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

[Christoffer Dall <christoffer.dall@linaro.org>]

On Tue, Sep 9, 2014 at 9:34 PM, Julien Grall <julien.grall@linaro.org> wrote:
> (Adding Christoffer)
>
> Hi Ian,
>
> On 09/09/14 07:34, Ian Campbell wrote:
>>
>> On Thu, 2014-07-31 at 16:00 +0100, Julien Grall wrote:
>>>
>>>      - Only common device properties (interrupts, regs) are written to
>>>      the guest device tree. Device that needs other properties may not
>>> work.
>>
>>
>> So I've glanced through the later (more toolstack oriented) bits from
>> towards the end but I think there's a question of the target users which
>> needs thinking about before I can have a sensible opinion on those.
>>
>> As I see it the main purpose of this series is to get the underlying
>> plumbing in place (wiring up iommus, routing IRQs etc) to support guests
>> with passthrough devices, for embedded folks to use and to provide a
>> basis for eventual PCI passthrough functionality. I really want to see
>> this stuff in 4.5
>>
>> What I'm concerned about is the toolstack side. TBH I'm not very keen on
>> the thing with exposing very DT specific stuff like compatible strings
>> down from the hypervisor via domctls.
>> It's not really clear how best to expose this functionality, I have a
>> feeling that this series either goes too far or not far enough and ends
>> up not really satisfying anyone.
>
>
> I don't see many other solutions to get the compatible strings. There is no
> easy way to get the property from DOM0, unless we introduce a new driver in
> Linux.
>

The toolstack you are using to create your guest must necessarily know
which guest it is creating, including device properties of a device a
user wishes to assign  It can know this because it's hardcoded,
included in some config files, or supplied directly by the user.  I
think you really want to decouple the hardware description method for
Dom0 from retrieving resource description about your device. Can't you
simply reference the device to Linux through its sysfs handle and use
your Xen-passthrough-layer-hypercall-magic (which I know nothing
about) to have Dom0 tell Xen to map/route the relevant resources?

What if your guest runs ACPI or something else different from your
hardware?  How will this work when using ACPI for the hardware?


>> My suspicion is that regular folks won't really be using passthrough
>> until it is via PCI and that in the meantime this functionality is only
>> going to be used by e.g. people building embedded system and superkeen
>> early adopters both of whom know what they are doing and can tolerate
>> some hacks etc to get things working (and I think that's fine, it's
>> still a worthwhile set of things to get into 4.5 and those folks are
>> worth supporting).
>>
>> I'm also worried that we may be committing ourselves to a libxl API
>> already without really working through all the issues (e.g. other
>> properties).
>>
>> Given that I wonder if we wouldn't be better off for 4.5 supporting
>> something much simpler at the toolstack level, namely allowing users to
>> use iomem= and irq= in their domain config to map platform devices
>> through (already works with your series today?)
>
>
> This would need a bit a plumbing for irq part to allow the user choosing the
> VIRQ (like Arianna did for MMIO range).
>

My Xen knowledge is limited here.  Is the iomem= and irq= commands
given to your Dom0 toolstack, Dom0, or Xen itself?  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?

It still seems to me that you need to abstract the simple concept of a
device passthrough vector (device handle, associated MMIO regions,
associated IRQs).  That would extend more nicely to PCI/ACPI as well.
Am I missing something?

>> and perhaps a back door
>>
>> to allow the injection a blob of DT into the guest's DT to describe
>> them. i.e. enough to actually get stuff done but not pretending to be
>> too finely integrated.
>

can we not treat the problem of how to describe hardware to the guest
independently?  For this matter, I still think you need some way to
retrieve the canonical information specific to your running instance
(mmio regions, irqs) and then you need to be able to create a DT/ACPI
tables as you want.

>
> I would be fine with this solution for Xen 4.5. I will give a look to see
> what could be done.
>
>> Then we can revisit the "proper" toolstack side for 4.6. Otherwise I
>> fear that by the time we get the toolstack side sorted out to our
>> satisfaction the basic functionality (which seems to be largely done)
>> will have missed 4.5.
>
>
> Depending of the use cases, your solution based on "iomem", "irq" and DT
> blob might be enough for device platform passthrough.
>

Hmmm, I don't really know what the Xen development policy is, but I am
generally not very much for creating a system solution on an OS level
that addresses a very limited use case without any sort of generic
abstractions...

-Christoffer