| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] [rfc] [patch] more 'long' in the hypervisor interface
Chris Wright wrote:
* Steve Ofsthun (sofsthun@xxxxxxxxxxxxxxx) wrote:
For HVM guests, the ABI is less established. I'm not sure anyone but us
(Virtual Iron), is doing much with hypercalls from HVM guests. We are
currently running paravirtualized drivers in HVM guests. As the code
matures, we will be posting these patches.
Look forward to seeing that.
So am I! ;)
We have had to deal with issues separate from the mechanical ABI issues.
For example, grant table transfers (used by the standard netfront/netback)
don't play well with QEMU's one time direct map of the entire HVM guest
address space.
What did you do here? Specifically, how much does the PV driver in HVM
guest diverge from normal PV guest? This will effect merging this code
into Linux which is why I care.
We changed the netfront/netback to stop using grant table transfers. As
an alternative, we preallocate receive buffers in netfront and pass them
as grant references to netback. As netback receives new packets, the
preallocated pool of buffers are dynamically mapped and data is copied in.
This additional data copy is probably unacceptable for PV guests. We
are just starting to analyze the performance impact.
Two alternatives to this approach are available in the longer term. One
is to create a new high performance device model in QEMU that reduces the
per packet cost of the emulated NIC. There has been discussion about this,
but I am not aware of any actual work in progress. Another approach is
to retain the existing PV network driver and fix the inconsistencies between
QEMU guest mappings and grant table transfer operations.
Steve
--
Steve Ofsthun - Virtual Iron Software, Inc.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home