Re: [Xen-devel] Re: Improving hvm IO performance by using self IO emulator (YA io-emu?)

[Tristan Gingold <tgingold@xxxxxxx>]

On Thu, Feb 22, 2007 at 09:24:15PM +0000, Mark Williamson wrote:
[...]
> Perhaps the network device ought to be the first to move?
I think I will start with the most simple device :-)

> > > Does the firmware get loaded as an option ROM or is it a special portion
> > > of guest memory that isn't normally reachable?
> >
> > IMHO it should come with hvmload.  No needs to make it unreachable.
> 
> Mmmm.  It's not like the guest can break security if it tampers with the 
> device models in its own memory space.
[Maybe I don't catch all the english here]
How can the guest break security WRT an usual PV domain ?

> Question: how does this compare with using a "stub domain" to run the device 
> models?  The previous proposed approach was to automatically switch to the 
> stub domain on trapping an IO by the HVM guest, and have that stub domain run 
> the device models, etc.
Is there a partial/full implementation of stub domain ?
The pro of firmware approach compared to stub domain is the easy way to do it:
it doesn't requires of lot of modification in the HV.

> You seem to be actually proposing running the code within the HVM guest 
> itself.  The two approaches aren't actually that different, IMO, since the 
> guest still effectively has two different execution contexts.  It does seem 
> to me that running within the HVM guest itself might be more flexible.
I fully agree.

> A cool little trick that this strategy could enable is to run a full Qemu 
> instruction emulator within the device model - I'd imagine this could be 
> useful on IA64, for instance, in order to provide support for running legacy 
> OSes (e.g. for x86, or *cough* PPC ;-))
That's something I'd like to have too.

Tristan.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel