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 11:33:10 +0000 [thread overview]
Message-ID: <1265110390.2965.22456.camel@zakaz.uk.xensource.com> (raw)
In-Reply-To: <1265098747-10117-7-git-send-email-sheng@linux.intel.com>
On Tue, 2010-02-02 at 08:19 +0000, Sheng Yang wrote:
> Notice one memory region(0xfbfe0000ul - 0xfc000000ul) would be reserved in the
> bios E820 table. This memory region would be used as grant table.
I queried this requirement in a reply to the hypervisor patch.
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 05a31e5..d7dfba9 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -1071,6 +1071,9 @@ static int __init xlblk_init(void)
> if (!xen_domain())
> return -ENODEV;
>
> + if (xen_hybrid_domain() && !xen_hybrid_evtchn_enabled())
> + return -ENODEV;
> +
This seems ugly, at the very least the check should be something like
xen_evtchn_enabled() but preferable would be to hook up evtchn's by
demuxing the PCI device IRQ (the exiting PVonHVM drivers mechanism) in
the case where hybrid evtchn's are not available and encapsulating the
differences inside the evtchn code, there should be no need to scatter
these sorts of checks throughout every driver.
If you don't want to demux the PCI device IRQ for the non-hybrid case
another option might be simply return failure from the evtchn operations
if hybrid evtchns are not available and to ensure that the drivers
handle that sort of error gracefully (which they should in any case). At
least the difference in mode would be encapsulated that way.
(same for netfront).
> if (register_blkdev(XENVBD_MAJOR, DEV_NAME)) {
> printk(KERN_WARNING "xen_blk: can't get major %d with name %s\n",
> XENVBD_MAJOR, DEV_NAME);
> diff --git a/drivers/input/xen-kbdfront.c b/drivers/input/xen-kbdfront.c
> index c721c0a..74cbb25 100644
> --- a/drivers/input/xen-kbdfront.c
> +++ b/drivers/input/xen-kbdfront.c
> @@ -341,6 +341,10 @@ static int __init xenkbd_init(void)
> if (!xen_domain())
> return -ENODEV;
>
> + /* Xen Hybrid domain don't need vkbd */
> + if (xen_hybrid_domain())
> + return -ENODEV;
> +
Why disallow it if the platform has specified it (same for fbfront)?
> diff --git a/include/xen/xen.h b/include/xen/xen.h
> index aace9cc..632e76f 100644
> --- a/include/xen/xen.h
> +++ b/include/xen/xen.h
> @@ -5,6 +5,7 @@ enum xen_domain_type {
> XEN_NATIVE, /* running on bare hardware */
> XEN_PV_DOMAIN, /* running in a PV domain */
> XEN_HVM_DOMAIN, /* running in a Xen hvm domain */
> + XEN_HYBRID_DOMAIN, /* running in a Xen hybrid hvm domain */
> };
I don't think you should need to distinguish HYBRID from HVM mode...
Ian.
next prev parent reply other threads:[~2010-02-02 11:33 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-02 8:19 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 [this message]
2010-02-02 13:24 ` [Xen-devel] " Sheng Yang
2010-02-02 16:24 ` Ian Campbell
2010-02-02 16:46 ` Sheng Yang
2010-02-02 18:09 ` Ian Campbell
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=1265110390.2965.22456.camel@zakaz.uk.xensource.com \
--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
all inboxes | Powered by JetHome®