linux-kernel - Re: [RFC PATCH v2 00/19] virtual-bus

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: <49E0C93E.5030205@redhat.com>
Date:	Sat, 11 Apr 2009 19:45:50 +0300
From:	Avi Kivity <avi@...hat.com>
To:	Gregory Haskins <ghaskins@...ell.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,
	bhutchings@...arflare.com, andi@...stfloor.org, gregkh@...e.de,
	herber@...dor.apana.org.au, chrisw@...s-sol.org,
	shemminger@...tta.com
Subject: Re: [RFC PATCH v2 00/19] virtual-bus

Gregory Haskins wrote:
> Avi,
>
> Gregory Haskins wrote:
>   
>> Todo:
>> *) Develop some kind of hypercall registration mechanism for KVM so that
>>    we can use that as an integration point instead of directly hooking
>>    kvm hypercalls
>>   
>>     
>
> What would you like to see here?  I now remember why I removed the
> original patch I had for registration...it requires some kind of
> discovery mechanism on its own.  Note that this is hard, but I figured
> it would make the overall series simpler if I didn't go this route and
> instead just integrated with a statically allocated vector.  That being
> said, I have no problem adding this back in but figure we should discuss
> the approach so I don't go down a rat-hole ;)
>
>   


One idea is similar to signalfd() or eventfd().  Provide a kvm ioctl 
that takes a gsi and returns an fd.  Writes to the fd change the state 
of the line, possible triggering an interrupt.  Another ioctl takes a 
hypercall number or pio port as well as an existing fd.  Invocations of 
the hypercall or writes to the port write to the fd (using the same 
protocol as eventfd), so the other end can respond.

The nice thing is that this can be used by both kernel and userspace 
components, and for kernel components, hypercalls can be either buffered 
or unbuffered.

> So, one thing we could do is use a string-identifier to discover
> hypercall resources.  In this model, we would have one additional
> hypercall registered with kvm (in addition to the mmu-ops, etc) called
> KVM_HC_DYNHC or something like that.  The support for DYNHC could be
> indicated in the cpuid (much like I do with the RESET, DYNIRQ, and VBUS
> support today.   When hypercall provides register, the could provide a
> string such as "vbus", and they would be allocated a hypercall id. 
> Likewise, the HC_DYNHC interface would allow a guest to query the cpuid
> for the DYNHC feature, and then query the HC_DYNHC vector for a string
> to hc# translation.  If the provider is not present, we return -1 for
> the hc#, otherwise we return the one that was allocated.
>
> I know how you feel about string-ids in general, but I am not quite sure
> how to design this otherwise without it looking eerily similar to what I
> already have (which is registering a new HC vector in kvm_para.h)
>   

No need for a string ID.  Reserve a range of hypercall numbers for 
dynamic IDs.  Userspace allocates one and gives it to the device using 
its configuration space (as applies to whatever bus it is using).


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