From: Wei Liu <wl@xen.org>
To: "Roger Pau Monné" <roger.pau@citrix.com>
Cc: Wei Liu <liuwe@microsoft.com>, Wei Liu <wl@xen.org>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Michael Kelley <mikelley@microsoft.com>,
Jan Beulich <jbeulich@suse.com>,
Xen Development List <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH for-next RFC 4/8] x86: factor out xen variants for hypervisor setup code
Date: Fri, 27 Sep 2019 13:46:08 +0100 [thread overview]
Message-ID: <20190927124608.wjupoy2a2sxeksci@debian> (raw)
In-Reply-To: <20190927114159.3ngxlqdgsn6bnarf@Air-de-Roger>
On Fri, Sep 27, 2019 at 01:41:59PM +0200, Roger Pau Monné wrote:
> > >
> > > I wonder, do you also require to map hypervisor data into the guest
> > > physmap when running on HyperV?
> > >
> >
> > Yes. There are a lot of comparable concepts in Hyper-V. For example,
> > there is a page called VP assist page which is more or less the same as
> > Xen's vcpuinfo. Its format, content and interfaces may be different, but
> > conceptually it is the same as vcpuinfo.
> >
> > > Is there a way when running on HyperV to request unused physical
> > > address space ranges? What Xen currently does in init_memmap is quite
> > > crappy.
> > >
> >
> > Xen itself still needs to manage the address space, no?
> >
> > I agree the rangeset code in xen.c isn't pretty, but it does the job and
> > is not too intrusive.
>
> The problem with the current approach is that the nested Xen has no
> way of knowing whether those holes are actually unused, or are MMIO
> regions used by devices for example.
>
> Hence I wondered if HyperV had a way to signal to guests that a
> physical address range is safe to be used as scratch mapping space. We
> had spoken avoid introducing something in Xen to be able to report to
> guests safe ranges in the physmap to map stuff.
AFAICT Hyper-V TLFS doesn't describe such functionality.
On the other hand, Hyper-V may not need this infrastructure at all
because it doesn't have grant table frame or shared info page. The most
likely outcome is in the next version the memmap stuff will be left to
Xen only until I find a use case for it.
Wei.
>
> Thanks, Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2019-09-27 12:46 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-23 10:09 [Xen-devel] [PATCH for-next RFC 0/8] Port Xen to Hyper-V Wei Liu
2019-09-23 10:09 ` [Xen-devel] [PATCH for-next RFC 1/8] x86: introduce CONFIG_GUEST and move code Wei Liu
2019-09-25 9:59 ` Roger Pau Monné
2019-09-23 10:09 ` [Xen-devel] [PATCH for-next RFC 2/8] x86: include asm_defns.h directly in hypercall.h Wei Liu
2019-09-25 10:02 ` Roger Pau Monné
2019-09-23 10:09 ` [Xen-devel] [PATCH for-next RFC 3/8] x86: drop hypervisor_cpuid_base Wei Liu
2019-09-25 10:07 ` Roger Pau Monné
2019-09-23 10:09 ` [Xen-devel] [PATCH for-next RFC 4/8] x86: factor out xen variants for hypervisor setup code Wei Liu
2019-09-25 10:23 ` Roger Pau Monné
2019-09-27 11:30 ` Wei Liu
2019-09-27 11:39 ` Jan Beulich
2019-09-27 12:47 ` Wei Liu
2019-09-27 12:56 ` Jan Beulich
2019-09-27 11:41 ` Roger Pau Monné
2019-09-27 12:46 ` Wei Liu [this message]
2019-09-23 10:09 ` [Xen-devel] [PATCH for-next RFC 5/8] x86: factor out hypervisor agnostic code Wei Liu
2019-09-25 10:39 ` Roger Pau Monné
2019-09-27 11:18 ` Wei Liu
2019-09-23 10:09 ` [Xen-devel] [PATCH for-next RFC 6/8] x86: make probe_xen return boolean value Wei Liu
2019-09-25 10:44 ` Roger Pau Monné
2019-09-27 11:18 ` Wei Liu
2019-09-23 10:09 ` [Xen-devel] [PATCH for-next RFC 7/8] x86: introduce CONFIG_HYPERV and hyperv directory Wei Liu
2019-09-25 10:48 ` Roger Pau Monné
2019-09-27 11:18 ` Wei Liu
2019-09-23 10:09 ` [Xen-devel] [PATCH for-next RFC 8/8] x86: be more verbose when running nested Wei Liu
2019-09-25 10:54 ` Roger Pau Monné
2019-09-23 10:48 ` [Xen-devel] [PATCH for-next RFC 0/8] Port Xen to Hyper-V Paul Durrant
2019-09-23 11:27 ` Wei Liu
2019-09-23 12:11 ` Paul Durrant
2019-09-23 12:54 ` Wei Liu
2019-09-23 13:33 ` Wei Liu
2019-09-23 13:47 ` Paul Durrant
2019-09-23 14:21 ` Wei Liu
2019-09-23 14:39 ` Paul Durrant
2019-09-23 14:41 ` Wei Liu
2019-09-25 11:02 ` Roger Pau Monné
2019-09-25 15:36 ` Wei Liu
2019-09-26 10:37 ` Wei Liu
2019-09-26 10:41 ` Roger Pau Monné
2019-09-26 10:50 ` Wei Liu
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=20190927124608.wjupoy2a2sxeksci@debian \
--to=wl@xen.org \
--cc=andrew.cooper3@citrix.com \
--cc=jbeulich@suse.com \
--cc=liuwe@microsoft.com \
--cc=mikelley@microsoft.com \
--cc=roger.pau@citrix.com \
--cc=xen-devel@lists.xenproject.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.