linux-kernel - Re: [KVM PATCH v4 3/3] kvm: add iosignalfd support

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: <1243446484.4852.13.camel@blaa>
Date:	Wed, 27 May 2009 18:48:04 +0100
From:	Mark McLoughlin <markmc@...hat.com>
To:	Gregory Haskins <ghaskins@...ell.com>
Cc:	Avi Kivity <avi@...hat.com>, kvm@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Davide Libenzi <davidel@...ilserver.org>, mtosatti@...hat.com
Subject: Re: [KVM PATCH v4 3/3] kvm: add iosignalfd support

On Wed, 2009-05-27 at 13:40 -0400, Gregory Haskins wrote:
> Mark McLoughlin wrote:
> > On Wed, 2009-05-27 at 15:11 +0300, Avi Kivity wrote:
> >
> >   
> >> Multiple cookies on the same address are required by virtio.  You can't 
> >> mux since the data doesn't go anywhere.
> >>
> >> Virtio can survive by checking all rings on a notify, and we can later 
> >> add a mechanism that has a distinct address for each ring, but let's see 
> >> if we can cope with multiple cookies.  Mark?
> >>     
> >
> > Trying to catch up, but you're talking about replacing virtio-pci
> > QUEUE_NOTIFY handling with iosignalfd ?
> >
> > For a perfect replacement, what you really need is to be able to
> > register multiple cookies per address range, but only have them trigger
> > if the written data matches a provided value.
> >   
> 
> Hmm..thats an interesting idea.  To date, the "cookie" has really been
> for identifying the proper range selected for deassignment.  I never
> thought of using it as an actual trigger value at run-time.
> 
> > If the data is lost, virtio has no way of knowing which queue is being
> > notified, so we either end up with per-device, rather than per-queue,
> > notifications (probably not too bad for net, at least) or a different
> > notify address per queue (limiting the number of queues per device).
> >   
> 
> The addr-per-queue is how I was envisioning it, but the trigger value
> concept hadn't occurred to me.  I could make this an option during
> assignment (e.g. "COOKIE" flag means only trigger on writes of the
> provided cookie, otherwise trigger on any write).  Sound good?

Ah, I'd been thinking of the trigger data being provided separately to
the cookie.

The virtio ABI is fixed, so we couldn't e.g. have the guest use a cookie
to identify a queue - it's just going to continue using a per-device
queue number. So, if the cookie was also the trigger, we'd need an
eventfd per device.

And if this was a device where the guest writes similar values to
multiple addresses, you'd need an eventfd per address.

Cheers,
Mark.

--
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/