From: Julien Grall <julien.grall@citrix.com>
To: Ian Campbell <ian.campbell@citrix.com>,
Manish Jaggi <mjaggi@caviumnetworks.com>
Cc: "Vijay Kilari" <vijay.kilari@gmail.com>,
"Prasun Kapoor" <Prasun.kapoor@caviumnetworks.com>,
"Kumar, Vijaya" <Vijaya.Kumar@caviumnetworks.com>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
"Stefano Stabellini" <stefano.stabellini@citrix.com>,
"Kulkarni, Ganapatrao" <Ganapatrao.Kulkarni@caviumnetworks.com>,
"Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: PCI Passthrough ARM Design : Draft1
Date: Wed, 10 Jun 2015 15:21:00 -0400 [thread overview]
Message-ID: <55788E1C.6080307@citrix.com> (raw)
In-Reply-To: <1433940302.30003.75.camel@citrix.com>
Hi,
On 10/06/2015 08:45, Ian Campbell wrote:
>> 4. DomU access / assignment PCI device
>> --------------------------------------
>> When a device is attached to a domU, provision has to be made such that
>> it can
>> access the MMIO space of the device and xen is able to identify the mapping
>> between guest bdf and system bdf. Two hypercalls are introduced
>
> I don't think we want/need new hypercalls here, the same existing
> hypercalls which are used on x86 should be suitable. That's
> XEN_DOMCTL_memory_mapping from the toolstack I think.
XEN_DOMCTL_memory_mapping is done by QEMU for x86 HVM when the guest
(i.e hvmloader?) is writing in the PCI BAR.
AFAIU, when the device is assigned to the guest, we don't know yet where
the BAR will live in the guest memory. It will be assigned by the guest
(I wasn't able to find if Linux is able to do it).
As the config space will trap in pciback, we would need to map the
physical memory to the guest from the kernel. A domain
>
>> Xen adds the mmio space to the stage2 translation for domU. The
>> restrction is
>> that xen creates 1:1 mapping of the MMIO address.
>
> I don't think we need/want this restriction. We can define some
> region(s) of guest memory to be an MMIO hole (by adding them to to the
> memory map in public/arch-arm.h).
Even if we decide to choose a 1:1 mapping, this should not be exposed in
the hypervisor interface (see the suggested physdev_map_mmio) and let at
the discretion of the toolstack domain.
Beware that the 1:1 mapping doesn't fit with the current guest memory
layout which is pre-defined at Xen build time. So you would also have to
make it dynamically or decide to use the same memory layout as the host.
> If there is a reason for this restriction/trade off then it should be
> spelled out as part of the design document, as should other such design
> decisions (which would include explaining where this differs from how
> things work for x86 why they must differ).
On x86, for HVM the MMIO mapping is done by QEMU. I know that Roger is
working on PCI passthrough for PVH. PVH is very similar to ARM guest and
I expect to see a similar needs for MMIO mapping. It would be good if we
can come up with a common interface.
Regards,
--
Julien Grall
next prev parent reply other threads:[~2015-06-10 19:21 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-08 7:52 PCI Passthrough ARM Design : Draft1 Manish Jaggi
2015-06-09 14:42 ` Jaggi, Manish
2015-06-09 15:58 ` Ian Campbell
2015-06-10 12:45 ` Ian Campbell
2015-06-10 19:21 ` Julien Grall [this message]
2015-06-11 8:56 ` Ian Campbell
2015-06-11 11:25 ` Julien Grall
2015-06-11 12:02 ` Ian Campbell
2015-06-16 16:13 ` Stefano Stabellini
2015-06-16 16:21 ` Roger Pau Monné
2015-06-16 17:11 ` Manish Jaggi
2015-06-16 17:28 ` Stefano Stabellini
2015-06-16 17:46 ` Manish Jaggi
2015-06-17 12:58 ` Stefano Stabellini
2015-06-17 13:43 ` Ian Campbell
2015-06-17 14:14 ` Manish Jaggi
2015-06-17 14:29 ` Ian Campbell
2015-06-17 14:35 ` Stefano Stabellini
2015-06-22 18:33 ` Konrad Rzeszutek Wilk
2015-06-23 8:44 ` Ian Campbell
2015-06-23 14:11 ` Konrad Rzeszutek Wilk
2015-06-25 7:44 ` Manish Jaggi
2015-06-25 9:11 ` Ian Campbell
2015-06-25 11:59 ` Manish Jaggi
2015-06-25 12:21 ` Ian Campbell
2015-06-25 17:26 ` Konrad Rzeszutek Wilk
2015-06-26 2:07 ` Manish Jaggi
2015-06-26 7:32 ` Ian Campbell
2015-06-26 8:50 ` Manish Jaggi
2015-06-26 9:09 ` Ian Campbell
2015-06-26 11:57 ` Manish Jaggi
2015-06-26 12:41 ` Ian Campbell
2015-06-26 13:28 ` Konrad Rzeszutek Wilk
2015-06-26 13:47 ` Ian Campbell
2015-06-26 13:52 ` Konrad Rzeszutek Wilk
2015-06-16 17:16 ` Stefano Stabellini
2015-06-17 10:08 ` Ian Campbell
2015-06-17 12:11 ` Julien Grall
2015-06-17 12:21 ` Ian Campbell
2015-06-17 12:53 ` Stefano Stabellini
2015-06-17 12:57 ` Julien Grall
2015-06-17 13:32 ` Ian Campbell
2015-06-17 13:40 ` Stefano Stabellini
2015-06-17 13:56 ` Ian Campbell
2015-06-17 14:18 ` Stefano Stabellini
2015-06-17 14:26 ` Ian Campbell
2015-06-22 18:31 ` Konrad Rzeszutek Wilk
2015-06-11 9:05 ` Roger Pau Monné
2015-06-11 12:04 ` Ian Campbell
2015-06-16 16:17 ` Stefano Stabellini
2015-06-11 21:38 ` Manish Jaggi
2015-06-12 8:32 ` Ian Campbell
2015-06-12 11:41 ` Julien Grall
2015-06-12 11:52 ` Ian Campbell
2015-06-16 5:42 ` Manish Jaggi
2015-06-16 7:02 ` Roger Pau Monné
2015-06-16 10:42 ` Julien Grall
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=55788E1C.6080307@citrix.com \
--to=julien.grall@citrix.com \
--cc=Ganapatrao.Kulkarni@caviumnetworks.com \
--cc=Prasun.kapoor@caviumnetworks.com \
--cc=Vijaya.Kumar@caviumnetworks.com \
--cc=ian.campbell@citrix.com \
--cc=mjaggi@caviumnetworks.com \
--cc=roger.pau@citrix.com \
--cc=stefano.stabellini@citrix.com \
--cc=vijay.kilari@gmail.com \
--cc=xen-devel@lists.xen.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.