Re: [Xen-devel] [PATCH v2 00/21] xen/arm: Add support for non-pci passthrough

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2014-09-10 at 21:03 -0700, Christoffer Dall wrote:
> On Wed, Sep 10, 2014 at 3:03 PM, Stefano Stabellini
> <stefano.stabellini@xxxxxxxxxxxxx> wrote:
> > On Wed, 10 Sep 2014, Christoffer Dall wrote:
> >> >>   How does a user
> >> >> know which physical address in Xen's physical address space needs to
> >> >> be remapped based on the hardware description language for Dom0?
> >> >
> >> > This is an interesting question. The short answer for platform device
> >> > type things is "they just know" (they presumably have datasheets etc).
> >> > But I think the underlying question here is whether they are given in PA
> >> > space or dom0 IPA space, right?
> >> >
> >>
> >> re. the underlying question, yes.
> >>
> >> For platform devices, I think the "they just know" doesn't really
> >> work.
> >
> > "Who" should "just know"?
> 
> Ian was arguing that that the Xen toolstack should just know.

No I'm not, I'm arguing that for 4.5 the toolstack should be told by the
user. I'm certainly not arguing that we should never have a better way.

>   To me
> it sounds like a very unflexible way of doing things.
> 
> > We are talking about users, specifically
> > embedded engineers trying to put together their systems. Certainly not a
> > server use case. A server sysadmin cannot be expected to "just know".
> > If we wanted to export this feature to end users we would have to
> > provide a simpler way to do it.
> >
> 
> All I am saying is that hardcoding hardware aspects about a specific
> platform in the toolstack sounds strange, especially if it's a matter
> of being able to probe for an IO region and an IRQ number.

No one is talking about hardcoding anything in the toolstack. When using
the lowlevel approach these things are written in the guest cfg file,
next to the kernel selection, number of vcpus etc etc.

> >> There must be a way for user space to determine the IO
> >> addresses and IRQ numbers for a platform device, I just think it
> >> should be completely decoupled from ACPI and DT.
> >
> > I don't follow you here. How would a user find the info she needs on a
> > device without using an ACPI/DT identifier to reference it?

For the server usecase almost everything of interest for passthrough
will be PCI, for which we already have a usable higher level
abstraction.

> 
> Your kernel would take care of that.  But you shouldn't be exposing
> the raw hardware description to user space.  My believe is that the
> notion of being able to copy a portion of a DTB from the host and
> directly insert it into the guest is fundamentally flawed.
> 
> But we're sort of discussing at two different axis here, Ian already
> suggested that we take the simple approach for the upcoming release,
> and we can talk more about generic solutions at LCU14, assuming you're
> all going to be there.

Yes.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel