Re: [Xen-devel] [PATCH v2] hvmloader, libxl: use the correct ACPI settings depending on device model

[Igor Druzhinin <igor.druzhinin@xxxxxxxxxx>]

On 26/07/17 14:30, Roger Pau Monné wrote:
> On Wed, Jul 26, 2017 at 02:21:49PM +0100, Igor Druzhinin wrote:
>> On 26/07/17 14:06, Roger Pau Monné wrote:
>>> On Wed, Jul 26, 2017 at 11:56:55AM +0100, Igor Druzhinin wrote:
>>>> On 26/07/17 08:31, Roger Pau Monné wrote:
>>>>> On Tue, Jul 25, 2017 at 08:55:30PM +0100, Igor Druzhinin wrote:
>>>>>> We need to choose ACPI tables and ACPI IO port location
>>>>>> properly depending on the device model version we are running.
>>>>>> Previously, this decision was made by BIOS type specific
>>>>>> code in hvmloader, e.g. always load QEMU traditional specific
>>>>>> tables if it's ROMBIOS and always load QEMU Xen specific
>>>>>> tables if it's SeaBIOS.
>>>>>>
>>>>>> This change saves this behavior but adds an additional way
>>>>>> (xenstore key) to specify the correct device model if we
>>>>>> happen to run a non-default one. Toolstack bit makes use of it.
>>>>>
>>>>> Should there also be a change to libxl to allow selecting rombios
>>>>> with qemu-xen or seabios with qemu-trad?
>>>>>
>>>>
>>>> It's already there (see libxl__domain_build_info_setdefault()).
>>>
>>> Current code in libxl__domain_build_info_setdefault will prevent you
>>> from selecting qemu-xen and rombios or qemu-trad and seabios (grep
>>> for "Enforce BIOS<->Device Model version relationship"), hence me
>>> asking if this should be lifted, so the new combinations that this
>>> patch seems to allow are available from libxl/xl.
>>>
>>> Roger.
>>>
>>
>> Yes, you're right. I think we need to change them to warnings rather
>> than errors. For instance, ROMBIOS is perfectly compatible with QEMU-Xen
>> with some small modifications so there is no need for enforcement.
> 
> Are those small modifications upstream in our tree(s)?
> 

Some of them are in review. I probably need to find some time to finish
them.

Igor

>> What
>> do you think?
> 
> I think adding a warning but allowing them should be fine, or else the
> changes made by this patch are mostly meaningless to libxl/xl.
> 
> Roger.
> 

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