From: Jan Kiszka <jan.kiszka@siemens.com>
To: Wei Liu <wei.liu2@citrix.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
xen-devel <xen-devel@lists.xensource.com>,
QEMU-devel <qemu-devel@nongnu.org>,
Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Qemu-devel] [PATCH] MSI / MSIX injection for Xen HVM
Date: Tue, 03 Apr 2012 18:52:19 +0200 [thread overview]
Message-ID: <4F7B2AC3.6030304@siemens.com> (raw)
In-Reply-To: <1333471466.2485.259.camel@leeds.uk.xensource.com>
On 2012-04-03 18:44, Wei Liu wrote:
> On Thu, 2012-03-01 at 15:56 +0000, Paolo Bonzini wrote:
>> Il 01/03/2012 15:50, Stefano Stabellini ha scritto:
>>>>>>> That is a good point actually: we already have lapic emulation in Xen,
>>>>>>> it makes sense to have apic-msi in Xen too.
>>>>>>> We would still need the changes to msi_notify and msix_notify though.
>>>>>
>>>>> Why? The stores would just go to the Xen interrupt controller MMIO area
>>>>> which then does the xc_hvm_inject_msi.
>>>
>>> Because msi(x)_notify is called by QEMU's emulated devices: it is not
>>> possible from QEMU to cause an emulation trap in Xen on behalf of the
>>> guest.
>>
>
> I'm not a QEMU expert, so following question may be dumb. However I do
> care about a cleaner implementation. So please be patient with me. :-)
>
>> msi{x,}_notify doesn't have to go to Xen MMIO emulation, so in Wei's
>> patch you don't need anymore the msi{,x}_notify parts, only apic_send_msi.
>>
>
> I don't quite understand "you don't need anymore the msi{,x}_notify
> parts". Virtio PCI invokes msi_notify directly. If I don't hook up
> msi{,x}_notify, how can I deal with devices like Virtio PCI?
See how KVM will solve this in [1].
Jan
[1] http://permalink.gmane.org/gmane.comp.emulators.kvm.devel/89121
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
WARNING: multiple messages have this Message-ID (diff)
From: Jan Kiszka <jan.kiszka@siemens.com>
To: Wei Liu <wei.liu2@citrix.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
xen-devel <xen-devel@lists.xensource.com>,
QEMU-devel <qemu-devel@nongnu.org>,
Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [PATCH] MSI / MSIX injection for Xen HVM
Date: Tue, 03 Apr 2012 18:52:19 +0200 [thread overview]
Message-ID: <4F7B2AC3.6030304@siemens.com> (raw)
In-Reply-To: <1333471466.2485.259.camel@leeds.uk.xensource.com>
On 2012-04-03 18:44, Wei Liu wrote:
> On Thu, 2012-03-01 at 15:56 +0000, Paolo Bonzini wrote:
>> Il 01/03/2012 15:50, Stefano Stabellini ha scritto:
>>>>>>> That is a good point actually: we already have lapic emulation in Xen,
>>>>>>> it makes sense to have apic-msi in Xen too.
>>>>>>> We would still need the changes to msi_notify and msix_notify though.
>>>>>
>>>>> Why? The stores would just go to the Xen interrupt controller MMIO area
>>>>> which then does the xc_hvm_inject_msi.
>>>
>>> Because msi(x)_notify is called by QEMU's emulated devices: it is not
>>> possible from QEMU to cause an emulation trap in Xen on behalf of the
>>> guest.
>>
>
> I'm not a QEMU expert, so following question may be dumb. However I do
> care about a cleaner implementation. So please be patient with me. :-)
>
>> msi{x,}_notify doesn't have to go to Xen MMIO emulation, so in Wei's
>> patch you don't need anymore the msi{,x}_notify parts, only apic_send_msi.
>>
>
> I don't quite understand "you don't need anymore the msi{,x}_notify
> parts". Virtio PCI invokes msi_notify directly. If I don't hook up
> msi{,x}_notify, how can I deal with devices like Virtio PCI?
See how KVM will solve this in [1].
Jan
[1] http://permalink.gmane.org/gmane.comp.emulators.kvm.devel/89121
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
next prev parent reply other threads:[~2012-04-03 16:52 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-29 17:21 [Qemu-devel] [PATCH] MSI / MSIX injection for Xen HVM Wei Liu
2012-02-29 17:21 ` Wei Liu
2012-02-29 17:47 ` [Qemu-devel] " Jan Kiszka
2012-02-29 17:47 ` Jan Kiszka
2012-03-01 10:20 ` [Qemu-devel] " Wei Liu
2012-03-01 10:20 ` Wei Liu
2012-03-01 11:22 ` [Qemu-devel] " Jan Kiszka
2012-03-01 11:22 ` Jan Kiszka
2012-03-01 11:51 ` [Qemu-devel] " Wei Liu
2012-03-01 11:51 ` Wei Liu
2012-03-01 12:56 ` [Qemu-devel] " Paolo Bonzini
2012-03-01 12:56 ` Paolo Bonzini
2012-03-01 14:06 ` [Qemu-devel] " Stefano Stabellini
2012-03-01 14:06 ` Stefano Stabellini
2012-03-01 14:03 ` [Qemu-devel] " Paolo Bonzini
2012-03-01 14:03 ` Paolo Bonzini
2012-03-01 14:50 ` [Qemu-devel] " Stefano Stabellini
2012-03-01 14:50 ` Stefano Stabellini
2012-03-01 15:56 ` [Qemu-devel] " Paolo Bonzini
2012-03-01 15:56 ` Paolo Bonzini
2012-03-01 16:06 ` [Qemu-devel] " Stefano Stabellini
2012-03-01 16:06 ` Stefano Stabellini
2012-04-03 16:44 ` [Qemu-devel] " Wei Liu
2012-04-03 16:44 ` Wei Liu
2012-04-03 16:52 ` Jan Kiszka [this message]
2012-04-03 16:52 ` Jan Kiszka
2012-04-04 13:40 ` [Qemu-devel] " Stefano Stabellini
2012-04-04 13:40 ` Stefano Stabellini
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=4F7B2AC3.6030304@siemens.com \
--to=jan.kiszka@siemens.com \
--cc=Stefano.Stabellini@eu.citrix.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xensource.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.