Re: [Xen-devel] PCI Pass-through in Xen ARM: Draft 4

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 13.08.15 at 19:01, <ian.campbell@xxxxxxxxxx> wrote:
> On Thu, 2015-08-13 at 09:29 -0600, Jan Beulich wrote:
> 
> A bunch of your questions seem to be about things which have been discussed
> at length in previous postings, it's probably worth reviewing some of those
> discussions.

With the huge amount of mail to be read after returning from vacation
I had hoped to avoid that, assuming that results of such discussion
would (should) manifest themselves in the new draft i.e. I specifically
avoided to join the tail of the draft 3 thread).

>> Furthermore OSes can generally reassign BARs as they see fit (as
>> long as the chosen addresses don't collide with anything else).
> 
> Not with PV pcifront/back based setups, the BARs are fixed then I believe,
> even for x86/PV. That model is being followed on ARM too.

I'm unaware of the mechanism to avoid such re-assignment in Linux;
it's even less clear how you'd expect to suppress this in other guest
OSes (Windows - afaik - being able to run on ARM certainly makes it
a candidate guest, even if maybe this doesn't work today), namely
such not having any pcifront. And I hope this design discussion isn't
limiting itself to Linux guests.

>> But I wonder in general why this would need to be done through
>> xenstore: pciback knows the real BAR base, and with the help of
>> the hypervisor it ought to be able to also know the corresponding
>> guest address.
> 
> How? Previously adding a new hypercall was proposed for this, I didn't like
> that approach because it added a new frozen ABI to the hypercall interface
> and IMHO the tools is the right place to have the address space layout
> stuff anyway.

Yeah - it's a balancing issue between maintaining redundant information
(i.e. the risk of it getting out of sync) or having an unchangeable
interface.

Jan


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