Xen devel - Oct 2006 - [PATCH] have netfront fail the probe for non-pv LAN devices in HVM guests

While testing a mix of PV and FV LAN devices in a sles10 HVM guest, it was found
that netfront tries to initialize for the FV device.  This eventually fails and
causes the guest to hang.  By having netfront fail the probe for the FV device,
both PV and FV LAN devices can come up.

The patch applies to both unstable and 3.0.3 testing.

Signed-off-by: Kirk Allan <kallan@novell.com>



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

On 20/10/06 10:58 pm, "Kirk Allan" <kallan@novell.com> wrote:
> While testing a mix of PV and FV LAN devices in a sles10 HVM guest, it was
> found that netfront tries to initialize for the FV device.  This eventually
> fails and causes the guest to hang.  By having netfront fail the probe for
the
> FV device, both PV and FV LAN devices can come up.
> 
> The patch applies to both unstable and 3.0.3 testing.
> 
> Signed-off-by: Kirk Allan <kallan@novell.com>
I don''t think this is the best fix. The underlying problem is that xend
is
writing into the standard backend and frontend device paths in the first
place. This causes dom0 and domU xenbus probes to fire when they really
shouldn''t.

A better fix would be to modify DevController.py to specify different
backend and frontend configuration paths in xenstore for ioemu devices. For
example, they could go to
''<dompath>/emu/backend/{vif,vbd,...}'' and
''<dompath>/emu/device/{vif,vbd,...}''. There''s
lots of abstraction in the
DevController class for building paths, so hooking into the appropriate
methods conditionally on self.type==''ioemu'' won''t be
that hard. All nodes
under the emu/ directories should be accessible only by domain-0 -- the
guest itself won''t need access and it''s be a good safety catch
to explicitly
disallow it from doing so.

ioemu itself will also need updating to go look in emu/device/ instead of
device/. That''s straightforward.

 -- Keir



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