Re: [PATCH 1/1] direct mmio for passthrough - kernel part

Ben-Ami Yassour1
2008-04-01T19:28:21Z

Avi Kivity <avi@qumranet.com> wrote on 01/04/2008 16:30:00:

> benami@il.ibm.com wrote:
> > From: Ben-Ami Yassour <benami@il.ibm.com>
> >
> > Enable a guest to access a device's memory mapped I/O regions directly.
> > Userspace sends the mmio regions that the guest can access. On the
first
> > page fault for an access to an mmio address the host translates
> the gva to hpa,
> > and updates the sptes.
> >
> >
>
> Can you explain why you're not using the regular memory slot mechanism?
> i.e. have userspace mmap(/dev/mem) and create a memslot containing that
> at the appropriate guest physical address?
>
> There are some issues with refcounting, but Andrea has some tricks to
> deal with that.
>
> --
> Any sufficiently difficult bug is indistinguishable from a feature.
>

Our initial approach was to mmap /sys/bus/pci/devices/.../resource#
and create a memory slot for it. However eventually we realized that for
mmio we don't need hva mapped to the mmio region, we can map the gpa
directly to hpa.

As far as I understand, the memory slots mechanism is used to map
gpa to hva. Then gfn_to_page uses get_user_pages to map hva to hpa.
However, get_user_pages does not work for mmio, and in addition we
know the hpa to begin with, so there is no real need to map an hva
for the mmio region.

In addition there is an assumption in the code that there is a page
struct for the frame which is not the case for mmio. So it was
easier to simply add a list of mmio gpa-hpa mapping.

I guess we can use the memory slots array to holds the gpa to hpa
mapping but it is not necessarily natural, and would probably
require more hooks in the code to handle an mmio memory slot. BTW,
note that for a guest that has multiple passthrough devices each
with a set of mmio regions, it might become a long list, so there
might be value to keep it separate from that respect as well.

With regards to the potential security issue Anthony pointed out
(ioctls taking hpa's) we can change the interface so that they will
take (device, BAR) instead and the kernel will translate to hpa

What do you think? Given that the shadow page table code has to be
modified anyway (due to the struct page issue), is it worthwhile to
experiment with mmap(...region) or is the current approach sufficient?

Thanks,
Ben