Re: [Xen-devel] [PATCH] libxl: write IO ABI for disk frontends

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2013-04-24 at 10:13 +0100, Wei Liu wrote:
> On Wed, Apr 24, 2013 at 09:57:28AM +0100, Ian Campbell wrote:
> [...]
> > > +     *
> > > +     * Presumably ARM guests don't have this problem, so this snippet is 
> > > only
> > > +     * compiled for X86 target.
> > 
> > Yes, this isn't required on ARM.
> > 
> > Is there a reason why this is only done for PV guests? I'd expect at
> > least some older versions of the PV on HVM drivers to also need this
> > node. What did Xend do in this regard?
> 
> My question, does Linux prior to 2.6.26 support PV on HVM?

Not in tree, but you can get out-of-tree modules for various old
versions, see the unmodified_drivers tree in the Xen source. They
support from something ancient (like 2.6.9) up to 2.6.2x. They
effectively stop supporting versions when pvops arrived I think, so
there is a gap between these drivers and when PVHVM was added to
mainline Linux.

However I'd be more inclined to follow what Xend did here rather than
try for wider coverage "just because".

> > I think it would be preferable to have the logic for determining the
> > protocol in libxc, rather than exposing the guest width and putting the
> > logic in libxl. Mostly because on domain build it is also libxc which
> > makes this determination and keeping it in the same library makes sense
> > to me.
> > 
> > What I'd actually prefer is to use the value of
> > dom->arch_hooks.native_protocol in libxl__build_pv when building a new
> > domain and have xc_domain_restore include the protocol as an output when
> > restoring so that libxl can use that in the restore case. This might be
> > more plumbing than we are willing to do at this stage of the release
> > though, so if you remove the bits which expose the protocol in the libxl
> > API (see below) and make this purely internal functionality of libxl+
> > libxc we could live with an explicit query for the protocol.
> > 
> 
> I did use arch_hooks.native_protocol in my first implementation but
> later found out that it is impossible to get this value when doing
> restore. I also tried to avoid altering existing restore API

In general changing the libxc APIs where necessary is absolutely fine --
we don't make any guarantees about that interface. But ...

> as you pointed out we are now close to release.

... yes. If it were just a case of adding an option to xc_domain_restore
I'd probably still push for it but since it will also involve plumbing
things through the libxl-save-helper process and libxl callbacks that
makes it a bit more involved.

> So I just came up with exposing guest width to libxl. :-(

I think just exposing a new function xc_domain_get_native_protocol would
be OK wrt the freeze and preferable to exposing the guest width.

[...]
> > Did Xend only do this for disks, or did it do it for all devices?
> > 
> 
> It does this for all devices, but only very old disk frontend relies on
> this AFAICT.

Disk is the only one I can think of where the ring structures are
different for 32 vs 64.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel