From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: hangaohuai@huawei.com, xen-devel@lists.xen.org,
stefano.stabellini@citrix.com, shannon.zhao@linaro.org,
Shannon Zhao <zhaoshenglong@huawei.com>,
Boris Ostrovsky <boris.ostrovsky@oracle.com>,
Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [PATCH v5 21/22] xen/arm: Add a hypercall for device mmio mapping
Date: Fri, 4 Mar 2016 11:37:04 +0000 [thread overview]
Message-ID: <alpine.DEB.2.02.1603041133000.17938@kaball.uk.xensource.com> (raw)
In-Reply-To: <56D97B6E02000078000D953A@prv-mh.provo.novell.com>
On Fri, 4 Mar 2016, Jan Beulich wrote:
> >>> On 04.03.16 at 12:00, <roger.pau@citrix.com> wrote:
> > On Fri, 4 Mar 2016, Jan Beulich wrote:
> >> >>> On 04.03.16 at 07:15, <zhaoshenglong@huawei.com> wrote:
> >> Overall I wonder whether this wouldn't help PVH on x86 too,
> >> where we currently do some hackery to (not even completely)
> >> map MMIO into Dom0's p2m. In such a case perhaps
> >> map_dev_mmio_regions() should become a general per-arch
> >> function right away (declared in a common header and stubbed
> >> out in x86 code for now). Boris, Roger?
> >
> > I though that we agreed that Xen will take care of doing all the MMIO
> > mappings for HVMlite/PVHv2 guests:
> >
> > http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg01609.html
> >
> > My first idea was to use the MMIO device mapping hypercall (just like
> > ARM) on the hardware domain, but I think we can get away without it on x86.
>
> Oh, you're right (albeit that doesn't cover MMIO regions not
> represented by BARs, which will need taking care of).
This.
On ARM there can MMIO regions of non-PCI devices which need to be mapped
and can only be discovered via DSDT.
> Question
> back to the ARM folks then: Would such a model work for you
> too? (I'd really like to avoid having two different models, if we
> can avoid it.)
It doesn't cover non-PCI devices. But once you extend your model to deal
with non-PCI devices and MMIO regions not represented by BARs, then
potentually yes.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-03-04 11:37 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-04 6:15 [PATCH v5 00/22] Prepare UEFI and ACPI tables for Dom0 on ARM64 Shannon Zhao
2016-03-04 6:15 ` [PATCH v5 01/22] arm/acpi: Estimate memory required for acpi/efi tables Shannon Zhao
2016-03-04 10:09 ` Jan Beulich
2016-03-04 10:55 ` Stefano Stabellini
2016-03-04 15:03 ` Shannon Zhao
2016-03-04 15:23 ` Stefano Stabellini
2016-03-04 15:52 ` Shannon Zhao
2016-03-04 15:59 ` Stefano Stabellini
2016-03-04 15:39 ` Jan Beulich
2016-03-04 6:15 ` [PATCH v5 02/22] arm/acpi: Add a helper function to get the acpi table offset Shannon Zhao
2016-03-04 10:59 ` Stefano Stabellini
2016-03-04 15:12 ` Shannon Zhao
2016-03-04 15:31 ` Stefano Stabellini
2016-03-04 15:53 ` Shannon Zhao
2016-03-04 6:15 ` [PATCH v5 03/22] arm/acpi: Prepare FADT table for Dom0 Shannon Zhao
2016-03-04 6:15 ` [PATCH v5 04/22] arm/gic: Add a new callback for creating MADT " Shannon Zhao
2016-03-04 6:15 ` [PATCH v5 05/22] arm/acpi: Prepare " Shannon Zhao
2016-03-04 6:15 ` [PATCH v5 06/22] arm/acpi: Prepare STAO " Shannon Zhao
2016-03-04 6:15 ` [PATCH v5 07/22] arm/acpi: Prepare XSDT " Shannon Zhao
2016-03-04 6:15 ` [PATCH v5 08/22] arm/acpi: Prepare RSDP " Shannon Zhao
2016-03-04 6:15 ` [PATCH v5 09/22] arm/p2m: Add helper functions to map memory regions Shannon Zhao
2016-03-04 10:51 ` Stefano Stabellini
2016-03-04 6:15 ` [PATCH v5 10/22] arm/acpi: Map all other tables for Dom0 Shannon Zhao
2016-03-04 6:15 ` [PATCH v5 11/22] arm/acpi: Prepare EFI system table " Shannon Zhao
2016-03-04 11:02 ` Stefano Stabellini
2016-03-04 6:15 ` [PATCH v5 12/22] arm/acpi: Prepare EFI memory descriptor " Shannon Zhao
2016-03-04 11:13 ` Stefano Stabellini
2016-03-16 8:59 ` Shannon Zhao
2016-03-04 6:15 ` [PATCH v5 13/22] arm/acpi: Map the new created EFI and ACPI tables to Dom0 Shannon Zhao
2016-03-04 6:15 ` [PATCH v5 14/22] arm/acpi: Create min DT stub for Dom0 Shannon Zhao
2016-03-04 11:17 ` Stefano Stabellini
2016-03-04 6:15 ` [PATCH v5 15/22] arm/acpi: Permit access all Xen unused SPIs " Shannon Zhao
2016-03-04 6:15 ` [PATCH v5 16/22] arm/acpi: Configure SPI interrupt type and route to Dom0 dynamically Shannon Zhao
2016-03-04 11:26 ` Stefano Stabellini
2016-03-04 15:16 ` Shannon Zhao
2016-03-04 6:15 ` [PATCH v5 17/22] arm/gic: Add a new callback to deny Dom0 access to GIC regions Shannon Zhao
2016-03-04 11:59 ` Stefano Stabellini
2016-03-04 6:15 ` [PATCH v5 18/22] arm/acpi: Permit MMIO access of Xen unused devices for Dom0 Shannon Zhao
2016-03-04 12:01 ` Stefano Stabellini
2016-03-04 6:15 ` [PATCH v5 19/22] hvm/params: Add a new delivery type for event-channel in HVM_PARAM_CALLBACK_IRQ Shannon Zhao
2016-03-04 10:16 ` Jan Beulich
2016-03-04 12:09 ` Stefano Stabellini
2016-03-04 12:20 ` Jan Beulich
2016-03-04 12:26 ` Stefano Stabellini
2016-03-16 15:03 ` Julien Grall
2016-03-16 15:10 ` Jan Beulich
2016-03-04 21:19 ` Konrad Rzeszutek Wilk
2016-03-16 16:34 ` Julien Grall
2016-03-16 17:49 ` Konrad Rzeszutek Wilk
2016-03-24 12:24 ` Stefano Stabellini
2016-03-04 6:15 ` [PATCH v5 20/22] xen/acpi: Fix event-channel interrupt when booting with ACPI Shannon Zhao
2016-03-04 6:15 ` [PATCH v5 21/22] xen/arm: Add a hypercall for device mmio mapping Shannon Zhao
2016-03-04 10:29 ` Jan Beulich
2016-03-04 11:00 ` Roger Pau Monné
2016-03-04 11:11 ` Jan Beulich
2016-03-04 11:37 ` Stefano Stabellini [this message]
2016-03-16 9:48 ` Shannon Zhao
2016-03-16 10:04 ` Jan Beulich
2016-03-16 11:22 ` Shannon Zhao
2016-03-04 6:15 ` [PATCH v5 22/22] xen/arm64: Add ACPI support Shannon Zhao
2016-03-04 10:33 ` Jan Beulich
2016-03-04 11:45 ` Stefano Stabellini
2016-03-04 11:45 ` Stefano Stabellini
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=alpine.DEB.2.02.1603041133000.17938@kaball.uk.xensource.com \
--to=stefano.stabellini@eu.citrix.com \
--cc=JBeulich@suse.com \
--cc=boris.ostrovsky@oracle.com \
--cc=hangaohuai@huawei.com \
--cc=roger.pau@citrix.com \
--cc=shannon.zhao@linaro.org \
--cc=stefano.stabellini@citrix.com \
--cc=xen-devel@lists.xen.org \
--cc=zhaoshenglong@huawei.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).