[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

  • To: Kirk Allan <kallan@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
  • Date: Sun, 22 Oct 2006 16:50:46 +0100
  • Delivery-date: Sun, 22 Oct 2006 09:02:09 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Acb18dZsFLtKH2HlEduF+QANk04WTA==
  • Thread-topic: [Xen-devel] [PATCH] have netfront fail the probe for non-pv LAN devices in HVM guests

On 20/10/06 10:58 pm, "Kirk Allan" <kallan@xxxxxxxxxx> 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@xxxxxxxxxx>

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

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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.