| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Re: Improving hvm IO performance by using self IO emulat
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
|
|
|
| |
|
Home