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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Thu, 13 Aug 2015, Julien Grall 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]).
> 
> > UEFI memmap shouldn't be exposed to Dom0 at all.
> 
> We have to craft a UEFI memmap in order to notify Dom0 where are the RAM
> regions.

Right. Keep in mind that there are no legacy interfaces to get these
info on ARM. All we have is ACPI and EFI.


> > Detecting running on Xen should (hopefully) be possible by other
> > means for Dom0.
> 
> How there is no cpuid like on ARM. So no possibility to know whether you
> are running on Xen or another hypervisor...
> 
> Modifying the FADT is the only viable solution we have today in order to
> tell that it's running on Xen.

We also have the XENV table.

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