Hello Viresh.

[CCed Jürgen who might have some thoughts] [Sorry for the possible format issues]

On Thu, Feb 16, 2023 at 1:36 PM Andrew Cooper andrew.cooper3@citrix.com wrote:

On 16/02/2023 11:13 am, Viresh Kumar wrote:

...

Hi Oleksandr,

As you already know, I am looking at how we can integrate the Xen grants work in our implementation of Rust based Xen vhost frontend [1].

The hypervisor independent vhost-user backends [2] talk to xen-vhost-frontend using the standard vhost-user protocol [3]. Every memory region that the backends get access to are sent to it by the frontend as memory region descriptors, which contain only address and size information and lack any permission flags.

I noticed that with Xen grants, there are strict memory access restrictions, where a memory region may be marked READ only and we can't map it as RW anymore, trying that just fails. Because the standard vhost-user protocol doesn't have any permission flags, the vhost libraries (in Rust) can't do anything else but try to map everything as RW.

I am wondering how do I proceed on this as I am very much stuck here.

(unhelpful comment) This is what happens when people try to reinvent the wheel a little more square than it was before.

If the guest grants the page read-only, then you can only map it read only. Anything else is a violation of the security model.

So either you need to adjust the guest to always grant read/write, or you need to teach virtio that read only is actually a real concept.

~Andrew

Below are my thoughts which might be wrong.

I see the problem, but cannot add anything else to what Andrew has already said. If the frontend maps a page as RO then a backend (device) should map it with the same attribute and perform only read access to it. Restricted memory access using Xen grants is a kind of SW IOMMU, no more no less, so I assume the very same problem would take place if we would implement a virtio-iommu for Xen...

Let's assume that we cannot modify a guest to map *everything* as RW. But although the permission flags are not communicated explicitly in classic case, the backend usually knows how a particular frontend page is supposed to be mapped (at least I didn't face any permission related issues when using Xen grants either with standalone virtio-disk backend or Qemu based backends using Jürgen's PoC):

1. The virtqueues are mapped as RW (because it is supposed to be written by both ends) 2. The payload I/O buffer's (virtio ring descriptors) fortunately have a flag field, so it is always known whether they are WO or RO 3. The indirect descriptor is mapped as RO (because it contains a list of other descriptors, so nothing to be written there)

So I am wondering can this standard vhost-user protocol be extended to pass some additional information for a memory region?

If and only if that standard vhost-user protocol cannot be extended to communicate required information for a memory region *and* there is a need to use Xen grants for virtio (so it is completely unclear what that memory region actually represents and how it should be mapped) one (crazy?) idea could be to try to map everything as RW and fallback to RO if the mapping attempt fails. Or, perhaps, as an alternative, to map as RW only those pages which are going to be modified, anything else map as RO. Although I am not quite sure whether it would be a good idea.