On 23/01/2019 11:42, Jan Beulich wrote:
>
>> --- a/xen/arch/x86/guest/pvh-boot.c
>> +++ b/xen/arch/x86/guest/pvh-boot.c
>> @@ -123,28 +123,29 @@ void __init pvh_print_info(void)
>> const struct hvm_modlist_entry *entry;
>> unsigned int i;
>>
>> -ASSERT(pvh_info->magic == XEN_HVM_STA
>>> On 21.01.19 at 16:37, wrote:
> The current rendering of PVH start info in unnecessarily verbose, and doesn't
> clearly separate decimal and hex numbers.
As expressed on earlier occasions, I think blindly adding 0x in
all cases goes too far. When context makes sufficiently clear
that it's a he
On Mon, Jan 21, 2019 at 03:37:21PM +, Andrew Cooper wrote:
> The current rendering of PVH start info in unnecessarily verbose, and doesn't
> clearly separate decimal and hex numbers.
>
> All addresses are expected to be below the 4G boundary, so drop 8 redundant
> zeroes on all physical addres
The current rendering of PVH start info in unnecessarily verbose, and doesn't
clearly separate decimal and hex numbers.
All addresses are expected to be below the 4G boundary, so drop 8 redundant
zeroes on all physical addresses. Properly prefix all hex numbers, and fold
related information onto