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

[Shannon Zhao <zhaoshenglong@xxxxxxxxxx>]

On 2015/8/13 18:29, Christoffer Dall wrote:
> On Thu, Aug 13, 2015 at 11:22:19AM +0100, Ian Campbell wrote:
>> On Thu, 2015-08-13 at 11:13 +0100, Stefano Stabellini wrote:
>>>
>>>>> For example it is only natural for the kernel to try to use the GIC 
>>>>> hyp
>>>>> functionalities if they are described, while actually they are not
>>>>> emulated by Xen at all.
>>>>
>>>> See Ian's earlier reply: It can also be considered natural for it to
>>>> be aware that when run in EL2 to not use EL1 functionality.
>>
>> NB EL2 == Hyp and EL1 == Kernel, so it's the other way round, FWIW.
>>
>>> It is not just about the GIC Hyp functionalities.
>>
>> What else is there which is not subject to this logic? Timers are too, it
>> even applies to IOMMU's which have both stage1 and stage2 bits.
>>
>> BTW, I think kernels _already_ need to deal with a lot of this because in
>> reality nobody modifies the DTB when they use a firmware which launches the
>> kernel in EL1. IOW I think the kernel is already aware of which resources
>> can be used by which privilege level.
>>
> Yes, for resources specific to EL2 I believe that is indeed the case
> (the GIC driver doesn't look at the hypervisor control register address,
> and KVM does not even get that far if you're not booted in EL2, and the
> timer only uses the virtual timer if not booted in EL2 - we never
> attempt to use the hyp timer until Marc's VHE patches land, but they
> also depend on being booted in hyp mode).
> 
> 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.

--
Shannon



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