Re: [Xen-devel] Design doc of adding ACPI support for arm64 on Xen - version 2

[Julien Grall <julien.grall@xxxxxxxxxx>]

On 13/08/15 12:55, Jan Beulich wrote:
>>>> On 13.08.15 at 13:00, <julien.grall@xxxxxxxxxx> wrote:
>> On 13/08/15 11:54, Jan Beulich wrote:
>>>>>> On 13.08.15 at 12:48, <zhaoshenglong@xxxxxxxxxx> wrote:
>>>> On 2015/8/13 18:29, Christoffer Dall wrote:
>>>>> However, what about for other resources?  Having code somewhere that
>>>>> says "hide this random piece of hardware if you're Xen dom0" sounds
>>>>> awful to me.  I know it's only the serial port right now, but still.
>>>>>
>>>> It needs to modify MADT table according to dom0_max_vcpus and modify EFI
>>>> MMAP table according to dom0_mem. And modify FADT table to set
>>>> hypervisor_id as "XenVMM" to tell Dom0 that it runs on Xen hypervisor.
>>>
>>> None of this should be required:
>>>
>>> Unaltered MADT may (or should I say will) be needed to drive P- or
>>> C-states.
>>
>> We have to alter MADT for different reasons:
>>      - restricting the number of vCPUs
>>      - update the CPU bring up method
>>      - changing the CPUID
>>
>> Maybe we should pass a backup but we don't support cpufreq driver right
>> now and it would need quite a look of work to do it (see [1]).
> 
> I.e. you intend to not even leave open the road there.

Please beware that currently porting a guest to Xen on ARM is only a
couple of hundreds lines which is mainly detecting Xen and initializing
the Xen code. Other than that everything is the same as booting on
baremetal. I don't take into account the drivers as they usually make
usage of the kernel framework and don't touch boot code.

This is a strong advantage for Xen because developer would not have to
hack the internal OS in order to get running on Xen.

We are trying  to aim the same for ACPI. Any change compare to
baremetal boot will result to more work for the OS developer.

The MADT has to be modified in order to let DOM0 knows about his CPU
topology. If ever need the original MADT for power management, then we
should find a Xen specific way to do it (even if it's passing the
orginal MADT as a backup).

Regards,

-- 
Julien Grall

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