linux-kernel - Re: [PATCH v2 1/6] kvm: Pass kvm

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120628140041.10354331@BR9GNB5Z>
Date:	Thu, 28 Jun 2012 14:00:41 +0200
From:	Cornelia Huck <cornelia.huck@...ibm.com>
To:	"Michael S. Tsirkin" <mst@...hat.com>
Cc:	Alex Williamson <alex.williamson@...hat.com>, avi@...hat.com,
	kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
	jan.kiszka@...mens.com
Subject: Re: [PATCH v2 1/6] kvm: Pass kvm_irqfd to functions

On Thu, 28 Jun 2012 12:34:43 +0300
"Michael S. Tsirkin" <mst@...hat.com> 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 linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/