xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sheng Yang <sheng@linux.intel.com>
Cc: Jeremy Fitzhardinge <Jeremy.Fitzhardinge@citrix.com>,
	Keir Fraser <Keir.Fraser@eu.citrix.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 6/6] xen/hybrid: Enable grant table and xenbus
Date: Tue, 2 Feb 2010 18:09:03 +0000	[thread overview]
Message-ID: <1265134143.3247.10.camel@localhost.localdomain> (raw)
In-Reply-To: <201002030046.41799.sheng@linux.intel.com>

On Tue, 2010-02-02 at 16:46 +0000, Sheng Yang wrote: 
> On Wednesday 03 February 2010 00:24:04 Ian Campbell wrote:
> > On Tue, 2010-02-02 at 13:24 +0000, Sheng Yang wrote:
> > > I am not sure if I understand you right, but I think the issue is,
> > > there is no PVonHVM drivers in Linux upstream. The drivers are
> > > currently maintained by OSVs, and the one in Xen upstream code only
> > > support 2.6.18. So I didn't take them into consideration at the time.
> > 
> > True, but this is something which should be taken care of by the core
> > Xen-aware code not something which should be pushed down into each
> > driver.
> > 
> > Someone who wants to add PVonHVM functionality shouldn't have to go and
> > remove a bunch of conditionals from each driver (or worse add
> > alternative clauses to each check!).
> > 
> > > I think the "xen_evtchn_enable()" looks much better. Would replace
> > > these ugly lines in the next version.
> > 
> > I think it would be cleaner to encapsulate this in the evtchn code
> > rather than leaking platform knowledge into each driver. IOW the evtchn
> > functions should return failure if event channels are not enabled and
> > the driver should cope with this gracefully.
> 
> Agree. That what I suppose to do. What the drivers should only know is, if 
> event channel is enabled. 
> 
> > Or perhaps at the xenbus driver level we should be deciding whether or
> > not we have enough paravirtualisation to be worth probing the drivers at
> > all?
> 
> I think current scheme is direct enough for now. We can improve it later.

Taking a step back I don't think any of these checks are necessary at
all -- in order to get as far as actually probing the devices xenbus
needs to be up and running, which implies event channels, as well as
everything else required for PV drivers to function, are working.

Drivers for PCI devices don't all start with "if (pci_bus_available())",
they just register the driver and let the kernel's driver core take care
of things. If someone is worried about the overhead of an extra driver
being registered, well that is what modular kernels are for.

I think that even the existing "if (xen_domain())" check is unnecessary,
at least in the frontend drivers.

Ian.

  reply	other threads:[~2010-02-02 18:09 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-02  8:19 (unknown), Sheng Yang
2010-02-02  8:19 ` [PATCH 1/6] xen/hybrid: add support for hvm_op Sheng Yang
2010-02-02  8:19 ` [PATCH 2/6] xen/hybrid: Import cpuid.h from Xen Sheng Yang
2010-02-02  8:19 ` [PATCH 3/6] xen/hybrid: Xen Hybrid Extension initialization Sheng Yang
2010-02-02  8:19 ` [PATCH 4/6] xen/hybrid: The entrance for Hybrid Sheng Yang
2010-02-02  8:19 ` [PATCH 5/6] xen/hybrid: Make event channel work with QEmu emulated devices Sheng Yang
2010-02-02  8:19 ` [PATCH 6/6] xen/hybrid: Enable grant table and xenbus Sheng Yang
2010-02-02 11:33   ` Ian Campbell
2010-02-02 13:24     ` Sheng Yang
2010-02-02 16:24       ` [Xen-devel] " Ian Campbell
2010-02-02 16:46         ` Sheng Yang
2010-02-02 18:09           ` Ian Campbell [this message]
2010-02-03  5:17             ` Sheng Yang
2010-02-02 17:03   ` Konrad Rzeszutek Wilk
2010-02-02 17:46     ` Sheng Yang
2010-02-02  8:26 ` [PATCH 0/6][v2] Hybrid extension for Xen guest Sheng Yang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1265134143.3247.10.camel@localhost.localdomain \
    --to=ian.campbell@citrix.com \
    --cc=Jeremy.Fitzhardinge@citrix.com \
    --cc=Keir.Fraser@eu.citrix.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sheng@linux.intel.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).