From: "Michael S. Tsirkin" <mst@redhat.com>
To: Gleb Natapov <gleb@redhat.com>
Cc: Avi Kivity <avi@redhat.com>, "Yang, Sheng" <sheng.yang@intel.com>,
Marcelo Tosatti <mtosatti@redhat.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: Re: Mask bit support's API
Date: Tue, 23 Nov 2010 18:10:11 +0200 [thread overview]
Message-ID: <20101123161011.GA32624@redhat.com> (raw)
In-Reply-To: <20101123152444.GC25606@redhat.com>
On Tue, Nov 23, 2010 at 05:24:44PM +0200, Gleb Natapov wrote:
> On Tue, Nov 23, 2010 at 05:11:19PM +0200, Michael S. Tsirkin wrote:
> > On Tue, Nov 23, 2010 at 04:06:20PM +0200, Avi Kivity wrote:
> > > >>
> > > >> So instead of
> > > >>
> > > >> - guest reads/writes msix
> > > >> - kvm filters mmio, implements some, passes others to userspace
> > > >>
> > > >> we have
> > > >>
> > > >> - guest reads/writes msix
> > > >> - kvm implements all
> > > >> - some writes generate an additional notification to userspace
> > > >
> > > >I suppose we don't need to generate notification to userspace? Because every
> > > >read/write is handled by kernel, and userspace just need interface to kernel to
> > > >get/set the entry - and well, does userspace need to do it when kernel can handle
> > > >all of them? Maybe not...
> > >
> > > We could have the kernel handle addr/data writes by setting up an
> > > internal interrupt routing. A disadvantage is that more work is
> > > needed if we emulator interrupt remapping in qemu.
> >
> > As an alternative, interrupt remapping will need some API rework, right?
> > Existing APIs only pass address/data for msi.
> >
> IIRC interrupt remapping works with address/data to. It just interpret
> it differently from apic.
Yes. So since our APIs use address/data, this is an argument for doing
the remapping in kernel.
> --
> Gleb.
next prev parent reply other threads:[~2010-11-23 16:10 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-23 6:09 Mask bit support's API Yang, Sheng
2010-11-23 6:17 ` Avi Kivity
2010-11-23 6:35 ` Yang, Sheng
2010-11-23 7:54 ` Avi Kivity
2010-11-23 8:30 ` Yang, Sheng
2010-11-23 12:47 ` Avi Kivity
2010-11-23 12:56 ` Michael S. Tsirkin
2010-11-23 13:57 ` Yang, Sheng
2010-11-23 14:06 ` Avi Kivity
2010-11-23 15:11 ` Michael S. Tsirkin
2010-11-23 15:24 ` Gleb Natapov
2010-11-23 16:10 ` Michael S. Tsirkin [this message]
2010-11-24 1:59 ` Yang, Sheng
2010-11-26 2:35 ` Yang, Sheng
2010-11-30 14:15 ` Avi Kivity
2010-12-01 2:36 ` Yang, Sheng
2010-12-02 13:09 ` Avi Kivity
2010-12-02 13:47 ` Michael S. Tsirkin
2010-12-02 13:56 ` Avi Kivity
2010-12-02 14:26 ` Michael S. Tsirkin
2010-12-02 14:54 ` Sheng Yang
2010-12-02 16:55 ` Michael S. Tsirkin
2010-12-03 3:03 ` Yang, Sheng
2010-11-23 12:04 ` Michael S. Tsirkin
2010-11-23 14:02 ` Yang, Sheng
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=20101123161011.GA32624@redhat.com \
--to=mst@redhat.com \
--cc=avi@redhat.com \
--cc=gleb@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=mtosatti@redhat.com \
--cc=sheng.yang@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