Re: qemu/hw/device-assignment: questions about msix_table_page

["Michael S. Tsirkin" <mst@redhat.com>]

On Mon, Apr 27, 2009 at 09:16:14PM +0800, Sheng Yang wrote:
> On Monday 27 April 2009 18:41:17 Michael S. Tsirkin wrote:
> > Sheng, Marcelo,
> > I've been reading code in qemu/hw/device-assignment.c, and
> > I have a couple of questions about msi-x implementation:
> 
> Hi Michael
>
> > 1. What is the reason that msix_table_page is allocated
> >    with mmap and not with e.g. malloc?
> 
> msix_table_page is a page, and mmap allocate memory on page boundary. So I use 
> it.

Just wondering, would e.g. posix_memalign work here as well?

> > 2. msix_table_page has the guest view of the msix table for the device.
> >    However, even this memory isn't mapped into guest directly, instead
> >    msix_mmio_read/msix_mmio_write perform the write in qemu.
> >    Won't it be possible to map this page directly into
> >    guest memory, reducing the overhead for table writes?
> 
> First, Linux configured the real MSI-X table in device, which is out of our 
> scope. KVM accepted the interrupt from Linux, then inject it to the guest 
> according to the MSI-X table setting of guest. So KVM should know about the 
> page modification. For example, MSI-X table got mask bit which can be written 
> by guest at any time(this bit haven't been implement yet, but should be soon), 
> then we should mask the correlated vector of real MSI-X table; then guest may 
> modified the MSI address/data, that also should be intercepted by KVM and used 
> to update our knowledge of guest. So we can't passthrough the modification.

Right, I see that. However all msix_mmio_write does is a memcpy.
So what I don't understand yet, what causes the real MSI-X table to be modified?
Where's that code?

> If guest can write to the real device MSI-X table directly, it would cause 
> chaos on interrupt delivery, for what guest see is totally different with 
> what's host see...

Obviously.

Thanks,
-- 
MST