Re: [Xen-devel] [PATCH v2 1/4] x86/PVHv2: Add memory map pointer to hvm_start_info struct

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 14.03.18 at 18:28, <boris.ostrovsky@xxxxxxxxxx> wrote:
> On 03/14/2018 03:55 AM, Jan Beulich wrote:
>>>>> On 14.03.18 at 00:31, <maran.wilson@xxxxxxxxxx> wrote:
>>> + * For x86 implementations at least, the values used in the type field will
>>> + * match the Address Range Types as defined in section 15 (System Address
>>> + * Map Interfaces) of the ACPI Specification 
>>> (http://uefi.org/specifications)
>>> + * where:
>>> + *     AddressRangeMemory = 1 (E820_RAM)
>>> + *     AddressRangeReserved = 2 (E820_RESERVED)
>>> + *     AddressRangeACPI = 3 (E820_ACPI)
>>> + *     AddressRangeNVS = 4 (E820_NVS)
>>> + *     AddressRangeUnusable = 5 (E820_UNUSABLE)
>>> + *     AddressRangeDisabled = 6 (E820_DISABLED)
>>> + *     AddressRangePersistentMemory = 7 (E820_PMEM)
>> Would you mind waiting for a discussion to settle before sending
>> out new patch versions? As indicated in an earlier reply to v1, I
>> consider this still insufficient. And no, I'm not asking for you to
>> add redundant and potentially conflicting definitions of E820_*,
>> but instead you want to use Xen specific ones (prefixed e.g.
>> by XEN_HVM_MEMMAP_TYPE_).
> 
> Since we will now have a non-Xen user of this interface perhaps
> PVH_MEMMAP_TYPE_ ?

Not really, no. For one I don't think PVH is meaningful to KVM. And
then, this is the canonical Xen header. It's up to the Linux side
customization to use different name prefixes. Just look at the
pvclock interface definitions and how they differ between the
canonical Xen headers and their Linux derivatives.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel