Re: [Xen-devel] [PATCH V2 7/25] tools/libacpi: Add new fields in acpi_config for DMAR table

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 24.08.17 at 04:33, <tianyu.lan@xxxxxxxxx> wrote:
> On 2017年08月23日 16:04, Roger Pau Monné wrote:
>> On Wed, Aug 23, 2017 at 03:52:01PM +0800, Lan Tianyu wrote:
>>> On 2017年08月23日 00:41, Roger Pau Monné wrote:
>>>>>> +    drhd = (struct acpi_dmar_hardware_unit *)((void*)dmar + 
>>>>>> sizeof(*dmar));
>>>>>> +    drhd->type = ACPI_DMAR_TYPE_HARDWARE_UNIT;
>>>>>> +    drhd->length = sizeof(*drhd) + ioapic_scope_size;
>>>>>> +    drhd->flags = ACPI_DMAR_INCLUDE_PCI_ALL;
>>>>>> +    drhd->pci_segment = 0;
>>>>>> +    drhd->base_address = config->iommu_base_addr;
>>>>>> +
>>>>>> +    scope = &drhd->scope[0];
>>>>>> +    scope->type = ACPI_DMAR_DEVICE_SCOPE_IOAPIC;
>>>>>> +    scope->length = ioapic_scope_size;
>>>>>> +    scope->enumeration_id = config->ioapic_id;
>>>>>> +    scope->bus = I440_PSEUDO_BUS_PLATFORM;
>>>>>> +    scope->path[0] = I440_PSEUDO_DEVFN_IOAPIC;
>>>> I'm not sure whether this constants should instead be fields in the
>>>> acpi_config struct passed down from libxl. libxc shouldn't really need
>>>> to know anything about which chipset a VM is using.
>>>
>>> How about rename I440_PSEUDO_XXX to VIOMMU_PSEUDO_XXX?
>> 
>> I'm not really complaining about the naming, I'm just saying that I'm
>> not sure whether this constants should live in libxl. It would be
>> better IMHO if they where defined in some libxl x86 specific header,
>> and passed to libxc inside of the acpi_config struct.
>> 
>> At the end it is libxl which decides which chipset the VM is going to
>> use, not libxc.
> 
> We can do that but the bdf is reserved for IOAPIC and should be same for
> different chipset. Do we still need to pass it via acpi_config?

Well, which value is the right (reserved) one surely can - at least
in theory - depend on the chipset. Which means that it should
come from the same place which determines the chipset to be
emulated for the guest.

Jan

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