[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Design doc of adding ACPI support for arm64 on Xen - version 2
On Thu, 2015-08-13 at 00:41 -0600, Jan Beulich wrote: > > > > Nonetheless, we still have to copy some table in Xen in order to modify > > them and/or new one. I have in mind the FADT table to set the hypervisor > > field and hiding the hypervisor specific data (GIC hyp, timer hyp...) to > > avoid the kernel thinks there is hyp mode available. > > "Have to"? Or rather "would like to"? As said in another reply to > Shannon, I didn't see any rationale spelled out for this fundamental > difference to x86. I think the fundamental difference is that h/w virt features are not (always) "discoverable" through h/w interfaces on ARM whereas they are visible in e.g. cpuid on x86 and not described in ACPI (x86 is only just gaining hardware support for virtualised interrupts so perhaps this will change? I think it doesn't have any hypervisor dedicated timer sources). So on ARM the firmware tables contain things like the additional virtualisation register regions in the interrupt controller description and the hypervisor timer interrupt in the timer block description. So we would like to hide these from dom0. Perhaps instead we should teach dom0 to notice that it was launched in Kernel mode rather than Hyp mode (which is detectable) and therefore ignore these unusable resources. Now you mention it that does sound sensible and I imagine is even already (close to) true for a Linux kernel to handle e.g. older firmware with newer device tree. The other reason for modification is to hide the Xen console device (i.e. one UART) from the dom0 kernel, since it is unusable. How does that work on x86? Do you just not bother and you expect the admin to arrange the configuration to work or is there some other trick? BTW, IIRC x86 does modify at least one ACPI table which is the DMAR (I think), to hide the IOMMU from the guest? That's another table we would want to frob on ARM I think (or it's equivalent, which I think is IORT). Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |