From: "Michael S. Tsirkin" <mst@redhat.com>
To: Avi Kivity <avi@redhat.com>
Cc: Sheng Yang <sheng@linux.intel.com>,
Marcelo Tosatti <mtosatti@redhat.com>,
kvm@vger.kernel.org, Alex Williamson <alex.williamson@redhat.com>
Subject: Re: [PATCH 2/2][RFC] KVM: Emulate MSI-X table and PBA in kernel
Date: Thu, 30 Dec 2010 12:03:02 +0200 [thread overview]
Message-ID: <20101230100302.GA6441@redhat.com> (raw)
In-Reply-To: <4D1C50B4.4020907@redhat.com>
On Thu, Dec 30, 2010 at 11:28:20AM +0200, Avi Kivity wrote:
> On 12/30/2010 09:32 AM, Sheng Yang wrote:
> >>
> >> I don't think it's going to work: we are not
> >> in the context of the right process. Further
> >> I think we should keep the option of
> >> reading the PBA status from the device or host kernel open.
> >> And generally having an interface
> >> for functionality we don't implement is not a good idea:
> >> you don't know whether you really can support the interface you promised.
> >
> >Well, I don't know if we want to read PBA from device directly. To me it's not a
> >good idea because the real device has nothing to do with the one we show to the
> >guest.
>
> Right. vPBA.bit = pPBA.bit |
> recorded_pending_bit_from_lazy_masked_interrupt.
At some level, this is correct. However both are *not* in userspace
memory so an interface that assumes that pending bits in userspace are
correct at all times is not going to work.
There is also the spec requirement that the device
clears the pending bit if the interrupt was not served
but the condition that caused the event no longer applies,
so that a driver can work just by polling pending bits.
Personally I don't think this requirement works in real life -
Seems more like a vague idea on behalf of spec authors -
so hopefully guests do not use this.
> > At least direct accessing the mask bits of real device would be very
> >dangerous. Avi?
>
> Agree.
>
> --
> error compiling committee.c: too many arguments to function
next prev parent reply other threads:[~2010-12-30 10:03 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-22 8:44 [PATCH 0/2 v6] MSI-X mask bit support for KVM Sheng Yang
2010-12-22 8:44 ` [PATCH 1/2] KVM: Move struct kvm_io_device to kvm_host.h Sheng Yang
2010-12-22 8:44 ` [PATCH 2/2][RFC] KVM: Emulate MSI-X table and PBA in kernel Sheng Yang
2010-12-28 12:26 ` Avi Kivity
2010-12-29 7:18 ` Sheng Yang
2010-12-29 8:31 ` Michael S. Tsirkin
2010-12-29 8:55 ` Sheng Yang
2010-12-29 9:28 ` Michael S. Tsirkin
2010-12-30 7:32 ` Sheng Yang
2010-12-30 7:47 ` Michael S. Tsirkin
2010-12-30 7:55 ` Sheng Yang
2010-12-30 8:15 ` Michael S. Tsirkin
2010-12-30 8:24 ` Sheng Yang
2010-12-30 8:52 ` Michael S. Tsirkin
2010-12-30 9:13 ` Sheng Yang
2010-12-30 9:30 ` Avi Kivity
2010-12-30 10:32 ` Michael S. Tsirkin
2010-12-30 10:37 ` Avi Kivity
2010-12-30 11:07 ` Michael S. Tsirkin
2010-12-30 11:27 ` Avi Kivity
2010-12-30 12:17 ` Michael S. Tsirkin
2010-12-31 3:05 ` Sheng Yang
2011-01-02 9:26 ` Michael S. Tsirkin
2011-01-02 10:26 ` Avi Kivity
2011-01-02 10:39 ` Michael S. Tsirkin
2011-01-02 10:58 ` Avi Kivity
2011-01-02 11:51 ` Michael S. Tsirkin
2011-01-02 13:34 ` Avi Kivity
2011-01-02 13:57 ` Michael S. Tsirkin
2010-12-30 9:28 ` Avi Kivity
2010-12-30 10:03 ` Michael S. Tsirkin [this message]
2010-12-28 4:05 ` [PATCH 0/2 v6] MSI-X mask bit support for KVM Sheng Yang
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=20101230100302.GA6441@redhat.com \
--to=mst@redhat.com \
--cc=alex.williamson@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