Re: [Xen-ia64-devel] RE: [PATCH] blkif include fixes

Re: [Xen-ia64-devel] RE: [PATCH] blkif include fixes

[Arun Sharma]

Magenheimer, Dan (HP Labs Fort Collins) wrote:
> Moving this to xen-ia64-devel...
> 
> I think it would be great if we could all start working
> together on getting the virtual drivers working (for both
> VTI and non-VTI), [..]
> Any suggestions on how to divide up this work and
> coordinate?

Hi Dan, I posted two patch series today that might be interesting:

The first series is a bunch of include file cleanups similar to what 
Matt Chapman posted.

The second is a build hook + sparse tree for building xen drivers 
against unmodified linux.

The status is that it compiles ok, but doesn't work yet (although an 
earlier version of the same code worked several months ago). We just 
wanted to get community feedback as quickly as possible.

What we have not figured out is, how to handle the case where the
netfront driver tries to transfer the ownership of a page to another 
domain. It does this by writing to the phys_to_machine_mapping[] array.

While we can easily map the phys_to_machine table into a VMX guest, it's 
not clear that:

a) allowing the guest to modify it is safe
b) How should device models (qemu-dm) handle this. Right now it maps all
    of guest physical upfront and is not notified when phys_to_machine
    mapping changes.

	-Arun

RE: [Xen-ia64-devel] RE: [PATCH] blkif include fixes

[Ian Pratt]

> What we have not figured out is, how to handle the case where 
> the netfront driver tries to transfer the ownership of a page 
> to another domain. It does this by writing to the 
> phys_to_machine_mapping[] array.
> 
> While we can easily map the phys_to_machine table into a VMX 
> guest, it's not clear that:
> a) allowing the guest to modify it is safe

For translate shadow mode guests we need to do the p2m update in Xen in
the gnttab hypercalls.

Ian