* KVM_ASSIGN_SET_MSIX_NR and KVM_ASSIGN_SET_MSIX_ENTRY should support MSI?
@ 2009-05-05 10:30 Michael S. Tsirkin
2009-05-05 11:04 ` Marcelo Tosatti
2009-05-05 11:29 ` Gregory Haskins
0 siblings, 2 replies; 12+ messages in thread
From: Michael S. Tsirkin @ 2009-05-05 10:30 UTC (permalink / raw)
To: Sheng Yang; +Cc: Avi Kivity, Marcelo Tosatti, Matthew Wilcox, kvm
The new KVM_ASSIGN_SET_MSIX_NR and KVM_ASSIGN_SET_MSIX_ENTRY ioctls have
been merged for 2.6.30. However, I note that PCI spec allows devices to
support multiple vectors with MSI as well (support will be in linux
2.6.30).
Even though qemu for now only uses a single vector with MSI, it would
seem that it's better to make the kernel/user interface generic straight
away rather than add more ioctls later. What do you think? It might not
be too late to fix this for 2.6.30.
--
MST
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: KVM_ASSIGN_SET_MSIX_NR and KVM_ASSIGN_SET_MSIX_ENTRY should support MSI?
2009-05-05 10:30 KVM_ASSIGN_SET_MSIX_NR and KVM_ASSIGN_SET_MSIX_ENTRY should support MSI? Michael S. Tsirkin
@ 2009-05-05 11:04 ` Marcelo Tosatti
2009-05-05 11:08 ` Michael S. Tsirkin
2009-05-05 11:29 ` Gregory Haskins
1 sibling, 1 reply; 12+ messages in thread
From: Marcelo Tosatti @ 2009-05-05 11:04 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Sheng Yang, Avi Kivity, Matthew Wilcox, kvm
On Tue, May 05, 2009 at 01:30:28PM +0300, Michael S. Tsirkin wrote:
> The new KVM_ASSIGN_SET_MSIX_NR and KVM_ASSIGN_SET_MSIX_ENTRY ioctls have
> been merged for 2.6.30. However, I note that PCI spec allows devices to
> support multiple vectors with MSI as well (support will be in linux
> 2.6.30).
>
> Even though qemu for now only uses a single vector with MSI, it would
> seem that it's better to make the kernel/user interface generic straight
> away rather than add more ioctls later. What do you think? It might not
> be too late to fix this for 2.6.30.
Can't you use more than one KVM_ASSIGN_SET_MSIX_ENTRY call per assigned
device?
If you can't, it would be better to change the ioctls before 2.6.30 is
release IMO.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: KVM_ASSIGN_SET_MSIX_NR and KVM_ASSIGN_SET_MSIX_ENTRY should support MSI?
2009-05-05 11:04 ` Marcelo Tosatti
@ 2009-05-05 11:08 ` Michael S. Tsirkin
2009-05-05 11:57 ` Avi Kivity
0 siblings, 1 reply; 12+ messages in thread
From: Michael S. Tsirkin @ 2009-05-05 11:08 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Sheng Yang, Avi Kivity, Matthew Wilcox, kvm
On Tue, May 05, 2009 at 08:04:15AM -0300, Marcelo Tosatti wrote:
> On Tue, May 05, 2009 at 01:30:28PM +0300, Michael S. Tsirkin wrote:
> > The new KVM_ASSIGN_SET_MSIX_NR and KVM_ASSIGN_SET_MSIX_ENTRY ioctls have
> > been merged for 2.6.30. However, I note that PCI spec allows devices to
> > support multiple vectors with MSI as well (support will be in linux
> > 2.6.30).
> >
> > Even though qemu for now only uses a single vector with MSI, it would
> > seem that it's better to make the kernel/user interface generic straight
> > away rather than add more ioctls later. What do you think? It might not
> > be too late to fix this for 2.6.30.
>
> Can't you use more than one KVM_ASSIGN_SET_MSIX_ENTRY call per assigned
> device?
Sure, but only one KVM_ASSIGN_SET_MSIX_NR.
> If you can't, it would be better to change the ioctls before 2.6.30 is
> release IMO.
>
--
MST
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: KVM_ASSIGN_SET_MSIX_NR and KVM_ASSIGN_SET_MSIX_ENTRY should support MSI?
2009-05-05 10:30 KVM_ASSIGN_SET_MSIX_NR and KVM_ASSIGN_SET_MSIX_ENTRY should support MSI? Michael S. Tsirkin
2009-05-05 11:04 ` Marcelo Tosatti
@ 2009-05-05 11:29 ` Gregory Haskins
2009-05-20 8:48 ` Sheng Yang
1 sibling, 1 reply; 12+ messages in thread
From: Gregory Haskins @ 2009-05-05 11:29 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Sheng Yang, Avi Kivity, Marcelo Tosatti, Matthew Wilcox, kvm
[-- Attachment #1: Type: text/plain, Size: 543 bytes --]
Michael S. Tsirkin wrote:
> The new KVM_ASSIGN_SET_MSIX_NR and KVM_ASSIGN_SET_MSIX_ENTRY ioctls have
> been merged for 2.6.30. However, I note that PCI spec allows devices to
> support multiple vectors with MSI as well (support will be in linux
> 2.6.30).
>
> Even though qemu for now only uses a single vector with MSI, it would
> seem that it's better to make the kernel/user interface generic straight
> away rather than add more ioctls later. What do you think? It might not
> be too late to fix this for 2.6.30.
>
+1
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 266 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: KVM_ASSIGN_SET_MSIX_NR and KVM_ASSIGN_SET_MSIX_ENTRY should support MSI?
2009-05-05 11:08 ` Michael S. Tsirkin
@ 2009-05-05 11:57 ` Avi Kivity
2009-05-05 12:01 ` Michael S. Tsirkin
0 siblings, 1 reply; 12+ messages in thread
From: Avi Kivity @ 2009-05-05 11:57 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Marcelo Tosatti, Sheng Yang, Matthew Wilcox, kvm
Michael S. Tsirkin wrote:
> On Tue, May 05, 2009 at 08:04:15AM -0300, Marcelo Tosatti wrote:
>
>> On Tue, May 05, 2009 at 01:30:28PM +0300, Michael S. Tsirkin wrote:
>>
>>> The new KVM_ASSIGN_SET_MSIX_NR and KVM_ASSIGN_SET_MSIX_ENTRY ioctls have
>>> been merged for 2.6.30. However, I note that PCI spec allows devices to
>>> support multiple vectors with MSI as well (support will be in linux
>>> 2.6.30).
>>>
>>> Even though qemu for now only uses a single vector with MSI, it would
>>> seem that it's better to make the kernel/user interface generic straight
>>> away rather than add more ioctls later. What do you think? It might not
>>> be too late to fix this for 2.6.30.
>>>
>> Can't you use more than one KVM_ASSIGN_SET_MSIX_ENTRY call per assigned
>> device?
>>
>
> Sure, but only one KVM_ASSIGN_SET_MSIX_NR.
>
>
MSIX_NR is the size of the table, while MSIX_ENTRY updates a single
entry, if I read the code correctly.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: KVM_ASSIGN_SET_MSIX_NR and KVM_ASSIGN_SET_MSIX_ENTRY should support MSI?
2009-05-05 11:57 ` Avi Kivity
@ 2009-05-05 12:01 ` Michael S. Tsirkin
2009-05-05 12:08 ` Avi Kivity
0 siblings, 1 reply; 12+ messages in thread
From: Michael S. Tsirkin @ 2009-05-05 12:01 UTC (permalink / raw)
To: Avi Kivity; +Cc: Marcelo Tosatti, Sheng Yang, Matthew Wilcox, kvm
On Tue, May 05, 2009 at 02:57:10PM +0300, Avi Kivity wrote:
> Michael S. Tsirkin wrote:
>> On Tue, May 05, 2009 at 08:04:15AM -0300, Marcelo Tosatti wrote:
>>
>>> On Tue, May 05, 2009 at 01:30:28PM +0300, Michael S. Tsirkin wrote:
>>>
>>>> The new KVM_ASSIGN_SET_MSIX_NR and KVM_ASSIGN_SET_MSIX_ENTRY ioctls have
>>>> been merged for 2.6.30. However, I note that PCI spec allows devices to
>>>> support multiple vectors with MSI as well (support will be in linux
>>>> 2.6.30).
>>>>
>>>> Even though qemu for now only uses a single vector with MSI, it would
>>>> seem that it's better to make the kernel/user interface generic straight
>>>> away rather than add more ioctls later. What do you think? It might not
>>>> be too late to fix this for 2.6.30.
>>>>
>>> Can't you use more than one KVM_ASSIGN_SET_MSIX_ENTRY call per assigned
>>> device?
>>>
>>
>> Sure, but only one KVM_ASSIGN_SET_MSIX_NR.
>>
>>
>
> MSIX_NR is the size of the table, while MSIX_ENTRY updates a single
> entry, if I read the code correctly.
Right. So we'll need something like this for MSI as well.
Actually maybe MSIX_NR MSIX_ENTRY should be renamed to MSI_NR / MSI_ENTRY
and changed to do the right thing depending on the IRQ type?
--
MST
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: KVM_ASSIGN_SET_MSIX_NR and KVM_ASSIGN_SET_MSIX_ENTRY should support MSI?
2009-05-05 12:01 ` Michael S. Tsirkin
@ 2009-05-05 12:08 ` Avi Kivity
2009-05-05 12:39 ` Michael S. Tsirkin
` (2 more replies)
0 siblings, 3 replies; 12+ messages in thread
From: Avi Kivity @ 2009-05-05 12:08 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Marcelo Tosatti, Sheng Yang, Matthew Wilcox, kvm
Michael S. Tsirkin wrote:
> On Tue, May 05, 2009 at 02:57:10PM +0300, Avi Kivity wrote:
>
>> Michael S. Tsirkin wrote:
>>
>>> On Tue, May 05, 2009 at 08:04:15AM -0300, Marcelo Tosatti wrote:
>>>
>>>
>>>> On Tue, May 05, 2009 at 01:30:28PM +0300, Michael S. Tsirkin wrote:
>>>>
>>>>
>>>>> The new KVM_ASSIGN_SET_MSIX_NR and KVM_ASSIGN_SET_MSIX_ENTRY ioctls have
>>>>> been merged for 2.6.30. However, I note that PCI spec allows devices to
>>>>> support multiple vectors with MSI as well (support will be in linux
>>>>> 2.6.30).
>>>>>
>>>>> Even though qemu for now only uses a single vector with MSI, it would
>>>>> seem that it's better to make the kernel/user interface generic straight
>>>>> away rather than add more ioctls later. What do you think? It might not
>>>>> be too late to fix this for 2.6.30.
>>>>>
>>>>>
>>>> Can't you use more than one KVM_ASSIGN_SET_MSIX_ENTRY call per assigned
>>>> device?
>>>>
>>>>
>>> Sure, but only one KVM_ASSIGN_SET_MSIX_NR.
>>>
>>>
>>>
>> MSIX_NR is the size of the table, while MSIX_ENTRY updates a single
>> entry, if I read the code correctly.
>>
>
> Right. So we'll need something like this for MSI as well.
> Actually maybe MSIX_NR MSIX_ENTRY should be renamed to MSI_NR / MSI_ENTRY
> and changed to do the right thing depending on the IRQ type?
>
Works for me. Sheng, is there a reason why it wasn't done like this?
btw, it could be further simplified by using irqfd. Instead of the host
device tying directly into kvm, it could just trigger an eventfd; and we
could terminate the eventfd either in kvm (irqfd) or in qemu.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: KVM_ASSIGN_SET_MSIX_NR and KVM_ASSIGN_SET_MSIX_ENTRY should support MSI?
2009-05-05 12:08 ` Avi Kivity
@ 2009-05-05 12:39 ` Michael S. Tsirkin
2009-05-05 12:57 ` Michael S. Tsirkin
2009-05-06 3:11 ` Sheng Yang
2 siblings, 0 replies; 12+ messages in thread
From: Michael S. Tsirkin @ 2009-05-05 12:39 UTC (permalink / raw)
To: Avi Kivity; +Cc: Marcelo Tosatti, Sheng Yang, Matthew Wilcox, kvm
On Tue, May 05, 2009 at 03:08:40PM +0300, Avi Kivity wrote:
> Michael S. Tsirkin wrote:
>> On Tue, May 05, 2009 at 02:57:10PM +0300, Avi Kivity wrote:
>>
>>> Michael S. Tsirkin wrote:
>>>
>>>> On Tue, May 05, 2009 at 08:04:15AM -0300, Marcelo Tosatti wrote:
>>>>
>>>>> On Tue, May 05, 2009 at 01:30:28PM +0300, Michael S. Tsirkin wrote:
>>>>>
>>>>>> The new KVM_ASSIGN_SET_MSIX_NR and KVM_ASSIGN_SET_MSIX_ENTRY ioctls have
>>>>>> been merged for 2.6.30. However, I note that PCI spec allows devices to
>>>>>> support multiple vectors with MSI as well (support will be in linux
>>>>>> 2.6.30).
>>>>>>
>>>>>> Even though qemu for now only uses a single vector with MSI, it would
>>>>>> seem that it's better to make the kernel/user interface generic straight
>>>>>> away rather than add more ioctls later. What do you think? It might not
>>>>>> be too late to fix this for 2.6.30.
>>>>>>
>>>>> Can't you use more than one KVM_ASSIGN_SET_MSIX_ENTRY call per assigned
>>>>> device?
>>>>>
>>>> Sure, but only one KVM_ASSIGN_SET_MSIX_NR.
>>>>
>>>>
>>> MSIX_NR is the size of the table, while MSIX_ENTRY updates a single
>>> entry, if I read the code correctly.
>>>
>>
>> Right. So we'll need something like this for MSI as well.
>> Actually maybe MSIX_NR MSIX_ENTRY should be renamed to MSI_NR / MSI_ENTRY
>> and changed to do the right thing depending on the IRQ type?
>>
>
> Works for me. Sheng, is there a reason why it wasn't done like this?
>
> btw, it could be further simplified by using irqfd. Instead of the host
> device tying directly into kvm, it could just trigger an eventfd; and we
> could terminate the eventfd either in kvm (irqfd) or in qemu.
This probably is outside the scope for 2.6.30 :)
--
MST
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: KVM_ASSIGN_SET_MSIX_NR and KVM_ASSIGN_SET_MSIX_ENTRY should support MSI?
2009-05-05 12:08 ` Avi Kivity
2009-05-05 12:39 ` Michael S. Tsirkin
@ 2009-05-05 12:57 ` Michael S. Tsirkin
2009-05-05 13:30 ` Avi Kivity
2009-05-06 3:11 ` Sheng Yang
2 siblings, 1 reply; 12+ messages in thread
From: Michael S. Tsirkin @ 2009-05-05 12:57 UTC (permalink / raw)
To: Avi Kivity; +Cc: Marcelo Tosatti, Sheng Yang, Matthew Wilcox, kvm
On Tue, May 05, 2009 at 03:08:40PM +0300, Avi Kivity wrote:
> Michael S. Tsirkin wrote:
>> On Tue, May 05, 2009 at 02:57:10PM +0300, Avi Kivity wrote:
>>
>>> Michael S. Tsirkin wrote:
>>>
>>>> On Tue, May 05, 2009 at 08:04:15AM -0300, Marcelo Tosatti wrote:
>>>>
>>>>> On Tue, May 05, 2009 at 01:30:28PM +0300, Michael S. Tsirkin wrote:
>>>>>
>>>>>> The new KVM_ASSIGN_SET_MSIX_NR and KVM_ASSIGN_SET_MSIX_ENTRY ioctls have
>>>>>> been merged for 2.6.30. However, I note that PCI spec allows devices to
>>>>>> support multiple vectors with MSI as well (support will be in linux
>>>>>> 2.6.30).
>>>>>>
>>>>>> Even though qemu for now only uses a single vector with MSI, it would
>>>>>> seem that it's better to make the kernel/user interface generic straight
>>>>>> away rather than add more ioctls later. What do you think? It might not
>>>>>> be too late to fix this for 2.6.30.
>>>>>>
>>>>> Can't you use more than one KVM_ASSIGN_SET_MSIX_ENTRY call per assigned
>>>>> device?
>>>>>
>>>> Sure, but only one KVM_ASSIGN_SET_MSIX_NR.
>>>>
>>>>
>>> MSIX_NR is the size of the table, while MSIX_ENTRY updates a single
>>> entry, if I read the code correctly.
>>>
>>
>> Right. So we'll need something like this for MSI as well.
>> Actually maybe MSIX_NR MSIX_ENTRY should be renamed to MSI_NR / MSI_ENTRY
>> and changed to do the right thing depending on the IRQ type?
>>
>
> Works for me. Sheng, is there a reason why it wasn't done like this?
>
> btw, it could be further simplified by using irqfd. Instead of the host
> device tying directly into kvm, it could just trigger an eventfd; and we
> could terminate the eventfd either in kvm (irqfd) or in qemu.
If you are going wild, you could then split this code out from kvm
into something like a UIO driver. E.g. qemu could then in theory
support assigned devices even without VT-d hardware support in CPU.
--
MST
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: KVM_ASSIGN_SET_MSIX_NR and KVM_ASSIGN_SET_MSIX_ENTRY should support MSI?
2009-05-05 12:57 ` Michael S. Tsirkin
@ 2009-05-05 13:30 ` Avi Kivity
0 siblings, 0 replies; 12+ messages in thread
From: Avi Kivity @ 2009-05-05 13:30 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Marcelo Tosatti, Sheng Yang, Matthew Wilcox, kvm
Michael S. Tsirkin wrote:
>> Works for me. Sheng, is there a reason why it wasn't done like this?
>>
>> btw, it could be further simplified by using irqfd. Instead of the host
>> device tying directly into kvm, it could just trigger an eventfd; and we
>> could terminate the eventfd either in kvm (irqfd) or in qemu.
>>
>
> If you are going wild, you could then split this code out from kvm
> into something like a UIO driver. E.g. qemu could then in theory
> support assigned devices even without VT-d hardware support in CPU.
>
That's my thinking. PCI interrupts don't work because we need to do
some hacky stuff in there, but MSI should. Oh, and we could improve UIO
support for interrupts when using MSI, since there's no need to
acknowledge the interrupt.
Support we can tell the kernel to signal an eventfd whenever an MSI
fires. We then ask kvm for an irqfd, and give that irqfd to the kernel
for the MSI.
Voila, we assign an interrupt from userspace, without the device or kvm
knowing anything about it. Like you say, we can assign the device to
pure qemu, or to a userspace driver.
Beautiful, I finally found something to replace my old Lego set.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: KVM_ASSIGN_SET_MSIX_NR and KVM_ASSIGN_SET_MSIX_ENTRY should support MSI?
2009-05-05 12:08 ` Avi Kivity
2009-05-05 12:39 ` Michael S. Tsirkin
2009-05-05 12:57 ` Michael S. Tsirkin
@ 2009-05-06 3:11 ` Sheng Yang
2 siblings, 0 replies; 12+ messages in thread
From: Sheng Yang @ 2009-05-06 3:11 UTC (permalink / raw)
To: Avi Kivity; +Cc: Michael S. Tsirkin, Marcelo Tosatti, Matthew Wilcox, kvm
On Tuesday 05 May 2009 20:08:40 Avi Kivity wrote:
> Michael S. Tsirkin wrote:
> > On Tue, May 05, 2009 at 02:57:10PM +0300, Avi Kivity wrote:
> >> Michael S. Tsirkin wrote:
> >>> On Tue, May 05, 2009 at 08:04:15AM -0300, Marcelo Tosatti wrote:
> >>>> On Tue, May 05, 2009 at 01:30:28PM +0300, Michael S. Tsirkin wrote:
> >>>>> The new KVM_ASSIGN_SET_MSIX_NR and KVM_ASSIGN_SET_MSIX_ENTRY ioctls
> >>>>> have been merged for 2.6.30. However, I note that PCI spec allows
> >>>>> devices to support multiple vectors with MSI as well (support will be
> >>>>> in linux 2.6.30).
Well, one question: when did them merged? IIRC, MSI-X related things are still
pending for 2.6.31... :)
> >>>>>
> >>>>> Even though qemu for now only uses a single vector with MSI, it would
> >>>>> seem that it's better to make the kernel/user interface generic
> >>>>> straight away rather than add more ioctls later. What do you think?
> >>>>> It might not be too late to fix this for 2.6.30.
> >>>>
> >>>> Can't you use more than one KVM_ASSIGN_SET_MSIX_ENTRY call per
> >>>> assigned device?
> >>>
> >>> Sure, but only one KVM_ASSIGN_SET_MSIX_NR.
> >>
> >> MSIX_NR is the size of the table, while MSIX_ENTRY updates a single
> >> entry, if I read the code correctly.
> >
> > Right. So we'll need something like this for MSI as well.
> > Actually maybe MSIX_NR MSIX_ENTRY should be renamed to MSI_NR / MSI_ENTRY
> > and changed to do the right thing depending on the IRQ type?
>
> Works for me. Sheng, is there a reason why it wasn't done like this?
No, I think it's fine. Also some related structure should be modified. And one
flag field should be add to kvm_assigned_msix_nr and
kvm_assigned_msix_entry(using padding ones) to indicate the interrupt type,
for we can't determined the irq type by device's status at that time.
--
regards
Yang, Sheng
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: KVM_ASSIGN_SET_MSIX_NR and KVM_ASSIGN_SET_MSIX_ENTRY should support MSI?
2009-05-05 11:29 ` Gregory Haskins
@ 2009-05-20 8:48 ` Sheng Yang
0 siblings, 0 replies; 12+ messages in thread
From: Sheng Yang @ 2009-05-20 8:48 UTC (permalink / raw)
To: kvm
Cc: Gregory Haskins, Michael S. Tsirkin, Avi Kivity, Marcelo Tosatti,
Matthew Wilcox
On Tuesday 05 May 2009 19:29:14 Gregory Haskins wrote:
> Michael S. Tsirkin wrote:
> > The new KVM_ASSIGN_SET_MSIX_NR and KVM_ASSIGN_SET_MSIX_ENTRY ioctls have
> > been merged for 2.6.30. However, I note that PCI spec allows devices to
> > support multiple vectors with MSI as well (support will be in linux
> > 2.6.30).
> >
> > Even though qemu for now only uses a single vector with MSI, it would
> > seem that it's better to make the kernel/user interface generic straight
> > away rather than add more ioctls later. What do you think? It might not
> > be too late to fix this for 2.6.30.
>
> +1
Hi
Sorry for I don't have time to work at it recently... And Avi's review
patchset reminded me the merge for 2.6.31 would be soon. Anyone have
interesting to get this done?
Thanks!
--
regards
Yang, Sheng
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2009-05-20 8:47 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-05-05 10:30 KVM_ASSIGN_SET_MSIX_NR and KVM_ASSIGN_SET_MSIX_ENTRY should support MSI? Michael S. Tsirkin
2009-05-05 11:04 ` Marcelo Tosatti
2009-05-05 11:08 ` Michael S. Tsirkin
2009-05-05 11:57 ` Avi Kivity
2009-05-05 12:01 ` Michael S. Tsirkin
2009-05-05 12:08 ` Avi Kivity
2009-05-05 12:39 ` Michael S. Tsirkin
2009-05-05 12:57 ` Michael S. Tsirkin
2009-05-05 13:30 ` Avi Kivity
2009-05-06 3:11 ` Sheng Yang
2009-05-05 11:29 ` Gregory Haskins
2009-05-20 8:48 ` Sheng Yang
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.