linux-kernel - Re: [RFC PATCH 0/3] generic hypercall 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: <4A03416D.8020405@redhat.com>
Date:	Thu, 07 May 2009 23:15:41 +0300
From:	Avi Kivity <avi@...hat.com>
To:	Gregory Haskins <ghaskins@...ell.com>
CC:	Gregory Haskins <gregory.haskins@...il.com>,
	Chris Wright <chrisw@...s-sol.org>,
	linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
	Anthony Liguori <anthony@...emonkey.ws>
Subject: Re: [RFC PATCH 0/3] generic hypercall support

Gregory Haskins wrote:
>> Oh yes.  But don't call it dynhc - like Chris says it's the wrong
>> semantic.
>>
>> Since we want to connect it to an eventfd, call it HC_NOTIFY or
>> HC_EVENT or something along these lines.  You won't be able to pass
>> any data, but that's fine.  Registers are saved to memory anyway.
>>     
> Ok, but how would you access the registers since you would presumably
> only be getting a waitq::func callback on the eventfd.  Or were you
> saying that more data, if required, is saved in a side-band memory
> location?  I can see the latter working. 

Yeah.  You basically have that side-band in vbus shmem (or the virtio ring).

>  I can't wrap my head around
> the former.
>   

I only meant that registers aren't faster than memory, since they are 
just another memory location.

In fact registers are accessed through a function call (not that that 
takes any time these days).


>> Just to make sure we have everything plumbed down, here's how I see
>> things working out (using qemu and virtio, use sed to taste):
>>
>> 1. qemu starts up, sets up the VM
>> 2. qemu creates virtio-net-server
>> 3. qemu allocates six eventfds: irq, stopirq, notify (one set for tx
>> ring, one set for rx ring)
>> 4. qemu connects the six eventfd to the data-available,
>> data-not-available, and kick ports of virtio-net-server
>> 5. the guest starts up and configures virtio-net in pci pin mode
>> 6. qemu notices and decides it will manage interrupts in user space
>> since this is complicated (shared level triggered interrupts)
>> 7. the guest OS boots, loads device driver
>> 8. device driver switches virtio-net to msix mode
>> 9. qemu notices, plumbs the irq fds as msix interrupts, plumbs the
>> notify fds as notifyfd
>> 10. look ma, no hands.
>>
>> Under the hood, the following takes place.
>>
>> kvm wires the irqfds to schedule a work item which fires the
>> interrupt.  One day the kvm developers get their act together and
>> change it to inject the interrupt directly when the irqfd is signalled
>> (which could be from the net softirq or somewhere similarly nasty).
>>
>> virtio-net-server wires notifyfd according to its liking.  It may
>> schedule a thread, or it may execute directly.
>>
>> And they all lived happily ever after.
>>     
>
> Ack.  I hope when its all said and done I can convince you that the
> framework to code up those virtio backends in the kernel is vbus ;)

If vbus doesn't bring significant performance advantages, I'll prefer 
virtio because of existing investment.

>   But
> even if not, this should provide enough plumbing that we can all coexist
> together peacefully.
>   

Yes, vbus and virtio can compete on their merits without bias from some 
maintainer getting in the way.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

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