linux-kernel - Re: Use of virtio device IDs

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]

Date:	Thu, 08 Nov 2007 10:40:44 -0600
From:	Anthony Liguori <aliguori@...ibm.com>
To:	Gerd Hoffmann <kraxel@...hat.com>
CC:	Avi Kivity <avi@...ranet.com>,
	Gregory Haskins <gregory.haskins.ml@...il.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Dor Laor <dor.laor@...ranet.com>,
	virtualization@...ts.linux-foundation.org,
	linux-kernel@...r.kernel.org
Subject: Re: Use of virtio device IDs

Gerd Hoffmann wrote:
> Avi Kivity wrote:
>   
>>> You are
>>> probably better off designing something that is PV specific instead of
>>> shoehorning it in to fit a different model (at least for the things I
>>> have in mind).  
>>>       
>> Well, if we design our pv devices to look like hardware, they will fit
>> quite well.  Both to the guest OS and to user's expectations.
>>     
>
> Disclaimer: Havn't looked at the virtio code much.
>
> I think we should keep the door open for both models and don't nail the
>  virtio infrastructure to one of them.
>
> For pure pv devices I don't see the point in trying to squeeze it into
> the PCI model.  Also s390 has no PCI, so there effecticely is no way
> around that, we must be able have some pure virtual bus like xenbus.
>   

I don't really agree with this assessment.  There is no performance 
advantage to using a pure virtual bus.  If you have a pure pv device 
that looks and act like a PCI device, besides the obvious advantage of 
easy portability to other guest OSes (since everything support PCI, but 
porting XenBus--event to Linux 2.4.x was a royal pain), it is also very 
easy to support the device on other VMMs.

For instance, the PCI device that I just posted would allow virtio 
devices to be used trivially with HVM on Xen.  In fact, once the 
backends are complete and merged into QEMU, the next time Xen rebases 
QEMU they'll get the virtio PV-on-HVM drivers for free.  To me, that's a 
pretty significant advantage.

> Uhm, well, yea.  Guess you are refering to the pv-on-hvm drivers.  Been
> there, dealt with it.  What exactly do you think is messy there?
>
> IMHO the most messy thing is the boot problem.  hvm bios can't deal with
> pv disks, so you can't boot with pv disks only.  "fixed" by having the
> (boot) disk twice in the system, once via emulated ide, once as pv disk.
>  Ouch.
>   

I have actually addressed this problem with a PV option rom for QEMU.  I 
expect to get time to submit the QEMU patches by the end of the year.  
See http://hg.codemonkey.ws/extboot

Regards,

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