WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] disable qemu PCI devices in HVM domains

> > 6) The drivers write a two-byte bitmask of devices to unplug to IO
> >    port 0x10.  The defined fields are:
> > 
> >    1 -- All IDE disks (not including CD drives)
> >    2 -- All emulated NICs
> >    4 -- All IDE disks except for the primary master (not including CD
> >     drives)
> Interesting. This seems more flexible than my initial approach which was
> to block just the PCI devices. I guess it makes sense to leave the qemu
> CDROM's as they support the eject etc functionality, and performance is
> seldom such a problem.
Yeah, that was pretty much our thinking.  If you want a bit to turn
off the IDE controller completely then that would be pretty easy to
add.

> > A previous version of the protocol put the IO ports on the PCI
> > platform device.  Unfortunately, that makes it difficult to get at
> > them before PCI bus enumeration happens, which complicates removal of
> > the emulated NICs.  It is possible to work around these but (at least
> > on Windows) it's complicated and messy, and generally best avoided.
> 
> I found that too :)
> 
> It's a bit more complicated than I would have preferred, but I think
> there is value in keeping the tree's in sync rather than re-implementing
> things.
> 
> As a result of this patch, does that mean that the Citrix Windows PV
> drivers might work on the GPL tree?
Not quite.  You still need a few other little bits of our toolstack,
but nothing which couldn't be added to xend with twenty minutes
hacking (which is how I tested these patches).

Of course, the driver EULA still prohibits using them with anything
other than XenServer.

> Is that a problem?
Not really.  All of the patches I've posted were open source already,
so someone who really wanted to use the drivers could have done so,
and there's enough still missing to make it inconvenient for casual
infringement.

Steven.

Attachment: signature.asc
Description: Digital signature

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
<Prev in Thread] Current Thread [Next in Thread>