Re: [Xen-devel] [PATCH v3.1 15/15] xen/x86: setup PVHv2 Dom0 ACPI tables

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 30.11.16 at 15:23, <roger.pau@xxxxxxxxxx> wrote:
> On Wed, Nov 30, 2016 at 07:09:47AM -0700, Jan Beulich wrote:
>> >>> On 30.11.16 at 13:40, <roger.pau@xxxxxxxxxx> wrote:
>> > On Mon, Nov 14, 2016 at 09:15:37AM -0700, Jan Beulich wrote:
>> >> >>> On 29.10.16 at 11:00, <roger.pau@xxxxxxxxxx> wrote:
>> >> > Also, regions marked as E820_ACPI or E820_NVS are identity mapped into 
>> >> > Dom0
>> >> > p2m, plus any top-level ACPI tables that should be accessible to Dom0 
>> >> > and
>> >> > that don't reside in RAM regions. This is needed because some memory 
>> >> > maps
>> >> > don't properly account for all the memory used by ACPI, so it's common 
>> >> > to
>> >> > find ACPI tables in holes.
>> >> 
>> >> I question whether this behavior should be enabled by default. Not
>> >> having seen the code yet I also wonder whether these regions
>> >> shouldn't simply be added to the guest's E820 as E820_ACPI, which
>> >> should then result in them getting mapped without further special
>> >> casing.
>> >> 
>> >> > +static int __init hvm_add_mem_range(struct domain *d, uint64_t s, 
>> >> > uint64_t e,
>> >> > +                                    uint32_t type)
>> >> 
>> >> I see s and e being uint64_t, but I don't see why type can't be plain
>> >> unsigned int.
>> > 
>> > Well, that's the type for "type" as defined in e820.h. I'm just using 
>> > uint32_t 
>> > for consistency with that.
>> 
>> As said a number of times in various contexts: We should try to
>> get away from using fixed width types where we don't really need
>> them.
> 
> Done, I've changed it. Would you like me to also change the uint64_t's to 
> paddr_t?

To me paddr_t is not better or worse than uint64_t, perhaps with
the slight exception that in a (very old) non-PAE 32-bit build
paddr_t would have been actively wrong.

Jan


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