Re: [Xen-devel] [PATCH, RFC 0/7] PCI multi-segment support

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 05.09.11 at 15:33, Keir Fraser <keir.xen@xxxxxxxxx> wrote:
> On 05/09/2011 14:18, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
> 
>>>>> On 25.08.11 at 16:54, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:
>>> In order for Xen to be able to boot on systems with multiple PCI segments
>>> (also called domains), a number of changes are necessary to the
>>> hypervisor, the hypercall interface, the tools, and the Dom0 kernel, as
>>> in most code paths and definitions there were not even provisions for
>>> passing a segment number.
>>> 
>>> The hypercall interface changes may need some discussion before
>>> applying the patches, in particular
>>> 
>>> - whether the way PHYSDEVOP_map_pirq gets re-used is acceptable,
>>>   or whether alternatively we should define a replacement one sub-
>>>   hypercall
>>> - whether PHYSDEVOP_manage_pci_* should be deprecated
>>> - whether the bit assignments for the four uses of machine_bdf in
>>>   the domctl interface can be re-defined
>> 
>> No comment from either of you on the proposed changes?
> 
> I'm personally fine with folding segment into the bus field. Otherwise we
> just end up with more compat cruft.
> 
> I don't have an opinion on the PHYSDEVOP_manage_pci_* hypercalls. In fact I
> don't know much about them at all.
> 
> I've always considered the domctl interface subject to change, but you don't
> seem to redefine anything that already exists? You just give meaning to bits
> 24-31 of an existing 32-bit parameter?

I'm trying to avoid incompatible changes when possible (due to
out-of-tree consumers like libvirt, and due to the hacks required to
use domctl interfaces from the kernel). Now here we need 16 bits, but
have two sets of 8 (at bottom and top), hence I'd favor doing an
incompatible change here (moving the bdf bits down to 0...15, and
using 16...31 for the segment), perhaps renaming the field to
machine_sbdf (to force compile-time noticing of the change at least
for those that actually use our headers). But as the odd bit assignment
could have other (hidden) reasons I coded things first to not do any
re-assignments.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel