kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Sheng Yang <sheng@linux.intel.com>
Cc: Avi Kivity <avi@redhat.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	kvm@vger.kernel.org
Subject: Re: qemu/hw/device-assignment: questions about msix_table_page
Date: Mon, 27 Apr 2009 17:15:04 +0300	[thread overview]
Message-ID: <20090427141504.GC2504@redhat.com> (raw)
In-Reply-To: <200904272203.59909.sheng@linux.intel.com>

On Mon, Apr 27, 2009 at 10:03:59PM +0800, Sheng Yang wrote:
> On Monday 27 April 2009 21:51:34 Michael S. Tsirkin wrote:
> > 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?
> 
> Um, I think it should work too.
> >
> > > > 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?
> 
> Now it haven't been allowed to do dynamically change...:( For now, please 
> refer to assigned_device_update_msix_mmio in qemu/hw/device-assignment.c. It 
> would scan the MSI-X page and transfer to KVM through ioctl. And for the 
> kernel part, please refer to pci_enable_msix().

Right, I noticed that. So msix_mmio_read/write are placeholders, right?
For exiting functionality we thinkably could let the guest write into
msix_table_page.

> The userspace/kernel both still need change to support mask/unmask feature. 
> That's still in TODO list(and I hope it can catch up with 2.6.31 merge 
> window).
> 
> -- 
> regards
> Yang, Sheng
> 
> 
> > > 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,
> 

  reply	other threads:[~2009-04-27 14:16 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20090427104117.GB29082@redhat.com>
2009-04-27 13:16 ` Sheng Yang
2009-04-27 13:51   ` qemu/hw/device-assignment: questions about msix_table_page Michael S. Tsirkin
2009-04-27 14:03     ` Sheng Yang
2009-04-27 14:15       ` Michael S. Tsirkin [this message]
2009-04-27 14:30         ` Sheng Yang
2009-04-27 14:35           ` Michael S. Tsirkin
2009-05-05  9:51           ` Michael S. Tsirkin
2009-05-05 10:19             ` Marcelo Tosatti
2009-05-05 10:34               ` Michael S. Tsirkin
2009-05-05 10:49                 ` Marcelo Tosatti
2009-05-05 11:45                   ` Michael S. Tsirkin
2009-05-05 11:51                     ` Marcelo Tosatti
2009-05-05 12:46                   ` Michael S. Tsirkin
2009-05-06  2:35                     ` Sheng Yang
2009-05-06  7:31                       ` Michael S. Tsirkin
2009-05-06  8:17                         ` Sheng Yang
2009-04-28  9:31       ` Avi Kivity
2009-04-27 13:13 Michael S. Tsirkin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090427141504.GC2504@redhat.com \
    --to=mst@redhat.com \
    --cc=avi@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    --cc=sheng@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).