On Thu, 28 Jun 2012 12:34:43 +0300
"Michael S. Tsirkin" <mst@xxxxxxxxxx> wrote:
> On Thu, Jun 28, 2012 at 11:03:16AM +0200, Cornelia Huck wrote:
> > How about something like this as parameter for the new ioctl?
> >
> > struct kvm_irqfd2 {
> > __u32 fd;
> > __u32 flags; /* for things like deassign */
> > __u64 type; /* determines the payload */
> > union {
> > /* type traditional */
> > struct {
> > __u32 gsi;
> > } trad;
> > /* type s390 */
> > struct {
> > __u32 int_type;
> > __u32 parm;
> > __u64 parm64;
> > } s390;
> > __u8 pad[20];
> > };
> > }
> >
> > This could be combined with an arch or a per-kvm callback to keep the
> > generic code clean of architecture dependencies.
> >
> > Cornelia
>
> Looks a bit weird - shouldn't all this be part of gsi routing?
> But no idea really, I don't see the big picture here.
>
Well, on s390 we don't have anything like "gsi routing" (I'm not even
really sure what that is).
My understanding is the following:
- Basically, we want to notify the guest for a virtqueue.
- For this, we want to inject an interrupt for the associated device.
- On x86, this means raising an interrupt on an interrupt line, as
specified by some kind of number.
- On s390, we need some more information to (a) identify the device and
(b) additional information that needs to be transmitted for an
interrupt (device specific). (This is what basically goes into struct
kvm_s390_interrupt, which I reproduced in the s390 part.)
Cornelia
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
