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.

If we remove the entry of SPCR table from XSDT table, would it work for
Dom0 to ignore the uart? And it doesn't need the STAO table?

-- 
Shannon


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