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

[Christoffer Dall <christoffer.dall@xxxxxxxxxx>]

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.  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.

>
>> 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?

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.

-Christoffer

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