linux-kernel - Re: [kvm-devel] [PATCH 3/3] virtio PCI device

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: <474BE319.502@qumranet.com>
Date:	Tue, 27 Nov 2007 11:27:53 +0200
From:	Avi Kivity <avi@...ranet.com>
To:	carsteno@...ibm.com
CC:	Eric Van Hensbergen <ericvanhensbergen@...ibm.com>,
	kvm-devel@...ts.sourceforge.net, lguest <lguest@...abs.org>,
	linux-kernel@...r.kernel.org, virtualization@...ts.osdl.org
Subject: Re: [kvm-devel] [PATCH 3/3] virtio PCI device

Carsten Otte wrote:
> Avi Kivity wrote:
>   
>> No, definitely not define a hypercall ABI.  The feature bit should say 
>> "this device understands a hypervisor-specific way of kicking.  consult 
>> your hypervisor manual and cpuid bits for further details.  should you 
>> not be satisfied with this method, port io is still available".
>>     
> ...unless you're lucky enough to be on s390 where pio is not available.
> I don't see why we'd have two different ways to talk to a virtio 
> device. I think we should use a hypercall for interrupt injection, 
> without support for grumpy old soldered pci features other than 
> HPA-style Lguest PCI bus organization. There are no devices that we 
> want to be backward compatible with.
>   

pio is useful for qemu, for example, and as a fallback against changing 
hypervisor calling conventions.  As Anthony points out, it makes a 
qemu-implemented device instantly available to Xen at no extra charge.

My wording was inappropriate for s390, though.  The politically correct 
version reads "this device understands a hypervisor-specific way of 
kicking. consult your hypervisor manual and platform-specific way of 
querying hypervisor information for further details. should you not be 
satisfied with this method, the standard method of kicking virtio 
devices on your platform is still available".

On s390, I imagine that "the standard method" is the fabled diag 
instruction (which, with the proper arguments, will cook your steak to 
the exact shade of medium-rare you desire).  So you will never need to 
set the "hypervisor-specific way of kicking" bit, as your standard 
method is already optimal.

Unfortunately, we have to care for platform differences, subarch 
differences (vmx/svm), hypervisor differences (with virtio), and guest 
differences (Linux/Windows/pvLinux, 32/64).  Much care is needed when 
designing the ABI here.

[actually thinking a bit, this is specific to the virtio pci binding; 
s390 will never see any of it]

-- 
error compiling committee.c: too many arguments to function

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