netdev - Re: [RFC PATCH 14/17] kvm: add a reset capability

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: <49D27F24.1070709@novell.com>
Date:	Tue, 31 Mar 2009 16:37:56 -0400
From:	Gregory Haskins <ghaskins@...ell.com>
To:	Avi Kivity <avi@...hat.com>
CC:	linux-kernel@...r.kernel.org, agraf@...e.de, pmullaney@...ell.com,
	pmorreale@...ell.com, anthony@...emonkey.ws, rusty@...tcorp.com.au,
	netdev@...r.kernel.org, kvm@...r.kernel.org
Subject: Re: [RFC PATCH 14/17] kvm: add a reset capability

Avi Kivity wrote:
> Gregory Haskins wrote:
>> Avi Kivity wrote:
>>  
>>> Gregory Haskins wrote:
>>>    
>>>> We need a way to detect if a VM is reset later in the series, so lets
>>>> add a capability for userspace to signal a VM reset down to the
>>>> kernel.
>>>>         
>>> How do you handle the case of a guest calling kexec to load a new
>>> kernel?  Or is that not important for your use case?
>>>
>>>     
>>
>> Hmm..I had not considered this.  Any suggestions on ways to detect it?
>>
>>   
>
> Best would be not to detect it; it's tying global events into a
> device.  Instead, have a reset command for your device and have the
> driver issue it on load and unload.

Yes, good point.  This is doable within the existing infrastructure, but
it would have to be declared in each devices ABI definition.  I could
make it more formal and add it to the list of low-level bus-verbs, like
DEVICEOPEN, DEVICECLOSE, etc.

>
> btw, reset itself would be better controlled from userspace; qemu
> knows about resets and can reset vbus devices directly instead of
> relying on kvm to reset them.
In a way, this is what I have done (note to self: post the userspace
patches)

The detection is done by userspace, and it invokes an ioctl.  The kernel
based devices then react if they are interested.  In my case, vbus
registers for reset-notification, and it acts as if the guest exited
when it gets reset (e.g. it issues DEVICECLOSE verbs to all devices the
guest had open).



Download attachment "signature.asc" of type "application/pgp-signature" (258 bytes)