qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v4 10/20] hw/arm/virt-acpi-build: Generate RSDT


From: Igor Mammedov
Subject: Re: [Qemu-devel] [PATCH v4 10/20] hw/arm/virt-acpi-build: Generate RSDT table
Date: Thu, 9 Apr 2015 16:43:36 +0200

On Thu, 9 Apr 2015 14:59:09 +0100
Peter Maydell <address@hidden> wrote:

> On 9 April 2015 at 14:51, Igor Mammedov <address@hidden> wrote:
> > On Thu, 9 Apr 2015 14:27:58 +0100
> > Peter Maydell <address@hidden> wrote:
> >
> >> On 9 April 2015 at 14:17, Igor Mammedov <address@hidden> wrote:
> >> > On Thu, 09 Apr 2015 13:50:52 +0100
> >> > Alex Bennée <address@hidden> wrote:
> >> >
> >> >>
> >> >> Shannon Zhao <address@hidden> writes:
> >> >> > +    for (i = 0; i < table_offsets->len; ++i) {
> >> >> > +        /* rsdt->table_offset_entry to be filled by Guest linker */
> >> >> > +        bios_linker_loader_add_pointer(linker,
> >> >> > +                                       ACPI_BUILD_TABLE_FILE,
> >> >> > +                                       ACPI_BUILD_TABLE_FILE,
> >> >> > +                                       table_data, 
> >> >> > &rsdt->table_offset_entry[i],
> >> >> > +                                       sizeof(uint32_t));
> >> >>
> >> >> Why are these pointers always 32 bit? Can they ever be 64 bit?
> >> > Laszlo, can you confirm that UEFI puts APCI tables below 4G address 
> >> > space?
> >>
> >> In the general case you can't guarantee that there will
> >> be any RAM at all below the 4G point. (The virt board
> >> isn't like that, obviously, but I believe there's real
> >> hardware out there that's designed that way.) I don't
> >> think we should have any 32 bit assumptions in the
> >> code at all -- pointer values should always be 64 bits
> >> everywhere.
> >
> > then that forces us to use xsdt instead of 32-bit rsdt
> 
> Does that matter much?
not much, using rsdt would allow to share this code with x86.

also having tables below 4Gb in rsdt would make life of
32 bit guests easier, not that there are such guests now and may be
there wouldn't be any.

> 
> -- PMM
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]