[Xen-devel] Status of 4.13

[Xen-devel] Status of 4.13

[Jürgen Groß]

Where do we stand with Xen 4.13 regarding blockers and related patches?

1. OSStest failure regarding nested test:
    I'm not quite sure whether the currently debated patch of Andrew is
    fixing the problem. If not, do we know what is missing or how to
    address the issue? If yes, could we please come to an agreement?
    As an alternative: any thoughts about ignoring this test failure for
    4.13-RC3 (IOW: doing a force push)?

2. Ryzen/Rome failures with Windows guests:
    What is the currently planned way to address the problem? Who is
    working on that?

3. Pending patches for 4.13:
    Could I please have feedback which patches tagged as "for-4.13" are
    fixing real regressions or issues? I don't want to take any patches
    not fixing real problems after RC3, and I hope to be able to get a
    push rather sooner than later to be able to let Ian cut RC3.

4. Are there any blockers for 4.13 other than 1. and 2. (apart of any
    pending XSAs)?


Juergen

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

Re: [Xen-devel] Status of 4.13

[Steven Haigh]

On 2019-11-21 17:05, Jürgen Groß wrote:
> Where do we stand with Xen 4.13 regarding blockers and related patches?
> 
> 2. Ryzen/Rome failures with Windows guests:
>    What is the currently planned way to address the problem? Who is
>    working on that?

A workaround was found by specifying cpuid values in the Windows VM 
config file.

The workaround line is:
cpuid = [ "0x80000008:ecx=xxxxxxxxxxxxxxxx0100xxxxxxxxxxxx" ]

It was suggested that this be documented - but no immediate action 
should be taken - with a view to correct this properly in 4.14.

I'm not sure the status of any patches / additions to documentation - 
however maybe this is the wiki? I'll leave that for someone else to 
comment on.

-- 
Steven Haigh

? netwiz@crc.id.au     ? http://www.crc.id.au
? +61 (3) 9001 6090    ? 0412 935 897

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

Re: [Xen-devel] Status of 4.13

[Jürgen Groß]

On 21.11.19 08:30, Steven Haigh wrote:
> On 2019-11-21 17:05, Jürgen Groß wrote:
>> Where do we stand with Xen 4.13 regarding blockers and related patches?
>>
>> 2. Ryzen/Rome failures with Windows guests:
>>    What is the currently planned way to address the problem? Who is
>>    working on that?
> 
> A workaround was found by specifying cpuid values in the Windows VM 
> config file.
> 
> The workaround line is:
> cpuid = [ "0x80000008:ecx=xxxxxxxxxxxxxxxx0100xxxxxxxxxxxx" ]
> 
> It was suggested that this be documented - but no immediate action 
> should be taken - with a view to correct this properly in 4.14.

I'm aware of the suggestion, but not of any decision. :-)

> I'm not sure the status of any patches / additions to documentation - 
> however maybe this is the wiki? I'll leave that for someone else to 
> comment on.

I guess this would need to go into the release notes at least.


Juergen


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

Re: [Xen-devel] Status of 4.13

[Jan Beulich]

On 21.11.2019 08:36, Jürgen Groß wrote:
> On 21.11.19 08:30, Steven Haigh wrote:
>> On 2019-11-21 17:05, Jürgen Groß wrote:
>>> Where do we stand with Xen 4.13 regarding blockers and related patches?
>>>
>>> 2. Ryzen/Rome failures with Windows guests:
>>>    What is the currently planned way to address the problem? Who is
>>>    working on that?
>>
>> A workaround was found by specifying cpuid values in the Windows VM 
>> config file.
>>
>> The workaround line is:
>> cpuid = [ "0x80000008:ecx=xxxxxxxxxxxxxxxx0100xxxxxxxxxxxx" ]
>>
>> It was suggested that this be documented - but no immediate action 
>> should be taken - with a view to correct this properly in 4.14.
> 
> I'm aware of the suggestion, but not of any decision. :-)

It was my understanding that we'd cap the 4-bit value to 7 for
the time being. I think George was planning to send a patch.

Jan

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

Re: [Xen-devel] Status of 4.13

[George Dunlap]

> On Nov 21, 2019, at 8:41 AM, Jan Beulich <jbeulich@suse.com> wrote:
> 
> On 21.11.2019 08:36, Jürgen Groß wrote:
>> On 21.11.19 08:30, Steven Haigh wrote:
>>> On 2019-11-21 17:05, Jürgen Groß wrote:
>>>> Where do we stand with Xen 4.13 regarding blockers and related patches?
>>>> 
>>>> 2. Ryzen/Rome failures with Windows guests:
>>>>    What is the currently planned way to address the problem? Who is
>>>>    working on that?
>>> 
>>> A workaround was found by specifying cpuid values in the Windows VM 
>>> config file.
>>> 
>>> The workaround line is:
>>> cpuid = [ "0x80000008:ecx=xxxxxxxxxxxxxxxx0100xxxxxxxxxxxx" ]
>>> 
>>> It was suggested that this be documented - but no immediate action 
>>> should be taken - with a view to correct this properly in 4.14.
>> 
>> I'm aware of the suggestion, but not of any decision. :-)
> 
> It was my understanding that we'd cap the 4-bit value to 7 for
> the time being. I think George was planning to send a patch.

On that also, I’m aware of the suggestion, but not of any decision.  I don’t think I got much feedback, positive or negative, about the idea.

Suppose we implement the limit for 4.13. If someone runs Linux VMs on 4.12 a system with a hardware value of 7 for apic_id_size, the guests will see 8.  If they then migrate to 4.13, the value will magically change under their feet to 7.  Is that OK?

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

Re: [Xen-devel] Status of 4.13

[Jan Beulich]

On 21.11.2019 16:20, George Dunlap wrote:
> 
> 
>> On Nov 21, 2019, at 8:41 AM, Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 21.11.2019 08:36, Jürgen Groß wrote:
>>> On 21.11.19 08:30, Steven Haigh wrote:
>>>> On 2019-11-21 17:05, Jürgen Groß wrote:
>>>>> Where do we stand with Xen 4.13 regarding blockers and related patches?
>>>>>
>>>>> 2. Ryzen/Rome failures with Windows guests:
>>>>>    What is the currently planned way to address the problem? Who is
>>>>>    working on that?
>>>>
>>>> A workaround was found by specifying cpuid values in the Windows VM 
>>>> config file.
>>>>
>>>> The workaround line is:
>>>> cpuid = [ "0x80000008:ecx=xxxxxxxxxxxxxxxx0100xxxxxxxxxxxx" ]
>>>>
>>>> It was suggested that this be documented - but no immediate action 
>>>> should be taken - with a view to correct this properly in 4.14.
>>>
>>> I'm aware of the suggestion, but not of any decision. :-)
>>
>> It was my understanding that we'd cap the 4-bit value to 7 for
>> the time being. I think George was planning to send a patch.
> 
> On that also, I’m aware of the suggestion, but not of any decision.
>  I don’t think I got much feedback, positive or negative, about the idea.
> 
> Suppose we implement the limit for 4.13. If someone runs Linux VMs
> on 4.12 a system with a hardware value of 7 for apic_id_size, the
> guests will see 8.  If they then migrate to 4.13, the value will
> magically change under their feet to 7.  Is that OK?

Let's look at the prereqs for running a Linux (or actually any) VM
on such hardware: At least on dual socket systems with such CPUs
Xen 4.12 wouldn't even boot. I don't know how wide a range of
single socket systems with these 64-code CPUs would exist or
appear down the road.

The workaround before our enabling of x2APIC mode for these boxes
was to disable SMT, which has the side effect of changing said
value to 6.

As to your actual question - as far as Linux goes, I don't think
they re-evaluate this CPUID leaf post boot. But I could be wrong
with this, and of course other OSes might behave differently.

Jan

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

Re: [Xen-devel] Status of 4.13

[George Dunlap]

> On Nov 21, 2019, at 3:34 PM, Jan Beulich <jbeulich@suse.com> wrote:
> 
> On 21.11.2019 16:20, George Dunlap wrote:
>> 
>> 
>>> On Nov 21, 2019, at 8:41 AM, Jan Beulich <jbeulich@suse.com> wrote:
>>> 
>>> On 21.11.2019 08:36, Jürgen Groß wrote:
>>>> On 21.11.19 08:30, Steven Haigh wrote:
>>>>> On 2019-11-21 17:05, Jürgen Groß wrote:
>>>>>> Where do we stand with Xen 4.13 regarding blockers and related patches?
>>>>>> 
>>>>>> 2. Ryzen/Rome failures with Windows guests:
>>>>>>   What is the currently planned way to address the problem? Who is
>>>>>>   working on that?
>>>>> 
>>>>> A workaround was found by specifying cpuid values in the Windows VM 
>>>>> config file.
>>>>> 
>>>>> The workaround line is:
>>>>> cpuid = [ "0x80000008:ecx=xxxxxxxxxxxxxxxx0100xxxxxxxxxxxx" ]
>>>>> 
>>>>> It was suggested that this be documented - but no immediate action 
>>>>> should be taken - with a view to correct this properly in 4.14.
>>>> 
>>>> I'm aware of the suggestion, but not of any decision. :-)
>>> 
>>> It was my understanding that we'd cap the 4-bit value to 7 for
>>> the time being. I think George was planning to send a patch.
>> 
>> On that also, I’m aware of the suggestion, but not of any decision.
>> I don’t think I got much feedback, positive or negative, about the idea.
>> 
>> Suppose we implement the limit for 4.13. If someone runs Linux VMs
>> on 4.12 a system with a hardware value of 7 for apic_id_size, the
>> guests will see 8.  If they then migrate to 4.13, the value will
>> magically change under their feet to 7.  Is that OK?
> 
> Let's look at the prereqs for running a Linux (or actually any) VM
> on such hardware: At least on dual socket systems with such CPUs
> Xen 4.12 wouldn't even boot. I don't know how wide a range of
> single socket systems with these 64-code CPUs would exist or
> appear down the road.
> 
> The workaround before our enabling of x2APIC mode for these boxes
> was to disable SMT, which has the side effect of changing said
> value to 6.

Can you expand on this a bit?  Are you saying that Xen 4.12 couldn’t boot on such a system, and so as long as we limit this in the first Xen release which *can*, we won’t have a backwards compatibility problem?

But I thought Steven had already encountered and fixed this issue on such a system running 4.12 (or something earlier).

> As to your actual question - as far as Linux goes, I don't think
> they re-evaluate this CPUID leaf post boot. But I could be wrong
> with this, and of course other OSes might behave differently.

What I’m not getting here is a recommendation. :-)  I don’t really know what the chances of all these things happening are.

If you think there’s at least a 25% chance of it being approved, I can send a patch to limit the value to 7, and we can discuss it more there (where the patch name will make it more clear what’s being discussed).

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

Re: [Xen-devel] Status of 4.13

[Jan Beulich]

On 21.11.2019 17:03, George Dunlap wrote:
> 
> 
>> On Nov 21, 2019, at 3:34 PM, Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 21.11.2019 16:20, George Dunlap wrote:
>>>
>>>
>>>> On Nov 21, 2019, at 8:41 AM, Jan Beulich <jbeulich@suse.com> wrote:
>>>>
>>>> On 21.11.2019 08:36, Jürgen Groß wrote:
>>>>> On 21.11.19 08:30, Steven Haigh wrote:
>>>>>> On 2019-11-21 17:05, Jürgen Groß wrote:
>>>>>>> Where do we stand with Xen 4.13 regarding blockers and related patches?
>>>>>>>
>>>>>>> 2. Ryzen/Rome failures with Windows guests:
>>>>>>>   What is the currently planned way to address the problem? Who is
>>>>>>>   working on that?
>>>>>>
>>>>>> A workaround was found by specifying cpuid values in the Windows VM 
>>>>>> config file.
>>>>>>
>>>>>> The workaround line is:
>>>>>> cpuid = [ "0x80000008:ecx=xxxxxxxxxxxxxxxx0100xxxxxxxxxxxx" ]
>>>>>>
>>>>>> It was suggested that this be documented - but no immediate action 
>>>>>> should be taken - with a view to correct this properly in 4.14.
>>>>>
>>>>> I'm aware of the suggestion, but not of any decision. :-)
>>>>
>>>> It was my understanding that we'd cap the 4-bit value to 7 for
>>>> the time being. I think George was planning to send a patch.
>>>
>>> On that also, I’m aware of the suggestion, but not of any decision.
>>> I don’t think I got much feedback, positive or negative, about the idea.
>>>
>>> Suppose we implement the limit for 4.13. If someone runs Linux VMs
>>> on 4.12 a system with a hardware value of 7 for apic_id_size, the
>>> guests will see 8.  If they then migrate to 4.13, the value will
>>> magically change under their feet to 7.  Is that OK?
>>
>> Let's look at the prereqs for running a Linux (or actually any) VM
>> on such hardware: At least on dual socket systems with such CPUs
>> Xen 4.12 wouldn't even boot. I don't know how wide a range of
>> single socket systems with these 64-code CPUs would exist or
>> appear down the road.
>>
>> The workaround before our enabling of x2APIC mode for these boxes
>> was to disable SMT, which has the side effect of changing said
>> value to 6.
> 
> Can you expand on this a bit?  Are you saying that Xen 4.12
> couldn’t boot on such a system, and so as long as we limit this
> in the first Xen release which *can*, we won’t have a backwards
> compatibility problem?
> 
> But I thought Steven had already encountered and fixed this issue
> on such a system running 4.12 (or something earlier).

Looks like I was mis-remembering - indeed Andreas posted such
CPUID output (despite this apparently only having been an 8-core
chip).

>> As to your actual question - as far as Linux goes, I don't think
>> they re-evaluate this CPUID leaf post boot. But I could be wrong
>> with this, and of course other OSes might behave differently.
> 
> What I’m not getting here is a recommendation. :-)  I don’t really
> know what the chances of all these things happening are.

Nor do I. My _guess_ is it shouldn't upset any guest.

> If you think there’s at least a 25% chance of it being approved,
> I can send a patch to limit the value to 7, and we can discuss
> it more there (where the patch name will make it more clear
> what’s being discussed).

Since we're looking for a preferably cheap and simple workaround
rather an actual solution, I think such a patch has higher than
25% probability of getting approved.

Jan

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

Re: [Xen-devel] Status of 4.13

[Jan Beulich]

On 21.11.2019 07:05, Jürgen Groß wrote:
> Where do we stand with Xen 4.13 regarding blockers and related patches?
> 
> 1. OSStest failure regarding nested test:
>     I'm not quite sure whether the currently debated patch of Andrew is
>     fixing the problem. If not, do we know what is missing or how to
>     address the issue? If yes, could we please come to an agreement?
>     As an alternative: any thoughts about ignoring this test failure for
>     4.13-RC3 (IOW: doing a force push)?

I'd recommend against doing so, in particular seeing that all stable
trees are also affected.

Andrew's patch may end up being a prereq to the full fix, but this
looks to not be entirely clear yet at this point. (I'm having a
hard time seeing a fair solution without this change.)

> 2. Ryzen/Rome failures with Windows guests:
>     What is the currently planned way to address the problem? Who is
>     working on that?
> 
> 3. Pending patches for 4.13:
>     Could I please have feedback which patches tagged as "for-4.13" are
>     fixing real regressions or issues? I don't want to take any patches
>     not fixing real problems after RC3, and I hope to be able to get a
>     push rather sooner than later to be able to let Ian cut RC3.

According to my list it's
AMD/IOMMU: re-work mode updating [regression]
build: provide option to disambiguate symbol names [issue]
x86/vmx: always sync PIR to IRR before vmentry [issue]

The last one, according to my records, will need at least one more
revision.

Andrew did also indicate he'd see "x86: explicitly disallow guest
access to PPIN" as something that should go in for 4.13, but there
looks to have been too little attention/progress there.

> 4. Are there any blockers for 4.13 other than 1. and 2. (apart of any
>     pending XSAs)?

"Latest development (master) Xen fails to boot on HP ProLiant DL20 GEN10"

Jan

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

Re: [Xen-devel] Status of 4.13

[Roger Pau Monné]

On Thu, Nov 21, 2019 at 09:53:44AM +0100, Jan Beulich wrote:
> On 21.11.2019 07:05, Jürgen Groß wrote:
> > Where do we stand with Xen 4.13 regarding blockers and related patches?
> > 
> > 1. OSStest failure regarding nested test:
> >     I'm not quite sure whether the currently debated patch of Andrew is
> >     fixing the problem. If not, do we know what is missing or how to
> >     address the issue? If yes, could we please come to an agreement?
> >     As an alternative: any thoughts about ignoring this test failure for
> >     4.13-RC3 (IOW: doing a force push)?
> 
> I'd recommend against doing so, in particular seeing that all stable
> trees are also affected.
> 
> Andrew's patch may end up being a prereq to the full fix, but this
> looks to not be entirely clear yet at this point. (I'm having a
> hard time seeing a fair solution without this change.)
> 
> > 2. Ryzen/Rome failures with Windows guests:
> >     What is the currently planned way to address the problem? Who is
> >     working on that?
> > 
> > 3. Pending patches for 4.13:
> >     Could I please have feedback which patches tagged as "for-4.13" are
> >     fixing real regressions or issues? I don't want to take any patches
> >     not fixing real problems after RC3, and I hope to be able to get a
> >     push rather sooner than later to be able to let Ian cut RC3.
> 
> According to my list it's
> AMD/IOMMU: re-work mode updating [regression]
> build: provide option to disambiguate symbol names [issue]
> x86/vmx: always sync PIR to IRR before vmentry [issue]

Will ping Kevin now for feedback on the above.

I think:

x86/vlapic: allow setting APIC_SPIV_FOCUS_DISABLED in x2APIC mode [0]

Should also be considered, since it's an issue.

Thanks, Roger.

[0] https://lists.xenproject.org/archives/html/xen-devel/2019-11/msg01153.html

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

Re: [Xen-devel] Status of 4.13

[Wei Liu]

On Thu, 21 Nov 2019 at 06:05, Jürgen Groß <jgross@suse.com> wrote:
[...]
> 4. Are there any blockers for 4.13 other than 1. and 2. (apart of any
>     pending XSAs)?
>

FWIW I've pushed all the toolstack patches that I'm aware of.

Wei.

>
> Juergen

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

Re: [Xen-devel] Status of 4.13

[Ian Jackson]

Wei Liu writes ("Re: Status of 4.13"):
> FWIW I've pushed all the toolstack patches that I'm aware of.

The only thing outstanding that I am aware of is
 [PATCH for-4.13 v1 1/2] libxl: introduce new backend type VINPUT
of which I am awaiting a respin from Oleksandr Grytsov (in the To).

There is a new defect in the 4.13 API, where a particular enum has the
value `linux' for a non-Linux-specific protocol.  I'm wanting to
change it and I think we have agreed a name change to `pv'.  Oleksandr
was going to take care of that in his respin of that small 2-patch
series.

Oleksandr, when do you think you will be able to do your respin ?
I am not sure I know exactly what you were planning to do but if you
are not available I could have a go at it.  Please let me know ASAP.

Ian.

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

Re: [Xen-devel] Status of 4.13

[Oleksandr Grytsov]

On Thu, Nov 21, 2019 at 4:16 PM Ian Jackson <ian.jackson@citrix.com> wrote:
>
> Wei Liu writes ("Re: Status of 4.13"):
> > FWIW I've pushed all the toolstack patches that I'm aware of.
>
> The only thing outstanding that I am aware of is
>  [PATCH for-4.13 v1 1/2] libxl: introduce new backend type VINPUT
> of which I am awaiting a respin from Oleksandr Grytsov (in the To).
>
> There is a new defect in the 4.13 API, where a particular enum has the
> value `linux' for a non-Linux-specific protocol.  I'm wanting to
> change it and I think we have agreed a name change to `pv'.  Oleksandr
> was going to take care of that in his respin of that small 2-patch
> series.
>
> Oleksandr, when do you think you will be able to do your respin ?
> I am not sure I know exactly what you were planning to do but if you
> are not available I could have a go at it.  Please let me know ASAP.
>
> Ian.

The patches is ready, I'll submit them today soon.


-- 
Best Regards,
Oleksandr Grytsov.

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

Re: [Xen-devel] Status of 4.13

[Andrew Cooper]

On 21/11/2019 06:05, Jürgen Groß wrote:
> Where do we stand with Xen 4.13 regarding blockers and related patches?
>
> 1. OSStest failure regarding nested test:
>    I'm not quite sure whether the currently debated patch of Andrew is
>    fixing the problem. If not, do we know what is missing or how to
>    address the issue? If yes, could we please come to an agreement?
>    As an alternative: any thoughts about ignoring this test failure for
>    4.13-RC3 (IOW: doing a force push)?

Bare in mind that the answer to this question isn't for 4.13.  It is for
XSA-304 in general, across all the security supported trees.

Nested virt is experimental, with no support or security support, has
known/suspected privilege escalation holes to L0 in, and is unusable
broken outside of the corner case that OSS tests (where Xen and its
nested self make identical decisions given similar inputs).

The only leg OSSTest has to stand on here is "we shouldn't regress
functionality" which is fair enough in principle, but not in line with
the level of support we offer on experimental features.

That said, I as well as plenty of others do use nested virt even if only
for development purposes, and I'd prefer not to see it regressed.  After
several days of working on the issue, the patch I posed is for one
definite bug in nested pagewalking, and as far as I'm concerned, it
stands on its own merit.

It doesn't fix the regression, and I can't find a feasible way of doing
so in a manner which would be appropriate to re-issue in XSA-304. 
nestedhap_walk_L0_p2m() in its current form is simply not fit for purpose.

Upon writing this, one other alternative has presented itself.  Don't
use NX superpages for guests with nested virt enabled.  The L1
hypervisor is already capable of doing worse than DoS'ing the host, so
the overall security is not reduced by this approach.

> 3. Pending patches for 4.13:
>    Could I please have feedback which patches tagged as "for-4.13" are
>    fixing real regressions or issues? I don't want to take any patches
>    not fixing real problems after RC3, and I hope to be able to get a
>    push rather sooner than later to be able to let Ian cut RC3.

Of ones not already identified in various threads,

"x86/livepatch: Prevent patching with active waitqueues".  This is a
fully reviewed bugfix waiting for a release ack.  Patches 1 and 2 in the
series are independent, and 2 is the important one.

"xen: Drop bogus BOOLEAN definitions, TRUE and FALSE".  I need to check
where the next actions lie here.

"xen/vcpu: Sanitise VCPUOP_initialise call hierachy".  This is XSA-296
followup and RFC for-4.13 with no comments for/against.  This has also
stalled with no acks, no concrete suggestion for changes or ways forward.

>
> 4. Are there any blockers for 4.13 other than 1. and 2. (apart of any
>    pending XSAs)?

I still need to refresh the shim config, to at least disable tracebuffer
functionality as it is now selectable and not usable.  I think there is
a lurking makefile race condition.

Also some docs patches (licensing in particular) but that can wait until
other fixes are sorted.

~Andrew

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

Re: [Xen-devel] Status of 4.13

[Jan Beulich]

On 21.11.2019 17:20, Andrew Cooper wrote:
> "xen/vcpu: Sanitise VCPUOP_initialise call hierachy".  This is XSA-296
> followup and RFC for-4.13 with no comments for/against.  This has also
> stalled with no acks, no concrete suggestion for changes or ways forward.

On the 4th I replied

"I can see the merits of this, but I can also understand Julien's
 reservations. Hence I guess whether to ack this will depend on the
 discussion with him getting settled."

I don't really want to ack a patch where it's not clear whether
concerns have been addressed. From Julien's latest reply I can't
judge where he was happy with your prior answer; it more looked
like that he wasn't.

Jan


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

Re: [Xen-devel] Status of 4.13

[Roman Shaposhnik]

On Wed, Nov 20, 2019 at 10:06 PM Jürgen Groß <jgross@suse.com> wrote:
>
> Where do we stand with Xen 4.13 regarding blockers and related patches?
>
> 1. OSStest failure regarding nested test:
>     I'm not quite sure whether the currently debated patch of Andrew is
>     fixing the problem. If not, do we know what is missing or how to
>     address the issue? If yes, could we please come to an agreement?
>     As an alternative: any thoughts about ignoring this test failure for
>     4.13-RC3 (IOW: doing a force push)?
>
> 2. Ryzen/Rome failures with Windows guests:
>     What is the currently planned way to address the problem? Who is
>     working on that?
>
> 3. Pending patches for 4.13:
>     Could I please have feedback which patches tagged as "for-4.13" are
>     fixing real regressions or issues? I don't want to take any patches
>     not fixing real problems after RC3, and I hope to be able to get a
>     push rather sooner than later to be able to let Ian cut RC3.
>
> 4. Are there any blockers for 4.13 other than 1. and 2. (apart of any
>     pending XSAs)?

Any chance the efi=no-rs regression can be added to the list? I understand
that I'm still on the hook to provide more details (I promise to do it on Fri
when I get to my lab to actually have a serial console on all these boxes).
At the same time this is a pretty serious regression for an entire class of
devices where Xen was perfectly happy even during RC1.

Thanks,
Roman.

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

Re: [Xen-devel] Status of 4.13

[Andrew Cooper]

On 21/11/2019 17:31, Roman Shaposhnik wrote:
> On Wed, Nov 20, 2019 at 10:06 PM Jürgen Groß <jgross@suse.com> wrote:
>> Where do we stand with Xen 4.13 regarding blockers and related patches?
>>
>> 1. OSStest failure regarding nested test:
>>     I'm not quite sure whether the currently debated patch of Andrew is
>>     fixing the problem. If not, do we know what is missing or how to
>>     address the issue? If yes, could we please come to an agreement?
>>     As an alternative: any thoughts about ignoring this test failure for
>>     4.13-RC3 (IOW: doing a force push)?
>>
>> 2. Ryzen/Rome failures with Windows guests:
>>     What is the currently planned way to address the problem? Who is
>>     working on that?
>>
>> 3. Pending patches for 4.13:
>>     Could I please have feedback which patches tagged as "for-4.13" are
>>     fixing real regressions or issues? I don't want to take any patches
>>     not fixing real problems after RC3, and I hope to be able to get a
>>     push rather sooner than later to be able to let Ian cut RC3.
>>
>> 4. Are there any blockers for 4.13 other than 1. and 2. (apart of any
>>     pending XSAs)?
> Any chance the efi=no-rs regression can be added to the list? I understand
> that I'm still on the hook to provide more details (I promise to do it on Fri
> when I get to my lab to actually have a serial console on all these boxes).
> At the same time this is a pretty serious regression for an entire class of
> devices where Xen was perfectly happy even during RC1.

https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=534f9e29ce28580892b3856036b5e5cd805667cc
has been committed.  It is in staging, but not in master yet (because
master is blocked by my regression in 1).

~Andrew

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

Re: [Xen-devel] Status of 4.13

[Roman Shaposhnik]

On Thu, Nov 21, 2019 at 9:38 AM Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>
> On 21/11/2019 17:31, Roman Shaposhnik wrote:
> > On Wed, Nov 20, 2019 at 10:06 PM Jürgen Groß <jgross@suse.com> wrote:
> >> Where do we stand with Xen 4.13 regarding blockers and related patches?
> >>
> >> 1. OSStest failure regarding nested test:
> >>     I'm not quite sure whether the currently debated patch of Andrew is
> >>     fixing the problem. If not, do we know what is missing or how to
> >>     address the issue? If yes, could we please come to an agreement?
> >>     As an alternative: any thoughts about ignoring this test failure for
> >>     4.13-RC3 (IOW: doing a force push)?
> >>
> >> 2. Ryzen/Rome failures with Windows guests:
> >>     What is the currently planned way to address the problem? Who is
> >>     working on that?
> >>
> >> 3. Pending patches for 4.13:
> >>     Could I please have feedback which patches tagged as "for-4.13" are
> >>     fixing real regressions or issues? I don't want to take any patches
> >>     not fixing real problems after RC3, and I hope to be able to get a
> >>     push rather sooner than later to be able to let Ian cut RC3.
> >>
> >> 4. Are there any blockers for 4.13 other than 1. and 2. (apart of any
> >>     pending XSAs)?
> > Any chance the efi=no-rs regression can be added to the list? I understand
> > that I'm still on the hook to provide more details (I promise to do it on Fri
> > when I get to my lab to actually have a serial console on all these boxes).
> > At the same time this is a pretty serious regression for an entire class of
> > devices where Xen was perfectly happy even during RC1.
>
> https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=534f9e29ce28580892b3856036b5e5cd805667cc
> has been committed.  It is in staging, but not in master yet (because
> master is blocked by my regression in 1).

I'll make sure to test it on Fri, but here's where I'm lost -- my
understanding that
activation of this patch requires a special build flag to be passed.
Which means,
we're still very much in a regresses state when it comes to building
out-of-the-box,
no?

Thanks,
Roman.

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

Re: [Xen-devel] Status of 4.13

[Marek Marczykowski-Górecki]

[-- Attachment #1.1: Type: text/plain, Size: 2748 bytes --]

On Thu, Nov 21, 2019 at 11:39:14AM -0800, Roman Shaposhnik wrote:
> On Thu, Nov 21, 2019 at 9:38 AM Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> >
> > On 21/11/2019 17:31, Roman Shaposhnik wrote:
> > > On Wed, Nov 20, 2019 at 10:06 PM Jürgen Groß <jgross@suse.com> wrote:
> > >> Where do we stand with Xen 4.13 regarding blockers and related patches?
> > >>
> > >> 1. OSStest failure regarding nested test:
> > >>     I'm not quite sure whether the currently debated patch of Andrew is
> > >>     fixing the problem. If not, do we know what is missing or how to
> > >>     address the issue? If yes, could we please come to an agreement?
> > >>     As an alternative: any thoughts about ignoring this test failure for
> > >>     4.13-RC3 (IOW: doing a force push)?
> > >>
> > >> 2. Ryzen/Rome failures with Windows guests:
> > >>     What is the currently planned way to address the problem? Who is
> > >>     working on that?
> > >>
> > >> 3. Pending patches for 4.13:
> > >>     Could I please have feedback which patches tagged as "for-4.13" are
> > >>     fixing real regressions or issues? I don't want to take any patches
> > >>     not fixing real problems after RC3, and I hope to be able to get a
> > >>     push rather sooner than later to be able to let Ian cut RC3.
> > >>
> > >> 4. Are there any blockers for 4.13 other than 1. and 2. (apart of any
> > >>     pending XSAs)?
> > > Any chance the efi=no-rs regression can be added to the list? I understand
> > > that I'm still on the hook to provide more details (I promise to do it on Fri
> > > when I get to my lab to actually have a serial console on all these boxes).
> > > At the same time this is a pretty serious regression for an entire class of
> > > devices where Xen was perfectly happy even during RC1.
> >
> > https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=534f9e29ce28580892b3856036b5e5cd805667cc
> > has been committed.  It is in staging, but not in master yet (because
> > master is blocked by my regression in 1).
> 
> I'll make sure to test it on Fri, but here's where I'm lost -- my
> understanding that
> activation of this patch requires a special build flag to be passed.
> Which means,
> we're still very much in a regresses state when it comes to building
> out-of-the-box,
> no?

No, there are two thing:
1. A bug triggered by efi=no-rs flag - fixed in the above commit
2. A second commit making efi=no-rs unnecessary on some machines - this
is what require build flag (CONFIG_EFI_SET_VIRTUAL_ADDRESS_MAP=y).

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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

Re: [Xen-devel] Status of 4.13

[Roman Shaposhnik]

On Thu, Nov 21, 2019 at 9:38 AM Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>
> On 21/11/2019 17:31, Roman Shaposhnik wrote:
> > On Wed, Nov 20, 2019 at 10:06 PM Jürgen Groß <jgross@suse.com> wrote:
> >> Where do we stand with Xen 4.13 regarding blockers and related patches?
> >>
> >> 1. OSStest failure regarding nested test:
> >>     I'm not quite sure whether the currently debated patch of Andrew is
> >>     fixing the problem. If not, do we know what is missing or how to
> >>     address the issue? If yes, could we please come to an agreement?
> >>     As an alternative: any thoughts about ignoring this test failure for
> >>     4.13-RC3 (IOW: doing a force push)?
> >>
> >> 2. Ryzen/Rome failures with Windows guests:
> >>     What is the currently planned way to address the problem? Who is
> >>     working on that?
> >>
> >> 3. Pending patches for 4.13:
> >>     Could I please have feedback which patches tagged as "for-4.13" are
> >>     fixing real regressions or issues? I don't want to take any patches
> >>     not fixing real problems after RC3, and I hope to be able to get a
> >>     push rather sooner than later to be able to let Ian cut RC3.
> >>
> >> 4. Are there any blockers for 4.13 other than 1. and 2. (apart of any
> >>     pending XSAs)?
> > Any chance the efi=no-rs regression can be added to the list? I understand
> > that I'm still on the hook to provide more details (I promise to do it on Fri
> > when I get to my lab to actually have a serial console on all these boxes).
> > At the same time this is a pretty serious regression for an entire class of
> > devices where Xen was perfectly happy even during RC1.
>
> https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=534f9e29ce28580892b3856036b5e5cd805667cc
> has been committed.  It is in staging, but not in master yet (because
> master is blocked by my regression in 1).

Reporting back after spending some time in the lab today:

1. Good news, the above patch takes care of the regression. I can now
add efi=no-rs
back and Xen boots (and also boots Dom0) on all the boxes involved.

2. Neutral news: Dell product line still requires efi=no-rs and
coredumps without it
(no regression -- that's I started using efi=no-rs to begin with).

3. Bad news: Marek's suggestion didn't work on Dell product line (and yes
I double checked that I built it correctly).

So... when it comes to RC2 regression -- we're all good.

But since we're here anyway -- I'm wondering if anyone would be
interested in helping me figure out why Xen on those Dell boxes coredumps
without efi=no-rs ?

Marek, any chance I can interest you in helping me a bit here? ;-)

Thanks,
Roman.

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

[Xen-devel] UEFI support on Dell boxes (was: Re: Status of 4.13)

[Marek Marczykowski-Górecki]

[-- Attachment #1.1: Type: text/plain, Size: 975 bytes --]

On Fri, Nov 22, 2019 at 10:00:13PM -0800, Roman Shaposhnik wrote:
> 3. Bad news: Marek's suggestion didn't work on Dell product line (and yes
> I double checked that I built it correctly).
> 
> So... when it comes to RC2 regression -- we're all good.
> 
> But since we're here anyway -- I'm wondering if anyone would be
> interested in helping me figure out why Xen on those Dell boxes coredumps
> without efi=no-rs ?
> 
> Marek, any chance I can interest you in helping me a bit here? ;-)

Yes, I am interested in helping with UEFI state there. Do you have by
a chance messages of that crash (without efi=no-rs, but with
EFI_SET_VIRTUAL_ADDRESS_MAP enabled)? Or even a photo if no serial output is
available?

PS trimmed CC list as isn't really 'Status of 4.13' anymore.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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

Re: [Xen-devel] UEFI support on Dell boxes (was: Re: Status of 4.13)

[Roman Shaposhnik]

[-- Attachment #1: Type: text/plain, Size: 1181 bytes --]

On Sun, Nov 24, 2019 at 4:48 PM Marek Marczykowski-Górecki
<marmarek@invisiblethingslab.com> wrote:
>
> On Fri, Nov 22, 2019 at 10:00:13PM -0800, Roman Shaposhnik wrote:
> > 3. Bad news: Marek's suggestion didn't work on Dell product line (and yes
> > I double checked that I built it correctly).
> >
> > So... when it comes to RC2 regression -- we're all good.
> >
> > But since we're here anyway -- I'm wondering if anyone would be
> > interested in helping me figure out why Xen on those Dell boxes coredumps
> > without efi=no-rs ?
> >
> > Marek, any chance I can interest you in helping me a bit here? ;-)
>
> Yes, I am interested in helping with UEFI state there.

Thanks! That's very much appreciated!

Btw, I'll keep CCing xen-devel in case anyone else is interested in
this conversation.

> Do you have by
> a chance messages of that crash (without efi=no-rs, but with
> EFI_SET_VIRTUAL_ADDRESS_MAP enabled)? Or even a photo if no serial output is
> available?

With my awesome soldering skills ;-) I managed to rig a serial console.

Output is attached. Please let me know if you'd like me to run any
other experiments.

Thanks,
Roman.

[-- Attachment #2: xen.txt --]
[-- Type: text/plain, Size: 12359 bytes --]

 Xen 4.13.0-rc
(XEN) Xen version 4.13.0-rc (@) (gcc (Alpine 6.4.0) 6.4.0) debug=y  Tue Nov 26 03:19:38 UTC 2019
(XEN) Latest ChangeSet:
(XEN) build-id: 07aa9f711fe09a91be2588ee7df10d93ebe34c80
(XEN) Bootloader: GRUB 2.03
(XEN) Command line: com1=115200,8n1 console=com1 loglvl=all noreboot dom0_mem=640M,max:640M dom0_max_vcpus=1 dom0_vcpus_pin smt=false
(XEN) Xen image load base address: 0x70e00000
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN) Disc information:
(XEN)  Found 0 MBR signatures
(XEN)  Found 1 EDD information structures
(XEN) EFI RAM map:
(XEN)  0000000000000000 - 000000000003f000 (usable)
(XEN)  000000000003f000 - 0000000000040000 (ACPI NVS)
(XEN)  0000000000040000 - 00000000000a0000 (usable)
(XEN)  0000000000100000 - 0000000020000000 (usable)
(XEN)  0000000020000000 - 0000000020100000 (reserved)
(XEN)  0000000020100000 - 0000000076ccb000 (usable)
(XEN)  0000000076ccb000 - 0000000076d43000 (reserved)
(XEN)  0000000076d43000 - 0000000076d54000 (ACPI data)
(XEN)  0000000076d54000 - 00000000772de000 (ACPI NVS)
(XEN)  00000000772de000 - 00000000775f5000 (reserved)
(XEN)  00000000775f5000 - 00000000775f6000 (usable)
(XEN)  00000000775f6000 - 0000000077638000 (reserved)
(XEN)  0000000077638000 - 00000000789e5000 (usable)
(XEN)  00000000789e5000 - 0000000078ffa000 (reserved)
(XEN)  0000000078ffa000 - 0000000079000000 (usable)
(XEN)  00000000e0000000 - 00000000f0000000 (reserved)
(XEN)  00000000fec00000 - 00000000fec01000 (reserved)
(XEN)  00000000fed01000 - 00000000fed02000 (reserved)
(XEN)  00000000fed03000 - 00000000fed04000 (reserved)
(XEN)  00000000fed08000 - 00000000fed09000 (reserved)
(XEN)  00000000fed0c000 - 00000000fed10000 (reserved)
(XEN)  00000000fed1c000 - 00000000fed1d000 (reserved)
(XEN)  00000000fee00000 - 00000000fee01000 (reserved)
(XEN)  00000000fef00000 - 00000000ff000000 (reserved)
(XEN)  00000000ff900000 - 0000000100000000 (reserved)
(XEN) System RAM: 1919MB (1965176kB)
(XEN) ACPI: RSDP 76D46000, 0024 (r2   DELL)
(XEN) ACPI: XSDT 76D46088, 0094 (r1   DELL     AS09  1072009 AMI     10013)
(XEN) ACPI: FACP 76D52560, 010C (r5   DELL     AS09  1072009 AMI     10013)
(XEN) ACPI: DSDT 76D461B0, C3AF (r2   DELL     AS09  1072009 INTL 20120913)
(XEN) ACPI: FACS 772DDE80, 0040
(XEN) ACPI: APIC 76D52670, 0068 (r3   DELL     AS09  1072009 AMI     10013)
(XEN) ACPI: FPDT 76D526D8, 0044 (r1   DELL     AS09  1072009 AMI     10013)
(XEN) ACPI: FIDT 76D52720, 009C (r1   DELL     AS09  1072009 AMI     10013)
(XEN) ACPI: MCFG 76D527C0, 003C (r1   DELL     AS09  1072009 MSFT       97)
(XEN) ACPI: LPIT 76D52800, 0104 (r1   DELL     AS09        3 VLV2  100000D)
(XEN) ACPI: HPET 76D52908, 0038 (r1   DELL     AS09  1072009 AMI.        5)
(XEN) ACPI: SSDT 76D52940, 0763 (r1   DELL     AS09     3000 INTL 20061109)
(XEN) ACPI: SSDT 76D530A8, 0290 (r1   DELL     AS09     3000 INTL 20061109)
(XEN) ACPI: SSDT 76D53338, 017A (r1   DELL     AS09     3000 INTL 20061109)
(XEN) ACPI: UEFI 76D534B8, 0042 (r1   DELL     AS09        0             0)
(XEN) ACPI: CSRT 76D53500, 014C (r0   DELL     AS09        5 INTL 20120624)
(XEN) ACPI: TPM2 76D53650, 0034 (r3        Tpm2Tabl        1 AMI         0)
(XEN) ACPI: SSDT 76D53688, 00C9 (r1   MSFT  RHPROXY        1 INTL 20120913)
(XEN) No NUMA configuration found
(XEN) Faking a node at 0000000000000000-0000000079000000
(XEN) Domain heap initialised
(XEN) CPU Vendor: Intel, Family 6 (0x6), Model 55 (0x37), Stepping 9 (raw 00030679)
(XEN) SMBIOS 3.0 present.
(XEN) DMI 3.0 present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x408 (32 bits)
(XEN) ACPI: v5 SLEEP INFO: control[0:0], status[0:0]
(XEN) ACPI: SLEEP INFO: pm1x_cnt[1:404,1:0], pm1x_evt[1:400,1:0]
(XEN) ACPI: 32/64X FACS address mismatch in FADT - 772dde80/0000000000000000, using 32
(XEN) ACPI:             wakeup_vec[772dde8c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] enabled)
(XEN) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
(XEN) ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 1, version 32, address 0xfec00000, GSI 0-86
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
(XEN) ACPI: IRQ0 used by override.
(XEN) ACPI: IRQ2 used by override.
(XEN) ACPI: IRQ9 used by override.
(XEN) Enabling APIC mode:  Flat.  Using 1 I/O APICs
(XEN) ACPI: HPET id: 0x8086a201 base: 0xfed00000
(XEN) PCI: MCFG configuration 0: base e0000000 segment 0000 buses 00 - ff
(XEN) PCI: MCFG area at e0000000 reserved in E820
(XEN) PCI: Using MCFG for segment 0000 bus 00-ff
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) SMP: Allowing 2 CPUs (0 hotplug CPUs)
(XEN) IRQ limits: 87 GSI, 609 MSI/MSI-X
(XEN) mce_intel.c:778: MCA Capability: firstbank 0, extended MCE MSR 0, BCAST
(XEN) Thermal monitoring handled by SMI
(XEN) CPU0: Intel machine check reporting enabled
(XEN) traps.c:1589: GPF (0000): ffff82d08042fa34 [init_speculation_mitigations+0xec/0xd5d] -> ffff82d080388627
(XEN) Speculative mitigation facilities:
(XEN)   Hardware features:
(XEN)   Compiled-in support: SHADOW_PAGING
(XEN)   Xen settings: BTI-Thunk N/A, SPEC_CTRL: No, Other: BRANCH_HARDEN
(XEN)   Support for HVM VMs: RSB
(XEN)   Support for PV VMs: RSB
(XEN)   XPTI (64-bit PV only): Dom0 enabled, DomU enabled (without PCID)
(XEN)   PV L1TF shadowing: Dom0 disabled, DomU disabled
(XEN) Using scheduler: SMP Credit Scheduler rev2 (credit2)
(XEN) Initializing Credit2 scheduler
(XEN)  load_precision_shift: 18
(XEN)  load_window_shift: 30
(XEN)  underload_balance_tolerance: 0
(XEN)  overload_balance_tolerance: -3
(XEN)  runqueues arrangement: socket
(XEN)  cap enforcement granularity: 10ms
(XEN) load tracking window length 1073741824 ns
(XEN) Platform timer is 14.318MHz HPET
(XEN) Detected 1333.353 MHz processor.
(XEN) EFI memory map:
(XEN)  0000000000000-0000000007fff type=3 attr=000000000000000f
(XEN)  0000000008000-000000000bfff type=2 attr=000000000000000f
(XEN)  000000000c000-000000002efff type=7 attr=000000000000000f
(XEN)  000000002f000-000000003efff type=2 attr=000000000000000f
(XEN)  000000003f000-000000003ffff type=10 attr=000000000000000f
(XEN)  0000000040000-000000009ffff type=3 attr=000000000000000f
(XEN)  0000000100000-00000008c0fff type=2 attr=000000000000000f
(XEN)  00000008c1000-000000ac58fff type=7 attr=000000000000000f
(XEN)  000000ac59000-000001fffffff type=1 attr=000000000000000f
(XEN)  0000020000000-00000200fffff type=0 attr=000000000000000f
(XEN)  0000020100000-000003ca86fff type=7 attr=000000000000000f
(XEN)  000003ca87000-0000058ffffff type=1 attr=000000000000000f
(XEN)  0000059000000-000005901ffff type=4 attr=000000000000000f
(XEN)  0000059020000-0000070ffffff type=7 attr=000000000000000f
(XEN)  0000071000000-00000713e8fff type=2 attr=000000000000000f
(XEN)  00000713e9000-00000714b7fff type=7 attr=000000000000000f
(XEN)  00000714b8000-0000071687fff type=1 attr=000000000000000f
(XEN)  0000071688000-0000071688fff type=2 attr=000000000000000f
(XEN)  0000071689000-000007168efff type=7 attr=000000000000000f
(XEN)  000007168f000-0000071776fff type=1 attr=000000000000000f
(XEN)  0000071777000-000007655dfff type=4 attr=000000000000000f
(XEN)  000007655e000-00000766dbfff type=7 attr=000000000000000f
(XEN)  00000766dc000-0000076ccafff type=3 attr=000000000000000f
(XEN)  0000076ccb000-0000076d42fff type=0 attr=000000000000000f
(XEN)  0000076d43000-0000076d53fff type=9 attr=000000000000000f
(XEN)  0000076d54000-00000772ddfff type=10 attr=000000000000000f
(XEN)  00000772de000-0000077586fff type=6 attr=800000000000000f
(XEN)  0000077587000-00000775f4fff type=5 attr=800000000000000f
(XEN)  00000775f5000-00000775f5fff type=4 attr=000000000000000f
(XEN)  00000775f6000-0000077637fff type=6 attr=800000000000000f
(XEN)  0000077638000-00000789e4fff type=4 attr=000000000000000f
(XEN)  00000789e5000-0000078ff9fff type=6 attr=800000000000000f
(XEN)  0000078ffa000-0000078ffffff type=4 attr=000000000000000f
(XEN)  00000e0000000-00000efffffff type=11 attr=8000000000000001
(XEN)  00000fec00000-00000fec00fff type=11 attr=8000000000000001
(XEN)  00000fed01000-00000fed01fff type=11 attr=8000000000000001
(XEN)  00000fed03000-00000fed03fff type=11 attr=8000000000000001
(XEN)  00000fed08000-00000fed08fff type=11 attr=8000000000000001
(XEN)  00000fed0c000-00000fed0ffff type=11 attr=8000000000000001
(XEN)  00000fed1c000-00000fed1cfff type=11 attr=8000000000000001
(XEN)  00000fee00000-00000fee00fff type=11 attr=8000000000000001
(XEN)  00000fef00000-00000feffffff type=11 attr=8000000000000001
(XEN)  00000ff900000-00000ffffffff type=11 attr=8000000000000000
(XEN) Unknown cachability for MFNs 0xff900-0xfffff
(XEN) alt table ffff82d08047a1b0 -> ffff82d080488204
(XEN) I/O virtualisation disabled
(XEN) nr_sockets: 1
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using new ACK method
(XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=0 pin2=0
(XEN) TSC deadline timer enabled
(XEN) ----[ Xen-4.13.0-rc  x86_64  debug=y   Not tainted ]----
(XEN) CPU:    0
(XEN) RIP:    e008:[<00000000775e0d21>] 00000000775e0d21
(XEN) RFLAGS: 0000000000010046   CONTEXT: hypervisor
(XEN) rax: 0000000088431fe8   rbx: ffff82d0804afb48   rcx: ffff82d0804afa60
(XEN) rdx: 00000000ff920000   rsi: 00000000ff920000   rdi: 00000000775e4d58
(XEN) rbp: ffff82d0804afc00   rsp: ffff82d0804afa38   r8:  ffff82d0804afb48
(XEN) r9:  0000000000000000   r10: 00000000ff900000   r11: 0000000000020000
(XEN) r12: ffff82d0804afc60   r13: 0000000000000040   r14: 00000000775ce2c0
(XEN) r15: 00000000775cf9e8   cr0: 0000000080050033   cr4: 00000000001006e0
(XEN) cr3: 00000000787c1000   cr2: 00000000ff920020
(XEN) fsb: 0000000000000000   gsb: 0000000000000000   gss: 0000000000000000
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen code around <00000000775e0d21> (00000000775e0d21):
(XEN)  8b 11 45 33 c9 49 8b d8 <4c> 39 5a 20 75 0b 0f b7 42 30 48 8d 4c 10 17 eb
(XEN) Xen stack trace from rsp=ffff82d0804afa38:
(XEN)    00000000775ddb8e 00000000775e4d58 ffff82d0804afa78 ffff82d08025329f
(XEN)    ffff82d0804afa78 00000000ff920000 0000000000020000 00000000ff93fff0
(XEN)    00000000ff930546 00000000ff920060 0000000007f70020 0000000000000000
(XEN)    0000000077739001 0000000000002f88 0000000000000130 ff0082d000000000
(XEN)    0000000100000028 ffff82d0804afb38 ffff82d08022584c ffff82d0804afc60
(XEN)    00000000775e2e73 00000000775da608 ffff82d0804afc70 0000000000000000
(XEN)    0000000000000000 ffffffff00010000 00000000775e2ead ffff82d0802516ee
(XEN)    ffff82d0804afb38 8000000000000003 0000000000000000 0000000000000000
(XEN)    00000000775ddd88 00000000775da610 ffff82d0804afb68 ffff82d0804afc70
(XEN)    ffff82d0804afb78 ffff82d0804afc60 0000000000000096 ffff82d0803f65a7
(XEN)    ffff82d0804afb88 ffff82d0802516ee ffff82d080386851 0000000000000430
(XEN)    0000000000000004 ffff82d080491600 000000000000020c ffff82d0804afc70
(XEN)    00000000775de841 00000000775cf9e8 00000000775d03b5 00000000775ce2c0
(XEN)    0000000000000000 ffff82d0804afc60 ffff82d0804afbf8 0000000000000000
(XEN)    00000000775d0798 ffff82d0804afcb0 0000000000000000 0000000000002022
(XEN)    ffff82d0804afc3c ffff82d0804afc60 ffff82d0804afc80 ffff82d0804916a0
(XEN)    ffff82d0804916e0 0000000000000286 ffff82d0804a0f1e 0000000000100000
(XEN)    ffff82d080201439 000000004fedc7e6 000000004fedc7e6 0000000000000003
(XEN)    ffff82d0804afcf0 000000007129d000 00000000b3044162 0000000000000068
(XEN)    0000000000000200 0000000000cb74ff ffff82d0804afd68 00210900010107dc
(XEN) Xen call trace:
(XEN)    [<00000000775e0d21>] R 00000000775e0d21
(XEN)    [<00000000775ddb8e>] S 00000000775ddb8e
(XEN)    [<0000000000000000>] F 0000000000000000
(XEN)    [<7fffffff00000000>] F 7fffffff00000000
(XEN)
(XEN) Pagetable walk from 00000000ff920020:
(XEN)  L4[0x000] = 00000000787c0063 ffffffffffffffff
(XEN)  L3[0x003] = 0000000071298063 ffffffffffffffff
(XEN)  L2[0x1fc] = 0000000000000000 ffffffffffffffff
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) FATAL PAGE FAULT
(XEN) [error_code=0000]
(XEN) Faulting linear address: 00000000ff920020
(XEN) ****************************************
(XEN)
(XEN) Manual reset required ('noreboot' specified)

[-- Attachment #3: Type: text/plain, Size: 157 bytes --]

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

Re: [Xen-devel] UEFI support on Dell boxes (was: Re: Status of 4.13)

[Marek Marczykowski-Górecki]

[-- Attachment #1.1: Type: text/plain, Size: 2378 bytes --]

On Mon, Nov 25, 2019 at 07:44:03PM -0800, Roman Shaposhnik wrote:
> On Sun, Nov 24, 2019 at 4:48 PM Marek Marczykowski-Górecki
> <marmarek@invisiblethingslab.com> wrote:
> > Do you have by
> > a chance messages of that crash (without efi=no-rs, but with
> > EFI_SET_VIRTUAL_ADDRESS_MAP enabled)? Or even a photo if no serial output is
> > available?
> 
> With my awesome soldering skills ;-) I managed to rig a serial console.
> 
> Output is attached. Please let me know if you'd like me to run any
> other experiments.

Looks helpful, lets try to do something:

>  Xen 4.13.0-rc
> (XEN) Xen version 4.13.0-rc (@) (gcc (Alpine 6.4.0) 6.4.0) debug=y  Tue Nov 26 03:19:38 UTC 2019
> (XEN) Latest ChangeSet:
> (XEN) build-id: 07aa9f711fe09a91be2588ee7df10d93ebe34c80
> (XEN) Bootloader: GRUB 2.03
> (XEN) Command line: com1=115200,8n1 console=com1 loglvl=all noreboot dom0_mem=640M,max:640M dom0_max_vcpus=1 dom0_vcpus_pin smt=false
(...)
> (XEN) EFI memory map:
(...)
> (XEN)  0000077587000-00000775f4fff type=5 attr=800000000000000f

This is code that crashes - runtime services code, so somewhere with
actual UEFI code.

(...)
> (XEN)  00000ff900000-00000ffffffff type=11 attr=8000000000000000
> (XEN) Unknown cachability for MFNs 0xff900-0xfffff

The faulting address is in this range. And because of unknown
cachability, it isn't mapped. Try adding 'efi=attr=uc' to the Xen
cmdline.

(...)

> (XEN) Xen call trace:
> (XEN)    [<00000000775e0d21>] R 00000000775e0d21
> (XEN)    [<00000000775ddb8e>] S 00000000775ddb8e
> (XEN)    [<0000000000000000>] F 0000000000000000
> (XEN)    [<7fffffff00000000>] F 7fffffff00000000
> (XEN)
> (XEN) Pagetable walk from 00000000ff920020:
> (XEN)  L4[0x000] = 00000000787c0063 ffffffffffffffff
> (XEN)  L3[0x003] = 0000000071298063 ffffffffffffffff
> (XEN)  L2[0x1fc] = 0000000000000000 ffffffffffffffff
> (XEN)
> (XEN) ****************************************
> (XEN) Panic on CPU 0:
> (XEN) FATAL PAGE FAULT
> (XEN) [error_code=0000]
> (XEN) Faulting linear address: 00000000ff920020
> (XEN) ****************************************
> (XEN)
> (XEN) Manual reset required ('noreboot' specified)


-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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

Re: [Xen-devel] UEFI support on Dell boxes (was: Re: Status of 4.13)

[Roman Shaposhnik]

[-- Attachment #1: Type: text/plain, Size: 1737 bytes --]

On Mon, Nov 25, 2019 at 7:55 PM Marek Marczykowski-Górecki
<marmarek@invisiblethingslab.com> wrote:
>
> On Mon, Nov 25, 2019 at 07:44:03PM -0800, Roman Shaposhnik wrote:
> > On Sun, Nov 24, 2019 at 4:48 PM Marek Marczykowski-Górecki
> > <marmarek@invisiblethingslab.com> wrote:
> > > Do you have by
> > > a chance messages of that crash (without efi=no-rs, but with
> > > EFI_SET_VIRTUAL_ADDRESS_MAP enabled)? Or even a photo if no serial output is
> > > available?
> >
> > With my awesome soldering skills ;-) I managed to rig a serial console.
> >
> > Output is attached. Please let me know if you'd like me to run any
> > other experiments.
>
> Looks helpful, lets try to do something:
>
> >  Xen 4.13.0-rc
> > (XEN) Xen version 4.13.0-rc (@) (gcc (Alpine 6.4.0) 6.4.0) debug=y  Tue Nov 26 03:19:38 UTC 2019
> > (XEN) Latest ChangeSet:
> > (XEN) build-id: 07aa9f711fe09a91be2588ee7df10d93ebe34c80
> > (XEN) Bootloader: GRUB 2.03
> > (XEN) Command line: com1=115200,8n1 console=com1 loglvl=all noreboot dom0_mem=640M,max:640M dom0_max_vcpus=1 dom0_vcpus_pin smt=false
> (...)
> > (XEN) EFI memory map:
> (...)
> > (XEN)  0000077587000-00000775f4fff type=5 attr=800000000000000f
>
> This is code that crashes - runtime services code, so somewhere with
> actual UEFI code.

Yup -- that was my hunch with adding efi=no-rs option.

> (...)
> > (XEN)  00000ff900000-00000ffffffff type=11 attr=8000000000000000
> > (XEN) Unknown cachability for MFNs 0xff900-0xfffff
>
> The faulting address is in this range. And because of unknown
> cachability, it isn't mapped. Try adding 'efi=attr=uc' to the Xen
> cmdline.

Feels like we're getting exactly the same failure. Log attached.

Thanks,
Roman.

[-- Attachment #2: xen2.txt --]
[-- Type: text/plain, Size: 12371 bytes --]

 Xen 4.13.0-rc
(XEN) Xen version 4.13.0-rc (@) (gcc (Alpine 6.4.0) 6.4.0) debug=y  Tue Nov 26 03:19:38 UTC 2019
(XEN) Latest ChangeSet:
(XEN) build-id: 07aa9f711fe09a91be2588ee7df10d93ebe34c80
(XEN) Bootloader: GRUB 2.03
(XEN) Command line: com1=115200,8n1 console=com1 loglvl=all noreboot efi=attr=uc dom0_mem=640M,max:640M dom0_max_vcpus=1 dom0_vcpus_pin smt=false
(XEN) Xen image load base address: 0x70e00000
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN) Disc information:
(XEN)  Found 0 MBR signatures
(XEN)  Found 1 EDD information structures
(XEN) EFI RAM map:
(XEN)  0000000000000000 - 000000000003f000 (usable)
(XEN)  000000000003f000 - 0000000000040000 (ACPI NVS)
(XEN)  0000000000040000 - 00000000000a0000 (usable)
(XEN)  0000000000100000 - 0000000020000000 (usable)
(XEN)  0000000020000000 - 0000000020100000 (reserved)
(XEN)  0000000020100000 - 0000000076ccb000 (usable)
(XEN)  0000000076ccb000 - 0000000076d43000 (reserved)
(XEN)  0000000076d43000 - 0000000076d54000 (ACPI data)
(XEN)  0000000076d54000 - 00000000772de000 (ACPI NVS)
(XEN)  00000000772de000 - 00000000775f5000 (reserved)
(XEN)  00000000775f5000 - 00000000775f6000 (usable)
(XEN)  00000000775f6000 - 0000000077638000 (reserved)
(XEN)  0000000077638000 - 00000000789e5000 (usable)
(XEN)  00000000789e5000 - 0000000078ffa000 (reserved)
(XEN)  0000000078ffa000 - 0000000079000000 (usable)
(XEN)  00000000e0000000 - 00000000f0000000 (reserved)
(XEN)  00000000fec00000 - 00000000fec01000 (reserved)
(XEN)  00000000fed01000 - 00000000fed02000 (reserved)
(XEN)  00000000fed03000 - 00000000fed04000 (reserved)
(XEN)  00000000fed08000 - 00000000fed09000 (reserved)
(XEN)  00000000fed0c000 - 00000000fed10000 (reserved)
(XEN)  00000000fed1c000 - 00000000fed1d000 (reserved)
(XEN)  00000000fee00000 - 00000000fee01000 (reserved)
(XEN)  00000000fef00000 - 00000000ff000000 (reserved)
(XEN)  00000000ff900000 - 0000000100000000 (reserved)
(XEN) System RAM: 1919MB (1965176kB)
(XEN) ACPI: RSDP 76D46000, 0024 (r2   DELL)
(XEN) ACPI: XSDT 76D46088, 0094 (r1   DELL     AS09  1072009 AMI     10013)
(XEN) ACPI: FACP 76D52560, 010C (r5   DELL     AS09  1072009 AMI     10013)
(XEN) ACPI: DSDT 76D461B0, C3AF (r2   DELL     AS09  1072009 INTL 20120913)
(XEN) ACPI: FACS 772DDE80, 0040
(XEN) ACPI: APIC 76D52670, 0068 (r3   DELL     AS09  1072009 AMI     10013)
(XEN) ACPI: FPDT 76D526D8, 0044 (r1   DELL     AS09  1072009 AMI     10013)
(XEN) ACPI: FIDT 76D52720, 009C (r1   DELL     AS09  1072009 AMI     10013)
(XEN) ACPI: MCFG 76D527C0, 003C (r1   DELL     AS09  1072009 MSFT       97)
(XEN) ACPI: LPIT 76D52800, 0104 (r1   DELL     AS09        3 VLV2  100000D)
(XEN) ACPI: HPET 76D52908, 0038 (r1   DELL     AS09  1072009 AMI.        5)
(XEN) ACPI: SSDT 76D52940, 0763 (r1   DELL     AS09     3000 INTL 20061109)
(XEN) ACPI: SSDT 76D530A8, 0290 (r1   DELL     AS09     3000 INTL 20061109)
(XEN) ACPI: SSDT 76D53338, 017A (r1   DELL     AS09     3000 INTL 20061109)
(XEN) ACPI: UEFI 76D534B8, 0042 (r1   DELL     AS09        0             0)
(XEN) ACPI: CSRT 76D53500, 014C (r0   DELL     AS09        5 INTL 20120624)
(XEN) ACPI: TPM2 76D53650, 0034 (r3        Tpm2Tabl        1 AMI         0)
(XEN) ACPI: SSDT 76D53688, 00C9 (r1   MSFT  RHPROXY        1 INTL 20120913)
(XEN) No NUMA configuration found
(XEN) Faking a node at 0000000000000000-0000000079000000
(XEN) Domain heap initialised
(XEN) CPU Vendor: Intel, Family 6 (0x6), Model 55 (0x37), Stepping 9 (raw 00030679)
(XEN) SMBIOS 3.0 present.
(XEN) DMI 3.0 present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x408 (32 bits)
(XEN) ACPI: v5 SLEEP INFO: control[0:0], status[0:0]
(XEN) ACPI: SLEEP INFO: pm1x_cnt[1:404,1:0], pm1x_evt[1:400,1:0]
(XEN) ACPI: 32/64X FACS address mismatch in FADT - 772dde80/0000000000000000, using 32
(XEN) ACPI:             wakeup_vec[772dde8c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] enabled)
(XEN) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
(XEN) ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 1, version 32, address 0xfec00000, GSI 0-86
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
(XEN) ACPI: IRQ0 used by override.
(XEN) ACPI: IRQ2 used by override.
(XEN) ACPI: IRQ9 used by override.
(XEN) Enabling APIC mode:  Flat.  Using 1 I/O APICs
(XEN) ACPI: HPET id: 0x8086a201 base: 0xfed00000
(XEN) PCI: MCFG configuration 0: base e0000000 segment 0000 buses 00 - ff
(XEN) PCI: MCFG area at e0000000 reserved in E820
(XEN) PCI: Using MCFG for segment 0000 bus 00-ff
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) SMP: Allowing 2 CPUs (0 hotplug CPUs)
(XEN) IRQ limits: 87 GSI, 609 MSI/MSI-X
(XEN) mce_intel.c:778: MCA Capability: firstbank 0, extended MCE MSR 0, BCAST
(XEN) Thermal monitoring handled by SMI
(XEN) CPU0: Intel machine check reporting enabled
(XEN) traps.c:1589: GPF (0000): ffff82d08042fa34 [init_speculation_mitigations+0xec/0xd5d] -> ffff82d080388627
(XEN) Speculative mitigation facilities:
(XEN)   Hardware features:
(XEN)   Compiled-in support: SHADOW_PAGING
(XEN)   Xen settings: BTI-Thunk N/A, SPEC_CTRL: No, Other: BRANCH_HARDEN
(XEN)   Support for HVM VMs: RSB
(XEN)   Support for PV VMs: RSB
(XEN)   XPTI (64-bit PV only): Dom0 enabled, DomU enabled (without PCID)
(XEN)   PV L1TF shadowing: Dom0 disabled, DomU disabled
(XEN) Using scheduler: SMP Credit Scheduler rev2 (credit2)
(XEN) Initializing Credit2 scheduler
(XEN)  load_precision_shift: 18
(XEN)  load_window_shift: 30
(XEN)  underload_balance_tolerance: 0
(XEN)  overload_balance_tolerance: -3
(XEN)  runqueues arrangement: socket
(XEN)  cap enforcement granularity: 10ms
(XEN) load tracking window length 1073741824 ns
(XEN) Platform timer is 14.318MHz HPET
(XEN) Detected 1333.352 MHz processor.
(XEN) EFI memory map:
(XEN)  0000000000000-0000000007fff type=3 attr=000000000000000f
(XEN)  0000000008000-000000000bfff type=2 attr=000000000000000f
(XEN)  000000000c000-000000002efff type=7 attr=000000000000000f
(XEN)  000000002f000-000000003efff type=2 attr=000000000000000f
(XEN)  000000003f000-000000003ffff type=10 attr=000000000000000f
(XEN)  0000000040000-000000009ffff type=3 attr=000000000000000f
(XEN)  0000000100000-00000008c0fff type=2 attr=000000000000000f
(XEN)  00000008c1000-000000ac58fff type=7 attr=000000000000000f
(XEN)  000000ac59000-000001fffffff type=1 attr=000000000000000f
(XEN)  0000020000000-00000200fffff type=0 attr=000000000000000f
(XEN)  0000020100000-000003ca86fff type=7 attr=000000000000000f
(XEN)  000003ca87000-0000058ffffff type=1 attr=000000000000000f
(XEN)  0000059000000-000005901ffff type=4 attr=000000000000000f
(XEN)  0000059020000-0000070ffffff type=7 attr=000000000000000f
(XEN)  0000071000000-00000713e8fff type=2 attr=000000000000000f
(XEN)  00000713e9000-00000714b7fff type=7 attr=000000000000000f
(XEN)  00000714b8000-0000071687fff type=1 attr=000000000000000f
(XEN)  0000071688000-0000071688fff type=2 attr=000000000000000f
(XEN)  0000071689000-000007168efff type=7 attr=000000000000000f
(XEN)  000007168f000-0000071776fff type=1 attr=000000000000000f
(XEN)  0000071777000-000007655dfff type=4 attr=000000000000000f
(XEN)  000007655e000-00000766dbfff type=7 attr=000000000000000f
(XEN)  00000766dc000-0000076ccafff type=3 attr=000000000000000f
(XEN)  0000076ccb000-0000076d42fff type=0 attr=000000000000000f
(XEN)  0000076d43000-0000076d53fff type=9 attr=000000000000000f
(XEN)  0000076d54000-00000772ddfff type=10 attr=000000000000000f
(XEN)  00000772de000-0000077586fff type=6 attr=800000000000000f
(XEN)  0000077587000-00000775f4fff type=5 attr=800000000000000f
(XEN)  00000775f5000-00000775f5fff type=4 attr=000000000000000f
(XEN)  00000775f6000-0000077637fff type=6 attr=800000000000000f
(XEN)  0000077638000-00000789e4fff type=4 attr=000000000000000f
(XEN)  00000789e5000-0000078ff9fff type=6 attr=800000000000000f
(XEN)  0000078ffa000-0000078ffffff type=4 attr=000000000000000f
(XEN)  00000e0000000-00000efffffff type=11 attr=8000000000000001
(XEN)  00000fec00000-00000fec00fff type=11 attr=8000000000000001
(XEN)  00000fed01000-00000fed01fff type=11 attr=8000000000000001
(XEN)  00000fed03000-00000fed03fff type=11 attr=8000000000000001
(XEN)  00000fed08000-00000fed08fff type=11 attr=8000000000000001
(XEN)  00000fed0c000-00000fed0ffff type=11 attr=8000000000000001
(XEN)  00000fed1c000-00000fed1cfff type=11 attr=8000000000000001
(XEN)  00000fee00000-00000fee00fff type=11 attr=8000000000000001
(XEN)  00000fef00000-00000feffffff type=11 attr=8000000000000001
(XEN)  00000ff900000-00000ffffffff type=11 attr=8000000000000000
(XEN) Unknown cachability for MFNs 0xff900-0xfffff
(XEN) alt table ffff82d08047a1b0 -> ffff82d080488204
(XEN) I/O virtualisation disabled
(XEN) nr_sockets: 1
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using new ACK method
(XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=0 pin2=0
(XEN) TSC deadline timer enabled
(XEN) ----[ Xen-4.13.0-rc  x86_64  debug=y   Not tainted ]----
(XEN) CPU:    0
(XEN) RIP:    e008:[<00000000775e0d21>] 00000000775e0d21
(XEN) RFLAGS: 0000000000010046   CONTEXT: hypervisor
(XEN) rax: 0000000088431fe8   rbx: ffff82d0804afb48   rcx: ffff82d0804afa60
(XEN) rdx: 00000000ff920000   rsi: 00000000ff920000   rdi: 00000000775e4d58
(XEN) rbp: ffff82d0804afc00   rsp: ffff82d0804afa38   r8:  ffff82d0804afb48
(XEN) r9:  0000000000000000   r10: 00000000ff900000   r11: 0000000000020000
(XEN) r12: ffff82d0804afc60   r13: 0000000000000040   r14: 00000000775ce2c0
(XEN) r15: 00000000775cf9e8   cr0: 0000000080050033   cr4: 00000000001006e0
(XEN) cr3: 00000000787c1000   cr2: 00000000ff920020
(XEN) fsb: 0000000000000000   gsb: 0000000000000000   gss: 0000000000000000
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen code around <00000000775e0d21> (00000000775e0d21):
(XEN)  8b 11 45 33 c9 49 8b d8 <4c> 39 5a 20 75 0b 0f b7 42 30 48 8d 4c 10 17 eb
(XEN) Xen stack trace from rsp=ffff82d0804afa38:
(XEN)    00000000775ddb8e 00000000775e4d58 ffff82d0804afa78 ffff82d08025329f
(XEN)    ffff82d0804afa78 00000000ff920000 0000000000020000 00000000ff93fff0
(XEN)    00000000ff93f8ee 00000000ff920060 0000000007f70020 0000000000000000
(XEN)    0000000077739001 0000000000002f88 0000000000000130 ff0082d000000000
(XEN)    0000000100000028 ffff82d0804afb38 ffff82d08022584c ffff82d0804afc60
(XEN)    00000000775e2e73 00000000775da608 ffff82d0804afc70 0000000000000000
(XEN)    0000000000000000 ffffffff00010000 00000000775e2ead ffff82d0802516ee
(XEN)    ffff82d0804afb38 8000000000000003 0000000000000000 0000000000000000
(XEN)    00000000775ddd88 00000000775da610 ffff82d0804afb68 ffff82d0804afc70
(XEN)    ffff82d0804afb78 ffff82d0804afc60 0000000000000096 ffff82d0803f65a7
(XEN)    ffff82d0804afb88 ffff82d0802516ee ffff82d080386851 0000000000000430
(XEN)    0000000000000004 ffff82d080491600 000000000000020c ffff82d0804afc70
(XEN)    00000000775de841 00000000775cf9e8 00000000775d03b5 00000000775ce2c0
(XEN)    0000000000000000 ffff82d0804afc60 ffff82d0804afbf8 0000000000000000
(XEN)    00000000775d0798 ffff82d0804afcb0 0000000000000000 0000000000002022
(XEN)    ffff82d0804afc3c ffff82d0804afc60 ffff82d0804afc80 ffff82d0804916a0
(XEN)    ffff82d0804916e0 0000000000000286 ffff82d0804a0f1e 0000000000100000
(XEN)    ffff82d080201439 000000005000e1bb 000000005000e1bb 0000000000000003
(XEN)    ffff82d0804afcf0 000000007129d000 00000000d8dfad90 0000000000000045
(XEN)    0000000000000200 0000000000cb748f ffff82d0804afd68 00270600010107dc
(XEN) Xen call trace:
(XEN)    [<00000000775e0d21>] R 00000000775e0d21
(XEN)    [<00000000775ddb8e>] S 00000000775ddb8e
(XEN)    [<0000000000000000>] F 0000000000000000
(XEN)    [<7fffffff00000000>] F 7fffffff00000000
(XEN)
(XEN) Pagetable walk from 00000000ff920020:
(XEN)  L4[0x000] = 00000000787c0063 ffffffffffffffff
(XEN)  L3[0x003] = 0000000071298063 ffffffffffffffff
(XEN)  L2[0x1fc] = 0000000000000000 ffffffffffffffff
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) FATAL PAGE FAULT
(XEN) [error_code=0000]
(XEN) Faulting linear address: 00000000ff920020
(XEN) ****************************************
(XEN)
(XEN) Manual reset required ('noreboot' specified)

[-- Attachment #3: Type: text/plain, Size: 157 bytes --]

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

Re: [Xen-devel] UEFI support on Dell boxes

[Jan Beulich]

On 26.11.2019 08:02, Roman Shaposhnik wrote:
> On Mon, Nov 25, 2019 at 7:55 PM Marek Marczykowski-Górecki
> <marmarek@invisiblethingslab.com> wrote:
>> On Mon, Nov 25, 2019 at 07:44:03PM -0800, Roman Shaposhnik wrote:
>>> (XEN)  00000ff900000-00000ffffffff type=11 attr=8000000000000000
>>> (XEN) Unknown cachability for MFNs 0xff900-0xfffff
>>
>> The faulting address is in this range. And because of unknown
>> cachability, it isn't mapped. Try adding 'efi=attr=uc' to the Xen
>> cmdline.
> 
> Feels like we're getting exactly the same failure. Log attached.

Clearly the option hasn't been taking effect. Could you please
retry with this fix
https://lists.xenproject.org/archives/html/xen-devel/2019-11/msg01494.html
in place?

Jan

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

Re: [Xen-devel] UEFI support on Dell boxes

[Roman Shaposhnik]

On Tue, Nov 26, 2019 at 12:31 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 26.11.2019 08:02, Roman Shaposhnik wrote:
> > On Mon, Nov 25, 2019 at 7:55 PM Marek Marczykowski-Górecki
> > <marmarek@invisiblethingslab.com> wrote:
> >> On Mon, Nov 25, 2019 at 07:44:03PM -0800, Roman Shaposhnik wrote:
> >>> (XEN)  00000ff900000-00000ffffffff type=11 attr=8000000000000000
> >>> (XEN) Unknown cachability for MFNs 0xff900-0xfffff
> >>
> >> The faulting address is in this range. And because of unknown
> >> cachability, it isn't mapped. Try adding 'efi=attr=uc' to the Xen
> >> cmdline.
> >
> > Feels like we're getting exactly the same failure. Log attached.
>
> Clearly the option hasn't been taking effect. Could you please
> retry with this fix
> https://lists.xenproject.org/archives/html/xen-devel/2019-11/msg01494.html
> in place?

This works very well indeed! I acked it in the patch thread.

Thanks,
Roman.

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

Re: [Xen-devel] UEFI support on Dell boxes (was: Re: Status of 4.13)

[Roman Shaposhnik]

[-- Attachment #1: Type: text/plain, Size: 2507 bytes --]

Hi Marek, after applying Jan's patch I'm making much further progress.
Xen boots fine and Dom0 seems to be OK (more tests are needed tho on
my end).

I'm attaching the logs from Xen and Dom0.

At this point it seems that adding efi=attr=uc is a better option for
these boxes than a wholesale efi=no-rs

Question #1: is this something that EFI_SET_VIRTUAL_ADDRESS_MAP was
supposed to cover by default (so I don't have to add efi=attr=uc)?

Question #2: is there any downside to *always* specifying efi=attr=uc?
Even for servers that, strictly speaking, don't need it?

Thanks,
Roman.

On Mon, Nov 25, 2019 at 11:02 PM Roman Shaposhnik <roman@zededa.com> wrote:
>
> On Mon, Nov 25, 2019 at 7:55 PM Marek Marczykowski-Górecki
> <marmarek@invisiblethingslab.com> wrote:
> >
> > On Mon, Nov 25, 2019 at 07:44:03PM -0800, Roman Shaposhnik wrote:
> > > On Sun, Nov 24, 2019 at 4:48 PM Marek Marczykowski-Górecki
> > > <marmarek@invisiblethingslab.com> wrote:
> > > > Do you have by
> > > > a chance messages of that crash (without efi=no-rs, but with
> > > > EFI_SET_VIRTUAL_ADDRESS_MAP enabled)? Or even a photo if no serial output is
> > > > available?
> > >
> > > With my awesome soldering skills ;-) I managed to rig a serial console.
> > >
> > > Output is attached. Please let me know if you'd like me to run any
> > > other experiments.
> >
> > Looks helpful, lets try to do something:
> >
> > >  Xen 4.13.0-rc
> > > (XEN) Xen version 4.13.0-rc (@) (gcc (Alpine 6.4.0) 6.4.0) debug=y  Tue Nov 26 03:19:38 UTC 2019
> > > (XEN) Latest ChangeSet:
> > > (XEN) build-id: 07aa9f711fe09a91be2588ee7df10d93ebe34c80
> > > (XEN) Bootloader: GRUB 2.03
> > > (XEN) Command line: com1=115200,8n1 console=com1 loglvl=all noreboot dom0_mem=640M,max:640M dom0_max_vcpus=1 dom0_vcpus_pin smt=false
> > (...)
> > > (XEN) EFI memory map:
> > (...)
> > > (XEN)  0000077587000-00000775f4fff type=5 attr=800000000000000f
> >
> > This is code that crashes - runtime services code, so somewhere with
> > actual UEFI code.
>
> Yup -- that was my hunch with adding efi=no-rs option.
>
> > (...)
> > > (XEN)  00000ff900000-00000ffffffff type=11 attr=8000000000000000
> > > (XEN) Unknown cachability for MFNs 0xff900-0xfffff
> >
> > The faulting address is in this range. And because of unknown
> > cachability, it isn't mapped. Try adding 'efi=attr=uc' to the Xen
> > cmdline.
>
> Feels like we're getting exactly the same failure. Log attached.
>
> Thanks,
> Roman.

[-- Attachment #2: xen3.txt --]
[-- Type: text/plain, Size: 38100 bytes --]

(XEN) Xen version 4.13.0-rc (@) (gcc (Alpine 6.4.0) 6.4.0) debug=y  Tue Nov 26 16:59:33 UTC 2019
(XEN) Latest ChangeSet:
(XEN) build-id: 65fa4bd58d340488ec6963bd8ca5418747541fe5
(XEN) Bootloader: GRUB 2.03
(XEN) Command line: com1=115200,8n1 console=com1 efi=attr=uc loglvl=all noreboot dom0_mem=640M,max:640M dom0_max_vcpus=1 dom0_vcpus_pin smt=false
(XEN) Xen image load base address: 0x70e00000
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN) Disc information:
(XEN)  Found 0 MBR signatures
(XEN)  Found 1 EDD information structures
(XEN) EFI RAM map:
(XEN)  0000000000000000 - 000000000003f000 (usable)
(XEN)  000000000003f000 - 0000000000040000 (ACPI NVS)
(XEN)  0000000000040000 - 00000000000a0000 (usable)
(XEN)  0000000000100000 - 0000000020000000 (usable)
(XEN)  0000000020000000 - 0000000020100000 (reserved)
(XEN)  0000000020100000 - 0000000076ccb000 (usable)
(XEN)  0000000076ccb000 - 0000000076d43000 (reserved)
(XEN)  0000000076d43000 - 0000000076d54000 (ACPI data)
(XEN)  0000000076d54000 - 00000000772de000 (ACPI NVS)
(XEN)  00000000772de000 - 00000000775f5000 (reserved)
(XEN)  00000000775f5000 - 00000000775f6000 (usable)
(XEN)  00000000775f6000 - 0000000077638000 (reserved)
(XEN)  0000000077638000 - 00000000789e5000 (usable)
(XEN)  00000000789e5000 - 0000000078ffa000 (reserved)
(XEN)  0000000078ffa000 - 0000000079000000 (usable)
(XEN)  00000000e0000000 - 00000000f0000000 (reserved)
(XEN)  00000000fec00000 - 00000000fec01000 (reserved)
(XEN)  00000000fed01000 - 00000000fed02000 (reserved)
(XEN)  00000000fed03000 - 00000000fed04000 (reserved)
(XEN)  00000000fed08000 - 00000000fed09000 (reserved)
(XEN)  00000000fed0c000 - 00000000fed10000 (reserved)
(XEN)  00000000fed1c000 - 00000000fed1d000 (reserved)
(XEN)  00000000fee00000 - 00000000fee01000 (reserved)
(XEN)  00000000fef00000 - 00000000ff000000 (reserved)
(XEN)  00000000ff900000 - 0000000100000000 (reserved)
(XEN) System RAM: 1919MB (1965176kB)
(XEN) ACPI: RSDP 76D46000, 0024 (r2   DELL)
(XEN) ACPI: XSDT 76D46088, 0094 (r1   DELL     AS09  1072009 AMI     10013)
(XEN) ACPI: FACP 76D52560, 010C (r5   DELL     AS09  1072009 AMI     10013)
(XEN) ACPI: DSDT 76D461B0, C3AF (r2   DELL     AS09  1072009 INTL 20120913)
(XEN) ACPI: FACS 772DDE80, 0040
(XEN) ACPI: APIC 76D52670, 0068 (r3   DELL     AS09  1072009 AMI     10013)
(XEN) ACPI: FPDT 76D526D8, 0044 (r1   DELL     AS09  1072009 AMI     10013)
(XEN) ACPI: FIDT 76D52720, 009C (r1   DELL     AS09  1072009 AMI     10013)
(XEN) ACPI: MCFG 76D527C0, 003C (r1   DELL     AS09  1072009 MSFT       97)
(XEN) ACPI: LPIT 76D52800, 0104 (r1   DELL     AS09        3 VLV2  100000D)
(XEN) ACPI: HPET 76D52908, 0038 (r1   DELL     AS09  1072009 AMI.        5)
(XEN) ACPI: SSDT 76D52940, 0763 (r1   DELL     AS09     3000 INTL 20061109)
(XEN) ACPI: SSDT 76D530A8, 0290 (r1   DELL     AS09     3000 INTL 20061109)
(XEN) ACPI: SSDT 76D53338, 017A (r1   DELL     AS09     3000 INTL 20061109)
(XEN) ACPI: UEFI 76D534B8, 0042 (r1   DELL     AS09        0             0)
(XEN) ACPI: CSRT 76D53500, 014C (r0   DELL     AS09        5 INTL 20120624)
(XEN) ACPI: TPM2 76D53650, 0034 (r3        Tpm2Tabl        1 AMI         0)
(XEN) ACPI: SSDT 76D53688, 00C9 (r1   MSFT  RHPROXY        1 INTL 20120913)
(XEN) No NUMA configuration found
(XEN) Faking a node at 0000000000000000-0000000079000000
(XEN) Domain heap initialised
(XEN) CPU Vendor: Intel, Family 6 (0x6), Model 55 (0x37), Stepping 9 (raw 00030679)
(XEN) SMBIOS 3.0 present.
(XEN) DMI 3.0 present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x408 (32 bits)
(XEN) ACPI: v5 SLEEP INFO: control[0:0], status[0:0]
(XEN) ACPI: SLEEP INFO: pm1x_cnt[1:404,1:0], pm1x_evt[1:400,1:0]
(XEN) ACPI: 32/64X FACS address mismatch in FADT - 772dde80/0000000000000000, using 32
(XEN) ACPI:             wakeup_vec[772dde8c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] enabled)
(XEN) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
(XEN) ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 1, version 32, address 0xfec00000, GSI 0-86
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
(XEN) ACPI: IRQ0 used by override.
(XEN) ACPI: IRQ2 used by override.
(XEN) ACPI: IRQ9 used by override.
(XEN) Enabling APIC mode:  Flat.  Using 1 I/O APICs
(XEN) ACPI: HPET id: 0x8086a201 base: 0xfed00000
(XEN) PCI: MCFG configuration 0: base e0000000 segment 0000 buses 00 - ff
(XEN) PCI: MCFG area at e0000000 reserved in E820
(XEN) PCI: Using MCFG for segment 0000 bus 00-ff
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) SMP: Allowing 2 CPUs (0 hotplug CPUs)
(XEN) IRQ limits: 87 GSI, 609 MSI/MSI-X
(XEN) mce_intel.c:778: MCA Capability: firstbank 0, extended MCE MSR 0, BCAST
(XEN) Thermal monitoring handled by SMI
(XEN) CPU0: Intel machine check reporting enabled
(XEN) traps.c:1589: GPF (0000): ffff82d08042fa34 [init_speculation_mitigations+0xec/0xd5d] -> ffff82d080388627
(XEN) Speculative mitigation facilities:
(XEN)   Hardware features:
(XEN)   Compiled-in support: SHADOW_PAGING
(XEN)   Xen settings: BTI-Thunk N/A, SPEC_CTRL: No, Other: BRANCH_HARDEN
(XEN)   Support for HVM VMs: RSB
(XEN)   Support for PV VMs: RSB
(XEN)   XPTI (64-bit PV only): Dom0 enabled, DomU enabled (without PCID)
(XEN)   PV L1TF shadowing: Dom0 disabled, DomU disabled
(XEN) Using scheduler: SMP Credit Scheduler rev2 (credit2)
(XEN) Initializing Credit2 scheduler
(XEN)  load_precision_shift: 18
(XEN)  load_window_shift: 30
(XEN)  underload_balance_tolerance: 0
(XEN)  overload_balance_tolerance: -3
(XEN)  runqueues arrangement: socket
(XEN)  cap enforcement granularity: 10ms
(XEN) load tracking window length 1073741824 ns
(XEN) Platform timer is 14.318MHz HPET
(XEN) Detected 1333.353 MHz processor.
(XEN) EFI memory map:
(XEN)  0000000000000-0000000007fff type=3 attr=000000000000000f
(XEN)  0000000008000-000000000bfff type=2 attr=000000000000000f
(XEN)  000000000c000-000000002efff type=7 attr=000000000000000f
(XEN)  000000002f000-000000003efff type=2 attr=000000000000000f
(XEN)  000000003f000-000000003ffff type=10 attr=000000000000000f
(XEN)  0000000040000-000000009ffff type=3 attr=000000000000000f
(XEN)  0000000100000-00000008c0fff type=2 attr=000000000000000f
(XEN)  00000008c1000-000000ac58fff type=7 attr=000000000000000f
(XEN)  000000ac59000-000001fffffff type=1 attr=000000000000000f
(XEN)  0000020000000-00000200fffff type=0 attr=000000000000000f
(XEN)  0000020100000-000003ca86fff type=7 attr=000000000000000f
(XEN)  000003ca87000-0000058ffffff type=1 attr=000000000000000f
(XEN)  0000059000000-000005901ffff type=4 attr=000000000000000f
(XEN)  0000059020000-0000070ffffff type=7 attr=000000000000000f
(XEN)  0000071000000-00000713e8fff type=2 attr=000000000000000f
(XEN)  00000713e9000-00000714b7fff type=7 attr=000000000000000f
(XEN)  00000714b8000-0000071687fff type=1 attr=000000000000000f
(XEN)  0000071688000-0000071688fff type=2 attr=000000000000000f
(XEN)  0000071689000-000007168efff type=7 attr=000000000000000f
(XEN)  000007168f000-0000071776fff type=1 attr=000000000000000f
(XEN)  0000071777000-000007655dfff type=4 attr=000000000000000f
(XEN)  000007655e000-00000766dbfff type=7 attr=000000000000000f
(XEN)  00000766dc000-0000076ccafff type=3 attr=000000000000000f
(XEN)  0000076ccb000-0000076d42fff type=0 attr=000000000000000f
(XEN)  0000076d43000-0000076d53fff type=9 attr=000000000000000f
(XEN)  0000076d54000-00000772ddfff type=10 attr=000000000000000f
(XEN)  00000772de000-0000077586fff type=6 attr=800000000000000f
(XEN)  0000077587000-00000775f4fff type=5 attr=800000000000000f
(XEN)  00000775f5000-00000775f5fff type=4 attr=000000000000000f
(XEN)  00000775f6000-0000077637fff type=6 attr=800000000000000f
(XEN)  0000077638000-00000789e4fff type=4 attr=000000000000000f
(XEN)  00000789e5000-0000078ff9fff type=6 attr=800000000000000f
(XEN)  0000078ffa000-0000078ffffff type=4 attr=000000000000000f
(XEN)  00000e0000000-00000efffffff type=11 attr=8000000000000001
(XEN)  00000fec00000-00000fec00fff type=11 attr=8000000000000001
(XEN)  00000fed01000-00000fed01fff type=11 attr=8000000000000001
(XEN)  00000fed03000-00000fed03fff type=11 attr=8000000000000001
(XEN)  00000fed08000-00000fed08fff type=11 attr=8000000000000001
(XEN)  00000fed0c000-00000fed0ffff type=11 attr=8000000000000001
(XEN)  00000fed1c000-00000fed1cfff type=11 attr=8000000000000001
(XEN)  00000fee00000-00000fee00fff type=11 attr=8000000000000001
(XEN)  00000fef00000-00000feffffff type=11 attr=8000000000000001
(XEN)  00000ff900000-00000ffffffff type=11 attr=8000000000000000
(XEN) Unknown cachability for MFNs 0xff900-0xfffff, assuming UC
(XEN) alt table ffff82d08047a1b0 -> ffff82d080488204
(XEN) I/O virtualisation disabled
(XEN) nr_sockets: 1
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using new ACK method
(XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=0 pin2=0
(XEN) TSC deadline timer enabled
(XEN) Allocated console ring of 16 KiB.
(XEN) mwait-idle: MWAIT substates: 0x3000020
(XEN) mwait-idle: v0.4.1 model 0x37
(XEN) mwait-idle: lapic_timer_reliable_states 0xffffffff
(XEN) VMX: Supported advanced features:
(XEN)  - APIC MMIO access virtualisation
(XEN)  - APIC TPR shadow
(XEN)  - Extended Page Tables (EPT)
(XEN)  - Virtual-Processor Identifiers (VPID)
(XEN)  - Virtual NMI
(XEN)  - MSR direct-access bitmap
(XEN)  - Unrestricted Guest
(XEN)  - VM Functions
(XEN) HVM: ASIDs enabled.
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware Assisted Paging (HAP) detected
(XEN) HVM: HAP page sizes: 4kB, 2MB
(XEN) alt table ffff82d08047a1b0 -> ffff82d080488204
(XEN) Brought up 2 CPUs
(XEN) Adding cpu 0 to runqueue 0
(XEN)  First cpu on runqueue, activating
(XEN) Adding cpu 1 to runqueue 0
(XEN) Running stub recovery selftests...
(XEN) traps.c:1589: GPF (0000): ffff82d0bffff041 [ffff82d0bffff041] -> ffff82d0803883f3
(XEN) traps.c:784: Trap 12: ffff82d0bffff040 [ffff82d0bffff040] -> ffff82d0803883f3
(XEN) traps.c:1123: Trap 3: ffff82d0bffff041 [ffff82d0bffff041] -> ffff82d0803883f3
(XEN) mcheck_poll: Machine check polling timer started.
(XEN) Dom0 has maximum 279 PIRQs
(XEN) NX (Execute Disable) protection active
(XEN) *** Building a PV Dom0 ***
(XEN) ELF: phdr: paddr=0x1000000 memsz=0x1102000
(XEN) ELF: phdr: paddr=0x2200000 memsz=0x488000
(XEN) ELF: phdr: paddr=0x2688000 memsz=0x23118
(XEN) ELF: phdr: paddr=0x26ac000 memsz=0x380000
(XEN) ELF: memory: 0x1000000 -> 0x2a2c000
(XEN) ELF: note: GUEST_OS = "linux"
(XEN) ELF: note: GUEST_VERSION = "2.6"
(XEN) ELF: note: XEN_VERSION = "xen-3.0"
(XEN) ELF: note: VIRT_BASE = 0xffffffff80000000
(XEN) ELF: note: INIT_P2M = 0x8000000000
(XEN) ELF: note: ENTRY = 0xffffffff826ac180
(XEN) ELF: note: HYPERCALL_PAGE = 0xffffffff81001000
(XEN) ELF: note: FEATURES = "!writable_page_tables|pae_pgdir_above_4gb"
(XEN) ELF: note: SUPPORTED_FEATURES = 0x8801
(XEN) ELF: note: PAE_MODE = "yes"
(XEN) ELF: note: LOADER = "generic"
(XEN) ELF: note: unknown (0xd)
(XEN) ELF: note: SUSPEND_CANCEL = 0x1
(XEN) ELF: note: MOD_START_PFN = 0x1
(XEN) ELF: note: HV_START_LOW = 0xffff800000000000
(XEN) ELF: note: PADDR_OFFSET = 0
(XEN) ELF: note: PHYS32_ENTRY = 0x1000340
(XEN) ELF: Found PVH image
(XEN) ELF: addresses:
(XEN)     virt_base        = 0xffffffff80000000
(XEN)     elf_paddr_offset = 0x0
(XEN)     virt_offset      = 0xffffffff80000000
(XEN)     virt_kstart      = 0xffffffff81000000
(XEN)     virt_kend        = 0xffffffff82a2c000
(XEN)     virt_entry       = 0xffffffff826ac180
(XEN)     p2m_base         = 0x8000000000
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x2a2c000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   000000006c000000->0000000070000000 (147456 pages to be allocated)
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: ffffffff81000000->ffffffff82a2c000
(XEN)  Init. ramdisk: 0000000000000000->0000000000000000
(XEN)  Phys-Mach map: 0000008000000000->0000008000140000
(XEN)  Start info:    ffffffff82a2c000->ffffffff82a2c4b8
(XEN)  Xenstore ring: 0000000000000000->0000000000000000
(XEN)  Console ring:  0000000000000000->0000000000000000
(XEN)  Page tables:   ffffffff82a2d000->ffffffff82a46000
(XEN)  Boot stack:    ffffffff82a46000->ffffffff82a47000
(XEN)  TOTAL:         ffffffff80000000->ffffffff82c00000
(XEN)  ENTRY ADDRESS: ffffffff826ac180
(XEN) Dom0 has maximum 1 VCPUs
(XEN) ELF: phdr 0 at 0xffffffff81000000 -> 0xffffffff82102000
(XEN) ELF: phdr 1 at 0xffffffff82200000 -> 0xffffffff82688000
(XEN) ELF: phdr 2 at 0xffffffff82688000 -> 0xffffffff826ab118
(XEN) ELF: phdr 3 at 0xffffffff826ac000 -> 0xffffffff8281b000
(XEN) Initial low memory virq threshold set at 0x4000 pages.
(XEN) Scrubbing Free RAM in background
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) *** Serial input to DOM0 (type 'CTRL-a' three times to switch input)
(XEN) Freed 544kB init memory
mapping kernel into physical memory
about to get started...
[    0.000000] Linux version 4.19.5-linuxkit (root@56dc50603780) (gcc version 6.3.0 (Alpine 6.3.0)) #1 SMP Wed Sep 11 20:30:48 UTC 2019
[    0.000000] Command line: console=hvc0 rootdelay=3 root=PARTUUID=b44c9314-6603-40cd-beae-42b10e5b9d14 text
[    0.000000] x86/fpu: x87 FPU will use FXSAVE
[    0.000000] Released 0 page(s)
[    0.000000] BIOS-provided physical RAM map:
[    0.000000] Xen: [mem 0x0000000000000000-0x000000000003efff] usable
[    0.000000] Xen: [mem 0x000000000003f000-0x000000000003ffff] ACPI NVS
[    0.000000] Xen: [mem 0x0000000000040000-0x000000000009ffff] usable
[    0.000000] Xen: [mem 0x00000000000a0000-0x00000000000fffff] reserved
[    0.000000] Xen: [mem 0x0000000000100000-0x000000001fffffff] usable
[    0.000000] Xen: [mem 0x0000000020000000-0x00000000200fffff] reserved
[    0.000000] Xen: [mem 0x0000000020100000-0x0000000028160fff] usable
[    0.000000] Xen: [mem 0x0000000028161000-0x0000000076ccafff] unusable
[    0.000000] Xen: [mem 0x0000000076ccb000-0x0000000076d42fff] reserved
[    0.000000] Xen: [mem 0x0000000076d43000-0x0000000076d53fff] ACPI data
[    0.000000] Xen: [mem 0x0000000076d54000-0x00000000772ddfff] ACPI NVS
[    0.000000] Xen: [mem 0x00000000772de000-0x00000000775f4fff] reserved
[    0.000000] Xen: [mem 0x00000000775f5000-0x00000000775f5fff] unusable
[    0.000000] Xen: [mem 0x00000000775f6000-0x0000000077637fff] reserved
[    0.000000] Xen: [mem 0x0000000077638000-0x00000000789e4fff] unusable
[    0.000000] Xen: [mem 0x00000000789e5000-0x0000000078ff9fff] reserved
[    0.000000] Xen: [mem 0x0000000078ffa000-0x0000000078ffffff] unusable
[    0.000000] Xen: [mem 0x00000000e0000000-0x00000000efffffff] reserved
[    0.000000] Xen: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
[    0.000000] Xen: [mem 0x00000000fed01000-0x00000000fed01fff] reserved
[    0.000000] Xen: [mem 0x00000000fed03000-0x00000000fed03fff] reserved
[    0.000000] Xen: [mem 0x00000000fed08000-0x00000000fed08fff] reserved
[    0.000000] Xen: [mem 0x00000000fed0c000-0x00000000fed0ffff] reserved
[    0.000000] Xen: [mem 0x00000000fed1c000-0x00000000fed1cfff] reserved
[    0.000000] Xen: [mem 0x00000000fee00000-0x00000000feffffff] reserved
[    0.000000] Xen: [mem 0x00000000ff900000-0x00000000ffffffff] reserved
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] efi: EFI v2.40 by American Megatrends
[    0.000000] efi:  ACPI=0x76d46000  ACPI 2.0=0x76d46000  SMBIOS=0xf05b0  ESRT=0x7748b598  MPS=0xfd640
[    0.000000] SMBIOS 3.0 present.
[    0.000000] DMI: Dell Inc. Edge Gateway 3001/0DY2CV, BIOS 01.00.01 05/16/2017
[    0.000000] Hypervisor detected: Xen PV
[    0.000494] tsc: Detected 1333.353 MHz processor
[    0.001406] last_pfn = 0x28161 max_arch_pfn = 0x400000000
[    0.001411] Disabled
[    0.001416] x86/PAT: MTRRs disabled, skipping PAT initialization too.
[    0.001430] x86/PAT: Configuration [0-7]: WB  WT  UC- UC  WC  WP  UC  UC
[    0.001565] Kernel/User page tables isolation: disabled on XEN PV.
[    0.528038] Secure boot disabled
[    0.528074] ACPI: Early table checksum verification disabled
[    0.528101] ACPI: RSDP 0x0000000076D46000 000024 (v02 DELL  )
[    0.528133] ACPI: XSDT 0x0000000076D46088 000094 (v01 DELL   AS09     01072009 AMI  00010013)
[    0.528199] ACPI: FACP 0x0000000076D52560 00010C (v05 DELL   AS09     01072009 AMI  00010013)
[    0.528274] ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe0Block: 128/32 (20180810/tbfadt-569)
[    0.528318] ACPI: DSDT 0x0000000076D461B0 00C3AF (v02 DELL   AS09     01072009 INTL 20120913)
[    0.528361] ACPI: FACS 0x00000000772DDE80 000040
[    0.528403] ACPI: APIC 0x0000000076D52670 000068 (v03 DELL   AS09     01072009 AMI  00010013)
[    0.528445] ACPI: FPDT 0x0000000076D526D8 000044 (v01 DELL   AS09     01072009 AMI  00010013)
[    0.528488] ACPI: FIDT 0x0000000076D52720 00009C (v01 DELL   AS09     01072009 AMI  00010013)
[    0.528531] ACPI: MCFG 0x0000000076D527C0 00003C (v01 DELL   AS09     01072009 MSFT 00000097)
[    0.528575] ACPI: LPIT 0x0000000076D52800 000104 (v01 DELL   AS09     00000003 VLV2 0100000D)
[    0.528618] ACPI: HPET 0x0000000076D52908 000038 (v01 DELL   AS09     01072009 AMI. 00000005)
[    0.528661] ACPI: SSDT 0x0000000076D52940 000763 (v01 DELL   AS09     00003000 INTL 20061109)
[    0.528705] ACPI: SSDT 0x0000000076D530A8 000290 (v01 DELL   AS09     00003000 INTL 20061109)
[    0.528748] ACPI: SSDT 0x0000000076D53338 00017A (v01 DELL   AS09     00003000 INTL 20061109)
[    0.528792] ACPI: UEFI 0x0000000076D534B8 000042 (v01 DELL   AS09     00000000      00000000)
[    0.528835] ACPI: CSRT 0x0000000076D53500 00014C (v00 DELL   AS09     00000005 INTL 20120624)
[    0.528877] ACPI: TPM2 0x0000000076D53650 000034 (v03        Tpm2Tabl 00000001 AMI  00000000)
[    0.528920] ACPI: SSDT 0x0000000076D53688 0000C9 (v01 MSFT   RHPROXY  00000001 INTL 20120913)
[    0.529026] Setting APIC routing to Xen PV.
[    0.541432] Zone ranges:
[    0.541440]   DMA      [mem 0x0000000000001000-0x0000000000ffffff]
[    0.541448]   DMA32    [mem 0x0000000001000000-0x0000000028160fff]
[    0.541455]   Normal   empty
[    0.541460] Movable zone start for each node
[    0.541464] Early memory node ranges
[    0.541477]   node   0: [mem 0x0000000000001000-0x000000000003efff]
[    0.541482]   node   0: [mem 0x0000000000040000-0x000000000009ffff]
[    0.541488]   node   0: [mem 0x0000000000100000-0x000000001fffffff]
[    0.541493]   node   0: [mem 0x0000000020100000-0x0000000028160fff]
[    0.543615] Reserved but unavailable: 32769 pages
[    0.543623] Initmem setup node 0 [mem 0x0000000000001000-0x0000000028160fff]
[    0.554799] p2m virtual area at (____ptrval____), size is 40000000
[    1.171301] Remapped 353 page(s)
[    1.171351] x86/hpet: Will disable the HPET for this platform because it's not reliable
[    1.172781] ACPI: PM-Timer IO Port: 0x408
[    1.172888] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
[    1.172895] ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
[    1.172953] IOAPIC[0]: apic_id 1, version 32, address 0xfec00000, GSI 0-86
[    1.172982] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    1.172991] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[    1.173038] Using ACPI (MADT) for SMP configuration information
[    1.173056] ACPI: HPET id: 0x8086a201 base: 0xfed00000
[    1.173081] smpboot: Allowing 2 CPUs, 0 hotplug CPUs
[    1.173172] [mem 0x79000000-0xdfffffff] available for PCI devices
[    1.173184] Booting paravirtualized kernel on Xen
[    1.173189] Xen version: 4.13.0-rc (preserve-AD)
[    1.173197] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[    1.541832] random: get_random_bytes called from start_kernel+0x92/0x4be with crng_init=0
[    1.541863] setup_percpu: NR_CPUS:128 nr_cpumask_bits:128 nr_cpu_ids:2 nr_node_ids:1
[    1.542766] percpu: Embedded 45 pages/cpu @(____ptrval____) s143640 r8192 d32488 u1048576
[    1.542972] Built 1 zonelists, mobility grouping on.  Total pages: 161252
[    1.542981] Kernel command line: console=hvc0 rootdelay=3 root=PARTUUID=b44c9314-6603-40cd-beae-42b10e5b9d14 text
[    1.543525] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
[    1.543726] Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
[    1.660202] software IO TLB: mapped [mem 0x22e00000-0x26e00000] (64MB)
[    1.683550] Memory: 545788K/655356K available (12300K kernel code, 1595K rwdata, 3080K rodata, 1588K init, 1940K bss, 109568K reserved, 0K cma-reserved)
[    1.683808] ftrace: allocating 43677 entries in 171 pages
[    1.729166] rcu: Hierarchical RCU implementation.
[    1.729175] rcu: 	RCU restricting CPUs from NR_CPUS=128 to nr_cpu_ids=1.
[    1.729181] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1
[    1.741292] Using NULL legacy PIC
[    1.741303] NR_IRQS: 8448, nr_irqs: 256, preallocated irqs: 0
[    1.741374] xen:events: Using FIFO-based ABI
[    1.742817] Console: colour dummy device 80x25
[    1.743502] console [tty0] enabled
[    1.745307] console [hvc0] enabled
[    1.745339] ACPI: Core revision 20180810
[    1.750131] clocksource: xen: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns
[    1.750188] installing Xen timer for CPU 0
[    1.750468] clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x133831727bd, max_idle_ns: 440795263119 ns
[    1.750694] Calibrating delay loop (skipped), value calculated using timer frequency.. 2666.70 BogoMIPS (lpj=13333530)
[    1.750736] pid_max: default: 32768 minimum: 301
[    1.751209] Security Framework initialized
[    1.751235] Yama: becoming mindful.
[    1.751349] Mount-cache hash table entries: 2048 (order: 2, 16384 bytes)
[    1.751385] Mountpoint-cache hash table entries: 2048 (order: 2, 16384 bytes)
[    1.752207] Last level iTLB entries: 4KB 48, 2MB 0, 4MB 0
[    1.752238] Last level dTLB entries: 4KB 128, 2MB 16, 4MB 16, 1GB 0
[    1.752265] Spectre V2 : Vulnerable: Minimal generic ASM retpoline
[    1.752288] Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch
[    1.908352] Freeing SMP alternatives memory: 24K
[    1.910186] VPMU disabled by hypervisor.
[    1.911147] Performance Events: unsupported p6 CPU model 55 no PMU driver, software events only.
[    1.911460] rcu: Hierarchical SRCU implementation.
[    1.912173] NMI watchdog: Perf NMI watchdog permanently disabled
[    1.912510] smp: Bringing up secondary CPUs ...
[    1.912536] smp: Brought up 1 node, 1 CPU
[    1.912554] smpboot: Max logical packages: 1
[    1.913150] devtmpfs: initialized
[    1.913372] x86/mm: Memory block size: 128MB
[    1.914562] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[    1.914616] futex hash table entries: 256 (order: 2, 16384 bytes)
[    1.914835] pinctrl core: initialized pinctrl subsystem
[    1.915302] NET: Registered protocol family 16
[    1.915375] xen:grant_table: Grant tables using version 1 layout
[    1.915443] Grant table initialized
[    1.915940] audit: initializing netlink subsys (disabled)
[    1.916485] audit: type=2000 audit(1325413524.631:1): state=initialized audit_enabled=0 res=1
[    1.917042] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
[    1.917079] ACPI: bus type PCI registered
[    1.917513] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000)
[    1.917554] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in E820
(XEN) d0: Forcing write emulation on MFNs e0000-effff
[    2.202601] PCI: Using configuration type 1 for base access
[    2.210985] cryptd: max_cpu_qlen set to 1000
[    2.211624] ACPI: Added _OSI(Module Device)
[    2.211654] ACPI: Added _OSI(Processor Device)
[    2.211675] ACPI: Added _OSI(3.0 _SCP Extensions)
[    2.211695] ACPI: Added _OSI(Processor Aggregator Device)
[    2.211718] ACPI: Added _OSI(Linux-Dell-Video)
[    2.211741] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio)
[    2.239571] ACPI: 5 ACPI AML tables successfully acquired and loaded
[    2.251168] ACPI: Dynamic OEM Table Load:
[    2.251211] ACPI: SSDT 0xFFFF888022B4B800 0002B4 (v01 PmRef  Cpu0Ist  00003000 INTL 20061109)
[    2.252308] ACPI: Dynamic OEM Table Load:
[    2.252345] ACPI: SSDT 0xFFFF888022B27000 000433 (v01 PmRef  Cpu0Cst  00003001 INTL 20061109)
[    2.256061] ACPI: Interpreter enabled
[    2.256106] ACPI: (supports S0 S5)
[    2.256126] ACPI: Using IOAPIC for interrupt routing
[    2.256259] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[    2.257927] ACPI: Enabled 6 GPEs in block 00 to 3F
[    2.277631] ACPI: Power Resource [USBC] (on)
[    2.281909] ACPI: Power Resource [PLPE] (on)
[    2.282798] ACPI: Power Resource [PLPE] (on)
[    2.297770] ACPI: Power Resource [CLK0] (on)
[    2.297958] ACPI: Power Resource [CLK1] (on)
[    2.303625] ACPI: Power Resource [FN00] (off)
[    2.305671] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[    2.305718] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
[    2.306339] acpi PNP0A08:00: _OSC: platform does not support [PCIeHotplug SHPCHotplug PME]
[    2.306904] acpi PNP0A08:00: _OSC: OS now controls [PCIeCapability LTR]
[    2.306935] acpi PNP0A08:00: FADT indicates ASPM is unsupported, using BIOS configuration
[    2.307669] PCI host bridge to bus 0000:00
[    2.307700] pci_bus 0000:00: root bus resource [io  0x0070-0x0077]
[    2.307728] pci_bus 0000:00: root bus resource [io  0x0000-0x006f window]
[    2.307755] pci_bus 0000:00: root bus resource [io  0x0078-0x0cf7 window]
[    2.307783] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff window]
[    2.307810] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window]
[    2.307841] pci_bus 0000:00: root bus resource [mem 0x000c0000-0x000dffff window]
[    2.307891] pci_bus 0000:00: root bus resource [mem 0x000e0000-0x000fffff window]
[    2.307922] pci_bus 0000:00: root bus resource [mem 0x80000000-0x80336ffe window]
[    2.307953] pci_bus 0000:00: root bus resource [bus 00-ff]
(XEN) PCI add device 0000:00:00.0
(XEN) PCI add device 0000:00:14.0
(XEN) PCI add device 0000:00:1a.0
(XEN) PCI add device 0000:00:1c.0
(XEN) PCI add device 0000:00:1c.1
(XEN) PCI add device 0000:00:1c.2
(XEN) PCI add device 0000:00:1c.3
(XEN) PCI add device 0000:00:1f.0
(XEN) PCI add device 0000:00:1f.3
[    2.320150] pci 0000:00:1c.0: PCI bridge to [bus 01]
(XEN) PCI add device 0000:02:00.0
[    2.322791] pci 0000:00:1c.1: PCI bridge to [bus 02]
[    2.323169] pci 0000:00:1c.2: PCI bridge to [bus 03]
[    2.323548] pci 0000:00:1c.3: PCI bridge to [bus 04]
[    2.325378] ACPI: PCI Interrupt Link [LNKA] (IRQs *3 4 5 6 12 14 15)
[    2.325650] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 *5 6 12 14 15)
[    2.325913] ACPI: PCI Interrupt Link [LNKC] (IRQs *3 4 5 6 12 14 15)
[    2.326174] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 *5 6 12 14 15)
[    2.326469] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 *5 6 12 14 15)
[    2.326732] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 *5 6 12 14 15)
[    2.326992] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 12 14 15) *0, disabled.
[    2.327259] ACPI: PCI Interrupt Link [LNKH] (IRQs *3 4 5 6 12 14 15)
[    2.340504] xen:balloon: Initialising balloon driver
[    2.341049] SCSI subsystem initialized
[    2.341353] ACPI: bus type USB registered
[    2.341448] usbcore: registered new interface driver usbfs
[    2.341501] usbcore: registered new interface driver hub
[    2.341605] usbcore: registered new device driver usb
[    2.341693] pps_core: LinuxPPS API ver. 1 registered
[    2.341716] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[    2.341758] PTP clock support registered
[    2.341974] Registered efivars operations
[    2.347082] PCI: Using ACPI for IRQ routing
[    2.409398] NetLabel: Initializing
[    2.409425] NetLabel:  domain hash size = 128
[    2.409444] NetLabel:  protocols = UNLABELED CIPSOv4 CALIPSO
[    2.409524] NetLabel:  unlabeled traffic allowed by default
[    2.410004] wmi_bus wmi_bus-PNP0C14:00: WQBC data block query control method not found
[    2.410508] clocksource: Switched to clocksource tsc-early
[    2.468610] VFS: Disk quotas dquot_6.6.0
[    2.468689] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    2.468898] FS-Cache: Loaded
[    2.468921] hugetlbfs: disabling because there are no supported hugepage sizes
[    2.469101] CacheFiles: Loaded
[    2.469194] pnp: PnP ACPI init
[    2.469761] system 00:01: [io  0x0680-0x069f] has been reserved
[    2.469801] system 00:01: [io  0x0400-0x047f] has been reserved
[    2.469830] system 00:01: [io  0x0500-0x05fe] has been reserved
[    2.469857] system 00:01: [io  0x0600-0x061f] has been reserved
[    2.470964] system 00:02: [mem 0xe0000000-0xefffffff] has been reserved
[    2.471004] system 00:02: [mem 0xfed01000-0xfed01fff] has been reserved
[    2.471034] system 00:02: [mem 0xfed03000-0xfed03fff] has been reserved
[    2.471063] system 00:02: [mem 0xfed04000-0xfed04fff] has been reserved
[    2.471094] system 00:02: [mem 0xfed0c000-0xfed0ffff] could not be reserved
[    2.471124] system 00:02: [mem 0xfed08000-0xfed08fff] has been reserved
[    2.471152] system 00:02: [mem 0xfed1c000-0xfed1cfff] has been reserved
[    2.471181] system 00:02: [mem 0xfee00000-0xfeefffff] has been reserved
[    2.471210] system 00:02: [mem 0xfef00000-0xfeffffff] has been reserved
[    2.474685] pnp: PnP ACPI: found 3 devices
[    2.515602] PM-Timer failed consistency check  (0xffffff) - aborting.
[    2.515964] pci 0000:00:1c.0: BAR 14: no space for [mem size 0x00200000]
[    2.515995] pci 0000:00:1c.0: BAR 14: failed to assign [mem size 0x00200000]
[    2.516040] pci 0000:00:1c.0: BAR 15: no space for [mem size 0x00200000 64bit pref]
[    2.516072] pci 0000:00:1c.0: BAR 15: failed to assign [mem size 0x00200000 64bit pref]
[    2.516116] pci 0000:00:1c.1: BAR 15: no space for [mem size 0x00200000 64bit pref]
[    2.516148] pci 0000:00:1c.1: BAR 15: failed to assign [mem size 0x00200000 64bit pref]
[    2.516185] pci 0000:00:1c.2: BAR 14: no space for [mem size 0x00200000]
[    2.516212] pci 0000:00:1c.2: BAR 14: failed to assign [mem size 0x00200000]
[    2.516254] pci 0000:00:1c.2: BAR 15: no space for [mem size 0x00200000 64bit pref]
[    2.516285] pci 0000:00:1c.2: BAR 15: failed to assign [mem size 0x00200000 64bit pref]
[    2.516322] pci 0000:00:1c.3: BAR 14: no space for [mem size 0x00200000]
[    2.516349] pci 0000:00:1c.3: BAR 14: failed to assign [mem size 0x00200000]
[    2.516391] pci 0000:00:1c.3: BAR 15: no space for [mem size 0x00200000 64bit pref]
[    2.516422] pci 0000:00:1c.3: BAR 15: failed to assign [mem size 0x00200000 64bit pref]
[    2.516459] pci 0000:00:1c.0: BAR 13: assigned [io  0x1000-0x1fff]
[    2.516489] pci 0000:00:1c.2: BAR 13: assigned [io  0x2000-0x2fff]
[    2.516519] pci 0000:00:1c.3: BAR 13: assigned [io  0x3000-0x3fff]
[    2.516557] pci 0000:00:1c.3: BAR 14: no space for [mem size 0x00200000]
[    2.516584] pci 0000:00:1c.3: BAR 14: failed to assign [mem size 0x00200000]
[    2.516645] pci 0000:00:1c.3: BAR 15: no space for [mem size 0x00200000 64bit pref]
[    2.516677] pci 0000:00:1c.3: BAR 15: failed to assign [mem size 0x00200000 64bit pref]
[    2.516714] pci 0000:00:1c.2: BAR 14: no space for [mem size 0x00200000]
[    2.516741] pci 0000:00:1c.2: BAR 14: failed to assign [mem size 0x00200000]
[    2.516782] pci 0000:00:1c.2: BAR 15: no space for [mem size 0x00200000 64bit pref]
[    2.516813] pci 0000:00:1c.2: BAR 15: failed to assign [mem size 0x00200000 64bit pref]
[    2.516856] pci 0000:00:1c.1: BAR 15: no space for [mem size 0x00200000 64bit pref]
[    2.516887] pci 0000:00:1c.1: BAR 15: failed to assign [mem size 0x00200000 64bit pref]
[    2.516924] pci 0000:00:1c.0: BAR 14: no space for [mem size 0x00200000]
[    2.516950] pci 0000:00:1c.0: BAR 14: failed to assign [mem size 0x00200000]
[    2.516992] pci 0000:00:1c.0: BAR 15: no space for [mem size 0x00200000 64bit pref]
[    2.517023] pci 0000:00:1c.0: BAR 15: failed to assign [mem size 0x00200000 64bit pref]
[    2.517056] pci 0000:00:1c.0: PCI bridge to [bus 01]
[    2.517093] pci 0000:00:1c.0:   bridge window [io  0x1000-0x1fff]
[    2.517196] pci 0000:00:1c.1: PCI bridge to [bus 02]
[    2.517231] pci 0000:00:1c.1:   bridge window [io  0xd000-0xdfff]
[    2.517285] pci 0000:00:1c.1:   bridge window [mem 0x80200000-0x802fffff]
[    2.517363] pci 0000:00:1c.2: PCI bridge to [bus 03]
[    2.517398] pci 0000:00:1c.2:   bridge window [io  0x2000-0x2fff]
[    2.517498] pci 0000:00:1c.3: PCI bridge to [bus 04]
[    2.517533] pci 0000:00:1c.3:   bridge window [io  0x3000-0x3fff]
[    2.518138] NET: Registered protocol family 2
[    2.518663] tcp_listen_portaddr_hash hash table entries: 512 (order: 1, 8192 bytes)
[    2.518730] TCP established hash table entries: 8192 (order: 4, 65536 bytes)
[    2.518797] TCP bind hash table entries: 8192 (order: 5, 131072 bytes)
[    2.518880] TCP: Hash tables configured (established 8192 bind 8192)
[    2.518997] UDP hash table entries: 512 (order: 2, 16384 bytes)
[    2.519045] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
[    2.519354] NET: Registered protocol family 1
[    2.520796] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x133831727bd, max_idle_ns: 440795263119 ns
[    2.520886] clocksource: Switched to clocksource tsc
[    2.526316] AVX or AES-NI instructions are not detected.
[    2.526349] CPU feature 'AVX registers' is not supported.
[    2.526370] CPU feature 'AVX registers' is not supported.
[    2.526390] CPU feature 'AVX registers' is not supported.
[    2.526410] CPU feature 'AVX registers' is not supported.
[    2.526430] AVX2 or AES-NI instructions are not detected.
[    2.526450] AVX2 instructions are not detected.
[    2.527952] Initialise system trusted keyrings
[    2.528221] workingset: timestamp_bits=46 max_order=18 bucket_order=0
[    2.528939] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    2.529488] FS-Cache: Netfs 'cifs' registered for caching
[    2.529589] fuse init (API version 7.27)
[    2.529927] SGI XFS with ACLs, security attributes, no debug enabled
[    2.531093] 9p: Installing v9fs 9p2000 file system support
[    2.531139] FS-Cache: Netfs '9p' registered for caching
[    2.531174] pstore: using deflate compression
[    2.542446] NET: Registered protocol family 38
[    2.542482] Key type asymmetric registered
[    2.542502] Asymmetric key parser 'x509' registered
[    2.542558] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 248)
[    2.542754] io scheduler noop registered
[    2.542776] io scheduler deadline registered (default)
[    2.542858] io scheduler cfq registered
[    2.542880] io scheduler mq-deadline registered (default)
[    2.542901] io scheduler kyber registered
[    2.545503] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
[    2.545566] hv_vmbus: registering driver hyperv_fb
[    2.546087] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input0
[    2.546174] ACPI: Power Button [PWRB]
[    2.546369] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1
[    2.546490] ACPI: Power Button [PWRF]
[    2.553506] thermal LNXTHERM:00: registered as thermal_zone0
[    2.553545] ACPI: Thermal Zone [TZ01] (40 C)
[    2.554540] xen:xen_evtchn: Event-channel device installed
[    2.554858] xen_pciback: backend is vpci
[    2.555448] xen_acpi_processor: Uploading Xen processor PM info
[    2.559429] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
(XEN) d0: Forcing read-only access to MFN fed00
[    2.561182] Already setup the GSI :8
[    2.561210] hpet: number irqs doesn't agree with number of timers
[    2.561490] Non-volatile memory driver v1.3
[    2.561739] Hangcheck: starting hangcheck timer 0.9.1 (tick is 180 seconds, margin is 60 seconds).
[    2.573094] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0xFE, rev-id 4)
[    2.575833] tpm tpm0: A TPM error (2314) occurred attempting the self test
[    2.624751] loop: module loaded
[    2.637306] Invalid max_queues (4), will use default max: 1.
[    2.638004] VMware PVSCSI driver - version 1.0.7.0-k
[    2.638089] hv_vmbus: registering driver hv_storvsc
[    2.639517] tun: Universal TUN/TAP device driver, 1.6
[    2.639896] VMware vmxnet3 virtual NIC driver - version 1.4.16.0-k-NAPI
[    2.639967] xen_netfront: Initialising Xen virtual ethernet driver
[    2.640083] hv_vmbus: registering driver hv_netvsc
[    2.640108] Fusion MPT base driver 3.04.20
[    2.640126] Copyright (c) 1999-2008 LSI Corporation
[    2.640155] Fusion MPT SPI Host driver 3.04.20
[    2.640229] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    2.640256] ehci-pci: EHCI PCI platform driver
[    2.640310] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    2.640384] ohci-pci: OHCI PCI platform driver
[    2.640443] uhci_hcd: USB Universal Host Controller Interface driver
[    2.640973] Already setup the GSI :20
[    2.641175] xhci_hcd 0000:00:14.0: xHCI Host Controller
[    2.641220] xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 1
[    2.642392] xhci_hcd 0000:00:14.0: hcc params 0x200077c1 hci version 0x100 quirks 0x0000000000009810
[    2.643619] hub 1-0:1.0: USB hub found
[    2.643692] hub 1-0:1.0: 6 ports detected
[    2.645207] xhci_hcd 0000:00:14.0: xHCI Host Controller
[    2.645247] xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 2
[    2.645285] xhci_hcd 0000:00:14.0: Host supports USB 3.0  SuperSpeed
[    2.646039] hub 2-0:1.0: USB hub found
[    2.646104] hub 2-0:1.0: 1 port detected
[    2.646701] usbcore: registered new interface driver usb-storage
[    2.646797] i8042: PNP: No PS/2 controller found.
[    2.646879] hv_vmbus: registering driver hyperv_keyboard
[    2.647180] mousedev: PS/2 mouse device common for all mice

[-- Attachment #3: Type: text/plain, Size: 157 bytes --]

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

Re: [Xen-devel] UEFI support on Dell boxes (was: Re: Status of 4.13)

[Marek Marczykowski-Górecki]

[-- Attachment #1.1: Type: text/plain, Size: 3303 bytes --]

On Tue, Nov 26, 2019 at 09:56:25AM -0800, Roman Shaposhnik wrote:
> Hi Marek, after applying Jan's patch I'm making much further progress.
> Xen boots fine and Dom0 seems to be OK (more tests are needed tho on
> my end).
> 
> I'm attaching the logs from Xen and Dom0.
> 
> At this point it seems that adding efi=attr=uc is a better option for
> these boxes than a wholesale efi=no-rs
> 
> Question #1: is this something that EFI_SET_VIRTUAL_ADDRESS_MAP was
> supposed to cover by default (so I don't have to add efi=attr=uc)?

No, this looks like some different firmware (?) issue.

> Question #2: is there any downside to *always* specifying efi=attr=uc?
> Even for servers that, strictly speaking, don't need it?

TL;DR: It should be fine. It is what Linux does too.

Details:

Lets take a look why 'efi=attr=uc' helps, and how can we make it work
out of the box:

The issue is about memory marked as type=11 (EfiMemoryMappedIO) with
attr=8000000000000000 (EFI_MEMORY_RUNTIME). Indeed none of cachability 
attribute is defined. For the record, defined attributes are (UEFI spec 
.6):

    EFI_MEMORY_UC Memory cacheability attribute: The memory region supports
    being configured as not cacheable.

    EFI_MEMORY_WC Memory cacheability attribute: The memory region supports
    being configured as write combining.

    EFI_MEMORY_WT Memory cacheability attribute: The memory region supports
    being configured as cacheable with a “write through” policy.
    Writes that hit in the cache will also be written to main memory.

    EFI_MEMORY_WB Memory cacheability attribute: The memory region supports
    being configured as cacheable with a “write back” policy. Reads
    and writes that hit in the cache do not propagate to main memory.
    Dirty data is written back to main memory when a new cache line
    is allocated.

    EFI_MEMORY_UCE Memory cacheability attribute: The memory region supports
    being configured as not cacheable, exported, and supports the
    “fetch and add” semaphore mechanism.

My reading of UEFI spec doesn't give much hints what to do with memory
mappings without any cachability attribute. The only related info I've
found is about EfiMemoryMappedIO:

    This memory is not used by the OS. All system memory-mapped IO
    information should come from ACPI tables.

So, maybe there is some more info?

Anyway, if I understand correctly, MMIO region should be mapped as UC,
right?

I've also taken look at what Linux does. And basically, the only bit
Linux care about is EFI_MEMORY_WB - if it's absent, then set the region
as uncachable (page cache disabled bit in page table entry). So,
basically Linux by default does what Xen's efi=attr=uc does.

So, to improve Xen's hardware/firmware compatibility, I have two ideas:

1. Make efi=attr=uc the default (it's still possible to disable it with
efi=attr=no).

2. Map type=11 (MMIO) as UC, unless attributes specify otherwise.

Any preference? I can prepare a patch for either version. But I guess
it's too late for getting it into 4.13.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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

Re: [Xen-devel] UEFI support on Dell boxes (was: Re: Status of 4.13)

[Roman Shaposhnik]

On Tue, Nov 26, 2019 at 10:32 AM Marek Marczykowski-Górecki
<marmarek@invisiblethingslab.com> wrote:
>
> On Tue, Nov 26, 2019 at 09:56:25AM -0800, Roman Shaposhnik wrote:
> > Hi Marek, after applying Jan's patch I'm making much further progress.
> > Xen boots fine and Dom0 seems to be OK (more tests are needed tho on
> > my end).
> >
> > I'm attaching the logs from Xen and Dom0.
> >
> > At this point it seems that adding efi=attr=uc is a better option for
> > these boxes than a wholesale efi=no-rs
> >
> > Question #1: is this something that EFI_SET_VIRTUAL_ADDRESS_MAP was
> > supposed to cover by default (so I don't have to add efi=attr=uc)?
>
> No, this looks like some different firmware (?) issue.
>
> > Question #2: is there any downside to *always* specifying efi=attr=uc?
> > Even for servers that, strictly speaking, don't need it?
>
> TL;DR: It should be fine. It is what Linux does too.
>
> Details:
>
> Lets take a look why 'efi=attr=uc' helps, and how can we make it work
> out of the box:
>
> The issue is about memory marked as type=11 (EfiMemoryMappedIO) with
> attr=8000000000000000 (EFI_MEMORY_RUNTIME). Indeed none of cachability
> attribute is defined. For the record, defined attributes are (UEFI spec
> .6):
>
>     EFI_MEMORY_UC Memory cacheability attribute: The memory region supports
>     being configured as not cacheable.
>
>     EFI_MEMORY_WC Memory cacheability attribute: The memory region supports
>     being configured as write combining.
>
>     EFI_MEMORY_WT Memory cacheability attribute: The memory region supports
>     being configured as cacheable with a “write through” policy.
>     Writes that hit in the cache will also be written to main memory.
>
>     EFI_MEMORY_WB Memory cacheability attribute: The memory region supports
>     being configured as cacheable with a “write back” policy. Reads
>     and writes that hit in the cache do not propagate to main memory.
>     Dirty data is written back to main memory when a new cache line
>     is allocated.
>
>     EFI_MEMORY_UCE Memory cacheability attribute: The memory region supports
>     being configured as not cacheable, exported, and supports the
>     “fetch and add” semaphore mechanism.
>
> My reading of UEFI spec doesn't give much hints what to do with memory
> mappings without any cachability attribute. The only related info I've
> found is about EfiMemoryMappedIO:
>
>     This memory is not used by the OS. All system memory-mapped IO
>     information should come from ACPI tables.
>
> So, maybe there is some more info?
>
> Anyway, if I understand correctly, MMIO region should be mapped as UC,
> right?
>
> I've also taken look at what Linux does. And basically, the only bit
> Linux care about is EFI_MEMORY_WB - if it's absent, then set the region
> as uncachable (page cache disabled bit in page table entry). So,
> basically Linux by default does what Xen's efi=attr=uc does.

Very interesting! Thanks for doing the research.

> So, to improve Xen's hardware/firmware compatibility, I have two ideas:
>
> 1. Make efi=attr=uc the default (it's still possible to disable it with
> efi=attr=no).

I'd be very much in favor of that too (especially since it seems to match
Linux behaviour) What do others think?

> 2. Map type=11 (MMIO) as UC, unless attributes specify otherwise.

This seems to be the subset of the #1 option. As such -- perhaps it
is "safer" than a wholesale efi=attr=uc but at the same time Linux
behaviour gives me pretty good confidence that we should probably
be safe, no?

> Any preference? I can prepare a patch for either version. But I guess
> it's too late for getting it into 4.13.

Good question as well.

Thanks,
Roman.

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

Re: [Xen-devel] UEFI support on Dell boxes (was: Re: Status of 4.13)

[Andrew Cooper]

On 26/11/2019 20:12, Roman Shaposhnik wrote:
> On Tue, Nov 26, 2019 at 10:32 AM Marek Marczykowski-Górecki
> <marmarek@invisiblethingslab.com> wrote:
>> On Tue, Nov 26, 2019 at 09:56:25AM -0800, Roman Shaposhnik wrote:
>>> Hi Marek, after applying Jan's patch I'm making much further progress.
>>> Xen boots fine and Dom0 seems to be OK (more tests are needed tho on
>>> my end).
>>>
>>> I'm attaching the logs from Xen and Dom0.
>>>
>>> At this point it seems that adding efi=attr=uc is a better option for
>>> these boxes than a wholesale efi=no-rs
>>>
>>> Question #1: is this something that EFI_SET_VIRTUAL_ADDRESS_MAP was
>>> supposed to cover by default (so I don't have to add efi=attr=uc)?
>> No, this looks like some different firmware (?) issue.
>>
>>> Question #2: is there any downside to *always* specifying efi=attr=uc?
>>> Even for servers that, strictly speaking, don't need it?
>> TL;DR: It should be fine. It is what Linux does too.
>>
>> Details:
>>
>> Lets take a look why 'efi=attr=uc' helps, and how can we make it work
>> out of the box:
>>
>> The issue is about memory marked as type=11 (EfiMemoryMappedIO) with
>> attr=8000000000000000 (EFI_MEMORY_RUNTIME). Indeed none of cachability
>> attribute is defined. For the record, defined attributes are (UEFI spec
>> .6):
>>
>>     EFI_MEMORY_UC Memory cacheability attribute: The memory region supports
>>     being configured as not cacheable.
>>
>>     EFI_MEMORY_WC Memory cacheability attribute: The memory region supports
>>     being configured as write combining.
>>
>>     EFI_MEMORY_WT Memory cacheability attribute: The memory region supports
>>     being configured as cacheable with a “write through” policy.
>>     Writes that hit in the cache will also be written to main memory.
>>
>>     EFI_MEMORY_WB Memory cacheability attribute: The memory region supports
>>     being configured as cacheable with a “write back” policy. Reads
>>     and writes that hit in the cache do not propagate to main memory.
>>     Dirty data is written back to main memory when a new cache line
>>     is allocated.
>>
>>     EFI_MEMORY_UCE Memory cacheability attribute: The memory region supports
>>     being configured as not cacheable, exported, and supports the
>>     “fetch and add” semaphore mechanism.
>>
>> My reading of UEFI spec doesn't give much hints what to do with memory
>> mappings without any cachability attribute. The only related info I've
>> found is about EfiMemoryMappedIO:
>>
>>     This memory is not used by the OS. All system memory-mapped IO
>>     information should come from ACPI tables.
>>
>> So, maybe there is some more info?
>>
>> Anyway, if I understand correctly, MMIO region should be mapped as UC,
>> right?
>>
>> I've also taken look at what Linux does. And basically, the only bit
>> Linux care about is EFI_MEMORY_WB - if it's absent, then set the region
>> as uncachable (page cache disabled bit in page table entry). So,
>> basically Linux by default does what Xen's efi=attr=uc does.
> Very interesting! Thanks for doing the research.
>
>> So, to improve Xen's hardware/firmware compatibility, I have two ideas:
>>
>> 1. Make efi=attr=uc the default (it's still possible to disable it with
>> efi=attr=no).
> I'd be very much in favor of that too (especially since it seems to match
> Linux behaviour) What do others think?

Its more than just this.  Linux also doesn't use EFI reboot because it
is broken almost everywhere (because Windows doesn't use it because its
broken almost everywhere, so it never gets fixed).

Xen should be following Linux, but I'm exhausted arguing this point.

A consequence is that downstream tend to share a pile of "unbreak Xen on
UEFI" patches which have been rejected upstream on philosophical rather
than technical grounds, despite this being a toxic environment to work in.

~Andrew

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

Re: [Xen-devel] UEFI support on Dell boxes

[Jan Beulich]

On 26.11.2019 21:18, Andrew Cooper wrote:
> On 26/11/2019 20:12, Roman Shaposhnik wrote:
>> On Tue, Nov 26, 2019 at 10:32 AM Marek Marczykowski-Górecki
>>> So, to improve Xen's hardware/firmware compatibility, I have two ideas:
>>>
>>> 1. Make efi=attr=uc the default (it's still possible to disable it with
>>> efi=attr=no).
>> I'd be very much in favor of that too (especially since it seems to match
>> Linux behaviour) What do others think?
> 
> Its more than just this.  Linux also doesn't use EFI reboot because it
> is broken almost everywhere (because Windows doesn't use it because its
> broken almost everywhere, so it never gets fixed).
> 
> Xen should be following Linux, but I'm exhausted arguing this point.

Where it makes sense, yes. But there are cases where it doesn't (we
don't, for example, want to blindly inherit bugs). Nor do I see why
Linux should be the only possible reference. If other OSes work
around issues in a better way than Linux does, why should we follow
Linux rather than such alternative implementation?

> A consequence is that downstream tend to share a pile of "unbreak Xen on
> UEFI" patches which have been rejected upstream on philosophical rather
> than technical grounds, despite this being a toxic environment to work in.

We'll get out of this recurring debate only if you or anyone else
propose to have someone other than me be the UEFI code maintainer.
No matter that you call them philosophical rather than technical
arguments, I continue to be of the firm opinion that workarounds
for all sorts of things are acceptable, but shouldn't impact in
any way systems adhering to standards. (It is probably [bad] luck
that I've not myself been severely impacted by UEFI implementation
issues with any of the boxes I routinely test on.)

Jan

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

Re: [Xen-devel] UEFI support on Dell boxes

[Jan Beulich]

On 26.11.2019 19:32, Marek Marczykowski-Górecki  wrote:
> Anyway, if I understand correctly, MMIO region should be mapped as UC,
> right?

While MMIO typically would want to be UC, there are clearly cases
where they'd better be WC, and there may even be cases where they
want to be WT, WP, or WB. Hence the lack of firmware indication is
a problem even for this specific memory type.

Jan

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

Re: [Xen-devel] Status of 4.13

[Doug Goldstein]

On 11/21/19 12:05 AM, Jürgen Groß wrote:

> Where do we stand with Xen 4.13 regarding blockers and related patches?
>
1. Currently the default "make install" fails with errors in 
tools/tests/x86_emulator if you don't have a new enough GCC. Causing 
failures on distros that are considered still supported based on README.

2. The hypervisor currently fails to build with clang using versions 
that READM says are supported no matter the configuration.

--

Doug


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

Re: [Xen-devel] Status of 4.13

[Wei Liu]

Cc Roger -- you're our resident Clang expert. :-)

On Mon, Nov 25, 2019 at 08:02:17AM -0600, Doug Goldstein wrote:
> On 11/21/19 12:05 AM, Jürgen Groß wrote:
> 
> > Where do we stand with Xen 4.13 regarding blockers and related patches?
> > 
> 1. Currently the default "make install" fails with errors in
> tools/tests/x86_emulator if you don't have a new enough GCC. Causing
> failures on distros that are considered still supported based on README.
> 
> 2. The hypervisor currently fails to build with clang using versions that
> READM says are supported no matter the configuration.
> 

Do you have a link to the log? I guess the answer is to go to gitlab?

Wei.

> --
> 
> Doug
> 

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

Re: [Xen-devel] Status of 4.13

[Roger Pau Monné]

On Mon, Nov 25, 2019 at 02:06:06PM +0000, Wei Liu wrote:
> Cc Roger -- you're our resident Clang expert. :-)
> 
> On Mon, Nov 25, 2019 at 08:02:17AM -0600, Doug Goldstein wrote:
> > On 11/21/19 12:05 AM, Jürgen Groß wrote:
> > 
> > > Where do we stand with Xen 4.13 regarding blockers and related patches?
> > > 
> > 1. Currently the default "make install" fails with errors in
> > tools/tests/x86_emulator if you don't have a new enough GCC. Causing
> > failures on distros that are considered still supported based on README.
> > 
> > 2. The hypervisor currently fails to build with clang using versions that
> > READM says are supported no matter the configuration.
> > 
> 
> Do you have a link to the log? I guess the answer is to go to gitlab?

This is what I get:

[...]
clang -D__ASSEMBLY__ -m64 -DBUILD_ID -fno-strict-aliasing -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-local-typedefs -O1 -fno-omit-frame-pointer -nostdinc -fno-builtin -fno-common -Werror -Wredundant-decls -Wno-pointer-arith -Wvla -pipe -D__XEN__ -include /root/src/xen/xen/include/xen/config.h '-D__OBJECT_FILE__="/root/src/xen/xen/.xen-syms.0.o"' -g -MMD -MF /root/src/xen/xen/..xen-syms.0.o.d -DXEN_BUILD_EFI -I/root/src/xen/xen/include -I/root/src/xen/xen/include/asm-x86/mach-generic -I/root/src/xen/xen/include/asm-x86/mach-default -DXEN_IMG_OFFSET=0x200000 '-D__OBJECT_LABEL__=arch$x86$$root$src$xen$xen$.xen_syms.0.o' -msoft-float -fno-stack-protector -fno-exceptions -Wnested-externs -DHAVE_AS_VMX -DHAVE_AS_SSE4_2 -DHAVE_AS_EPT -DHAVE_AS_RDRAND -DHAVE_AS_FSGSBASE -DHAVE_AS_XSAVEOPT -DHAVE_AS_RDSEED -DHAVE_AS_CLWB -U__OBJECT_LABEL__ -DHAVE_AS_QUOTED_SYM '-D__OBJECT_LABEL__=arch/x86//root/src/xen/xen/.xen-syms.0.o' -DHAVE_AS_INVPCID -DHAVE_AS_NEGATIVE_TRUE -mno-red-zone -fpic -fno-asynchronous-unwind-tables -mno-sse -DGCC_HAS_VISIBILITY_ATTRIBUTE -Wa,-I/root/src/xen/xen/include -DBUILD_ID_EFI -c /root/src/xen/xen/.xen-syms.0.S -o /root/src/xen/xen/.xen-syms.0.o
gmake[4]: Leaving directory '/root/src/xen/xen/arch/x86'
ld    -melf_x86_64_fbsd  -T xen.lds -N prelink.o --build-id=sha1 \
    /root/src/xen/xen/.xen-syms.0.o -o /root/src/xen/xen/.xen-syms.1
nm -pa --format=sysv /root/src/xen/xen/.xen-syms.1 \
	| /root/src/xen/xen/tools/symbols --all-symbols --sort-by-name --sysv --sort --error-dup \
	>/root/src/xen/xen/.xen-syms.1.S
Duplicate symbol 'asid.c#get_cpu_info' (ffff82d0803032c0 != ffff82d0802e0f50)
Duplicate symbol 'asid.c#get_cpu_info_from_stack' (ffff82d0802e1080 != ffff82d0803032f0)
Duplicate symbol 'ats.c#__list_add' (ffff82d080260a00 != ffff82d080267c70)
Duplicate symbol 'boot.c#constant_test_bit' (ffff82d08040ea60 != ffff82d0804372f0)
Duplicate symbol 'common.c#clear_bit' (ffff82d080332440 != ffff82d0802d33b0)
Duplicate symbol 'common.c#constant_test_bit' (ffff82d080332340 != ffff82d0802d2220)
Duplicate symbol 'common.c#cpumask_check' (ffff82d0802d3370 != ffff82d080337b60)
Duplicate symbol 'common.c#get_cpu_info' (ffff82d0802d22b0 != ffff82d080331590)
Duplicate symbol 'common.c#get_cpu_info_from_stack' (ffff82d0802d31c0 != ffff82d0803374b0)
Duplicate symbol 'common.c#pfn_to_pdx' (ffff82d0802d3270 != ffff82d080331e00)
Duplicate symbol 'common.c#test_and_set_bit' (ffff82d0802d3360 != ffff82d080332250)
Duplicate symbol 'common.c#variable_clear_bit' (ffff82d0802d2270 != ffff82d080337b50)
Duplicate symbol 'compat.c#get_cpu_info' (ffff82d08026eab0 != ffff82d080200460)
Duplicate symbol 'compat.c#get_cpu_info_from_stack' (ffff82d08026ebd0 != ffff82d080200f70)
Duplicate symbol 'cpu_idle.c#get_cpu_info' (ffff82d0802ccb00 != ffff82d08035fcc0)
Duplicate symbol 'cpu_idle.c#get_cpu_info_from_stack' (ffff82d08035ff60 != ffff82d0802ce9f0)
Duplicate symbol 'cpufreq.c#_xmalloc_array' (ffff82d08024f9e0 != ffff82d0802d0210)
Duplicate symbol 'cpufreq.c#bitmap_empty' (ffff82d0802d0650 != ffff82d08024fb70)
Duplicate symbol 'cpufreq.c#bitmap_weight' (ffff82d0802d06a0 != ffff82d08024fb50)
Duplicate symbol 'cpufreq.c#cpumask_check' (ffff82d0802d0190 != ffff82d08024fb20)
Duplicate symbol 'cpufreq.c#cpumask_empty' (ffff82d0802d05b0 != ffff82d08024f520)
Duplicate symbol 'cpufreq.c#cpumask_first' (ffff82d0802d05c0 != ffff82d08024f480)
Duplicate symbol 'cpufreq.c#cpumask_test_cpu' (ffff82d0802cfba0 != ffff82d08024f070)
Duplicate symbol 'cpufreq.c#cpumask_weight' (ffff82d0802d0660 != ffff82d08024f4d0)
Duplicate symbol 'cpufreq.c#get_cpu_info' (ffff82d0803600e0 != ffff82d0802cfbd0)
Duplicate symbol 'cpufreq.c#get_cpu_info' (ffff82d08024fa10 != ffff82d0803600e0)
Duplicate symbol 'cpufreq.c#get_cpu_info_from_stack' (ffff82d0802d01b0 != ffff82d08024fb90)
Duplicate symbol 'cpufreq.c#get_cpu_info_from_stack' (ffff82d0803600f0 != ffff82d0802d01b0)
Duplicate symbol 'cpufreq.c#variable_test_bit' (ffff82d0802d0180 != ffff82d08024fb10)
Duplicate symbol 'cpuid.c#array_index_mask_nospec' (ffff82d08026e990 != ffff82d08026bef0)
Duplicate symbol 'cpuid.c#constant_test_bit' (ffff82d08026b710 != ffff82d08026dab0)
Duplicate symbol 'cpuid.c#get_cpu_info' (ffff82d08026bee0 != ffff82d08026e9b0)
Duplicate symbol 'cpuid.c#get_cpu_info_from_stack' (ffff82d08026ea00 != ffff82d08026bf10)
Duplicate symbol 'cpuid.c#zero_leaves' (ffff82d08026b660 != ffff82d08026e0c0)
Duplicate symbol 'dom0_build.c#__maddr_to_virt' (ffff82d08043bff0 != ffff82d08043eb90)
Duplicate symbol 'dom0_build.c#_mfn' (ffff82d08043bfe0 != ffff82d08043d330)
Duplicate symbol 'dom0_build.c#clear_bit' (ffff82d08043f750 != ffff82d08043c580)
Duplicate symbol 'dom0_build.c#constant_test_bit' (ffff82d08043c050 != ffff82d08043eac0)
Duplicate symbol 'dom0_build.c#elf_set_vcpu' (ffff82d08043c570 != ffff82d08043f000)
Duplicate symbol 'dom0_build.c#get_order_from_pages' (ffff82d08043eb40 != ffff82d08043c290)
Duplicate symbol 'dom0_build.c#mfn_x' (ffff82d08043bfd0 != ffff82d08043d320)
Duplicate symbol 'dom0_build.c#pdx_to_pfn' (ffff82d08043c2d0 != ffff82d08043eb10)
Duplicate symbol 'dom0_build.c#pfn_to_pdx' (ffff82d08043c300 != ffff82d08043d2f0)
Duplicate symbol 'dom0_build.c#set_bit' (ffff82d0804426e0 != ffff82d08043eae0)
Duplicate symbol 'domain.c#__rdgsbase' (ffff82d0802770e0 != ffff82d080357840)
Duplicate symbol 'domain.c#__virt_to_maddr' (ffff82d080272d30 != ffff82d080357a30)
Duplicate symbol 'domain.c#_gfn' (ffff82d0802e2b90 != ffff82d0802096c0)
Duplicate symbol 'domain.c#_gfn' (ffff82d080273920 != ffff82d0802e2b90)
Duplicate symbol 'domain.c#_mfn' (ffff82d0802e2af0 != ffff82d080357980)
Duplicate symbol 'domain.c#_mfn' (ffff82d080208a30 != ffff82d0802e2af0)
Duplicate symbol 'domain.c#_mfn' (ffff82d0802729c0 != ffff82d080208a30)
Duplicate symbol 'domain.c#_xzalloc_array' (ffff82d0803574c0 != ffff82d080207390)
Duplicate symbol 'domain.c#atomic_read' (ffff82d0802095f0 != ffff82d080274c30)
Duplicate symbol 'domain.c#bitmap_empty' (ffff82d080277440 != ffff82d080209630)
Duplicate symbol 'domain.c#clear_bit' (ffff82d080208800 != ffff82d080274da0)
Duplicate symbol 'domain.c#constant_test_bit' (ffff82d0802092b0 != ffff82d080357790)
Duplicate symbol 'domain.c#constant_test_bit' (ffff82d0802734f0 != ffff82d0802092b0)
Duplicate symbol 'domain.c#cpumask_check' (ffff82d080209650 != ffff82d080276e90)
Duplicate symbol 'domain.c#cpumask_empty' (ffff82d0802076d0 != ffff82d080276990)
Duplicate symbol 'domain.c#cpumask_test_cpu' (ffff82d080275740 != ffff82d0802094f0)
Duplicate symbol 'domain.c#get_cpu_info' (ffff82d080272580 != ffff82d0802e29e0)
Duplicate symbol 'domain.c#get_cpu_info' (ffff82d0802078d0 != ffff82d080272580)
Duplicate symbol 'domain.c#get_cpu_info' (ffff82d08035fc40 != ffff82d0802078d0)
Duplicate symbol 'domain.c#get_cpu_info' (ffff82d080357a00 != ffff82d08035fc40)
Duplicate symbol 'domain.c#get_cpu_info_from_stack' (ffff82d080276e50 != ffff82d080357a10)
Duplicate symbol 'domain.c#get_cpu_info_from_stack' (ffff82d08035fc50 != ffff82d080276e50)
Duplicate symbol 'domain.c#get_cpu_info_from_stack' (ffff82d0802e2b70 != ffff82d08035fc50)
Duplicate symbol 'domain.c#get_cpu_info_from_stack' (ffff82d0802096a0 != ffff82d0802e2b70)
Duplicate symbol 'domain.c#get_page_from_gfn' (ffff82d0802e2a30 != ffff82d080208a40)
Duplicate symbol 'domain.c#mfn_eq' (ffff82d080273930 != ffff82d080208a00)
Duplicate symbol 'domain.c#mfn_x' (ffff82d0803579c0 != ffff82d0802e2ae0)
Duplicate symbol 'domain.c#mfn_x' (ffff82d0802729b0 != ffff82d0803579c0)
Duplicate symbol 'domain.c#mfn_x' (ffff82d080208bc0 != ffff82d0802729b0)
Duplicate symbol 'domain.c#paging_update_paging_modes' (ffff82d080274db0 != ffff82d0802e2b50)
Duplicate symbol 'domain.c#pdx_to_pfn' (ffff82d080357990 != ffff82d0802729d0)
Duplicate symbol 'domain.c#pdx_to_pfn' (ffff82d080208b40 != ffff82d080357990)
Duplicate symbol 'domain.c#pdx_to_pfn' (ffff82d0802e2b00 != ffff82d080208b40)
Duplicate symbol 'domain.c#pfn_to_pdx' (ffff82d080208b90 != ffff82d0803579d0)
Duplicate symbol 'domain.c#pfn_to_pdx' (ffff82d0802e2ba0 != ffff82d080208b90)
Duplicate symbol 'domain.c#pfn_to_pdx' (ffff82d080274d50 != ffff82d0802e2ba0)
Duplicate symbol 'domain.c#put_page_and_type' (ffff82d080208b20 != ffff82d0802769b0)
Duplicate symbol 'domain.c#read_cr4' (ffff82d080357820 != ffff82d0802770b0)
Duplicate symbol 'domain.c#read_u32_atomic' (ffff82d080276fd0 != ffff82d080209600)
Duplicate symbol 'domain.c#set_bit' (ffff82d0802e2b60 != ffff82d080274cb0)
Duplicate symbol 'domain.c#set_bit' (ffff82d080206cd0 != ffff82d0802e2b60)
Duplicate symbol 'domain.c#test_and_clear_bit' (ffff82d080277460 != ffff82d0802092a0)
Duplicate symbol 'domain.c#test_and_set_bit' (ffff82d0802092d0 != ffff82d080276e40)
Duplicate symbol 'domain.c#variable_test_bit' (ffff82d080209360 != ffff82d0802770f0)
Duplicate symbol 'domain.c#write_u32_atomic' (ffff82d080208b80 != ffff82d080277100)
Duplicate symbol 'domain.c#write_u64_atomic' (ffff82d080208b70 != ffff82d080277260)
Duplicate symbol 'domctl.c#_gfn' (ffff82d080206660 != ffff82d080272150)
Duplicate symbol 'domctl.c#_mfn' (ffff82d080206670 != ffff82d0802715e0)
Duplicate symbol 'domctl.c#get_cpu_info' (ffff82d080271500 != ffff82d080205390)
Duplicate symbol 'domctl.c#get_cpu_info_from_stack' (ffff82d080272130 != ffff82d0802069a0)
Duplicate symbol 'emulate.c#IS_ERR_OR_NULL' (ffff82d0803034b0 != ffff82d0802e69a0)
Duplicate symbol 'emulate.c#get_cpu_info' (ffff82d080357cb0 != ffff82d0803034a0)
Duplicate symbol 'emulate.c#get_cpu_info' (ffff82d0802e30a0 != ffff82d080357cb0)
Duplicate symbol 'emulate.c#get_cpu_info_from_stack' (ffff82d0802e6a70 != ffff82d080357cf0)
Duplicate symbol 'emulate.c#get_cpu_info_from_stack' (ffff82d080303500 != ffff82d0802e6a70)
Duplicate symbol 'emulate.c#hvm_inject_hw_exception' (ffff82d0803034d0 != ffff82d0802e32f0)
Duplicate symbol 'grant_table.c#_gfn' (ffff82d0802e6bc0 != ffff82d0802114c0)
Duplicate symbol 'grant_table.c#_mfn' (ffff82d08035b520 != ffff82d080211430)
Duplicate symbol 'grant_table.c#get_cpu_info' (ffff82d0802e6bb0 != ffff82d08020dea0)
Duplicate symbol 'grant_table.c#get_cpu_info' (ffff82d08035b490 != ffff82d0802e6bb0)
Duplicate symbol 'grant_table.c#get_cpu_info_from_stack' (ffff82d0802117b0 != ffff82d08035bab0)
Duplicate symbol 'grant_table.c#get_cpu_info_from_stack' (ffff82d0802e6d50 != ffff82d0802117b0)
Duplicate symbol 'grant_table.c#get_gfn_type' (ffff82d080213560 != ffff82d0802e6cf0)
Duplicate symbol 'grant_table.c#get_gfn_type_access' (ffff82d0802e6d70 != ffff82d080213710)
Duplicate symbol 'grant_table.c#mfn_eq' (ffff82d0802e6d10 != ffff82d080212d10)
Duplicate symbol 'grant_table.c#mfn_eq' (ffff82d08035ba60 != ffff82d0802e6d10)
Duplicate symbol 'grant_table.c#mfn_x' (ffff82d08035b4a0 != ffff82d080210f10)
Duplicate symbol 'grant_table.c#mfn_x' (ffff82d0802e6d40 != ffff82d08035b4a0)
Duplicate symbol 'grant_table.c#pfn_to_pdx' (ffff82d080210ee0 != ffff82d08035bb10)
Duplicate symbol 'hpet.c#__test_and_clear_bit' (ffff82d0802c9b00 != ffff82d0802e8490)
Duplicate symbol 'hpet.c#constant_test_bit' (ffff82d0802c9630 != ffff82d0802e7990)
Duplicate symbol 'hpet.c#get_cpu_info' (ffff82d0802e83a0 != ffff82d0802c9190)
Duplicate symbol 'hpet.c#get_cpu_info_from_stack' (ffff82d0802e83b0 != ffff82d0802c9b20)
Duplicate symbol 'hpet.c#variable_set_bit' (ffff82d0802e8450 != ffff82d0802c9aa0)
Duplicate symbol 'hvm.c#_gfn' (ffff82d0802e9fc0 != ffff82d08034f230)
Duplicate symbol 'hvm.c#_mfn' (ffff82d0802e9fa0 != ffff82d08034f1f0)
Duplicate symbol 'hvm.c#constant_test_bit' (ffff82d0802ea4c0 != ffff82d080260ab0)
Duplicate symbol 'hvm.c#get_cpu_info' (ffff82d0802e86e0 != ffff82d08034e3b0)
Duplicate symbol 'hvm.c#get_cpu_info_from_stack' (ffff82d0802ef670 != ffff82d08034e580)
Duplicate symbol 'hvm.c#get_page_from_gfn' (ffff82d08034f270 != ffff82d0802eb3d0)
Duplicate symbol 'hvm.c#hvm_get_cpl' (ffff82d0802ece20 != ffff82d08034f080)
Duplicate symbol 'hvm.c#is_x86_user_segment' (ffff82d0802eb760 != ffff82d08034e5f0)
Duplicate symbol 'hvm.c#mfn_x' (ffff82d0802ea020 != ffff82d08034f1e0)
Duplicate symbol 'hvm.c#pdx_to_pfn' (ffff82d0802eb4a0 != ffff82d08034f340)
Duplicate symbol 'hvm.c#pfn_to_pdx' (ffff82d08034f200 != ffff82d0802eb4d0)
Duplicate symbol 'hypercall.c#array_index_mask_nospec' (ffff82d0802f14e0 != ffff82d08035bfa0)
Duplicate symbol 'hypercall.c#get_cpu_info' (ffff82d08035bf90 != ffff82d080279b10)
Duplicate symbol 'hypercall.c#get_cpu_info' (ffff82d0802f1470 != ffff82d08035bf90)
Duplicate symbol 'hypercall.c#get_cpu_info_from_stack' (ffff82d0802f14f0 != ffff82d080279e80)
Duplicate symbol 'hypercall.c#get_cpu_info_from_stack' (ffff82d08035c1e0 != ffff82d0802f14f0)
Duplicate symbol 'intr.c#get_cpu_info' (ffff82d0803036e0 != ffff82d08030c6c0)
Duplicate symbol 'intr.c#get_cpu_info_from_stack' (ffff82d08030c960 != ffff82d0803038d0)
Duplicate symbol 'io.c#__list_add' (ffff82d0802f2c30 != ffff82d0802586a0)
Duplicate symbol 'io.c#__list_del' (ffff82d0802f2c50 != ffff82d080258710)
Duplicate symbol 'io.c#get_cpu_info' (ffff82d080258760 != ffff82d0802f1e50)
Duplicate symbol 'io.c#get_cpu_info_from_stack' (ffff82d0802f25a0 != ffff82d0802587a0)
Duplicate symbol 'io.c#list_del' (ffff82d080258110 != ffff82d0802f2550)
Duplicate symbol 'io.c#list_empty' (ffff82d080258160 != ffff82d0802f24c0)
Duplicate symbol 'iommu.c#INIT_LIST_HEAD' (ffff82d080267d90 != ffff82d080258e80)
Duplicate symbol 'iommu.c#_dfn' (ffff82d080267e10 != ffff82d0802548d0)
Duplicate symbol 'iommu.c#_mfn' (ffff82d080254ba0 != ffff82d080258dc0)
Duplicate symbol 'iommu.c#_mfn' (ffff82d080267e20 != ffff82d080254ba0)
Duplicate symbol 'iommu.c#constant_test_bit' (ffff82d080258e90 != ffff82d080254b70)
Duplicate symbol 'iommu.c#dfn_eq' (ffff82d0802548a0 != ffff82d08025c100)
Duplicate symbol 'iommu.c#dfn_x' (ffff82d0802544c0 != ffff82d08025ba10)
Duplicate symbol 'iommu.c#iommu_get_ops' (ffff82d080267d40 != ffff82d0802541b0)
Duplicate symbol 'iommu.c#mfn_x' (ffff82d0802544d0 != ffff82d080267e30)
Duplicate symbol 'iommu.c#mfn_x' (ffff82d080258e00 != ffff82d0802544d0)
Duplicate symbol 'iommu.c#pdx_to_pfn' (ffff82d080267de0 != ffff82d080258dd0)
Duplicate symbol 'iommu.c#pfn_to_pdx' (ffff82d080258e50 != ffff82d080267db0)
Duplicate symbol 'iommu.c#variable_test_bit' (ffff82d080254b90 != ffff82d080258eb0)
Duplicate symbol 'irq.c#INIT_LIST_HEAD' (ffff82d080215470 != ffff82d080285d70)
Duplicate symbol 'irq.c#__test_and_clear_bit' (ffff82d080285d90 != ffff82d0802f56b0)
Duplicate symbol 'irq.c#alloc_cpumask_var' (ffff82d080215430 != ffff82d080281880)
Duplicate symbol 'irq.c#bitmap_fill' (ffff82d080285980 != ffff82d0802154c0)
Duplicate symbol 'irq.c#clear_bit' (ffff82d080285940 != ffff82d0802f5ad0)
Duplicate symbol 'irq.c#constant_test_bit' (ffff82d080284560 != ffff82d0802f60a0)
Duplicate symbol 'irq.c#cpumask_setall' (ffff82d080281740 != ffff82d080215460)
Duplicate symbol 'irq.c#free_cpumask_var' (ffff82d080215480 != ffff82d0802818b0)
Duplicate symbol 'irq.c#get_cpu_info' (ffff82d080281580 != ffff82d0802f5780)
Duplicate symbol 'irq.c#get_cpu_info_from_stack' (ffff82d080285960 != ffff82d0802f6080)
Duplicate symbol 'irq.c#local_irq_is_enabled' (ffff82d080282ea0 != ffff82d0802f5940)
Duplicate symbol 'irq.c#radix_tree_ptr_to_int' (ffff82d0802f6060 != ffff82d080284520)
Duplicate symbol 'irq.c#set_bit' (ffff82d0802f5ae0 != ffff82d0802818e0)
Duplicate symbol 'irq.c#variable_test_bit' (ffff82d0802f64c0 != ffff82d080284580)
Duplicate symbol 'mem_access.c#_gfn' (ffff82d080320920 != ffff82d08021da10)
Duplicate symbol 'mem_access.c#get_cpu_info' (ffff82d08021da00 != ffff82d080320c50)
Duplicate symbol 'mem_access.c#get_cpu_info_from_stack' (ffff82d08021da60 != ffff82d0803214b0)
Duplicate symbol 'mm.c#_gfn' (ffff82d08035ceb0 != ffff82d08028f550)
Duplicate symbol 'mm.c#_mfn' (ffff82d0802887c0 != ffff82d08035cbc0)
Duplicate symbol 'mm.c#get_cpu_info' (ffff82d080288df0 != ffff82d08035cb90)
Duplicate symbol 'mm.c#get_cpu_info_from_stack' (ffff82d08035ce10 != ffff82d080292970)
Duplicate symbol 'mm.c#get_page_from_gfn' (ffff82d08035cd50 != ffff82d08028cd60)
Duplicate symbol 'mm.c#get_pte_flags' (ffff82d0802895e0 != ffff82d08035cba0)
Duplicate symbol 'mm.c#mfn_x' (ffff82d0802887b0 != ffff82d08035cef0)
Duplicate symbol 'mm.c#pfn_to_pdx' (ffff82d080288780 != ffff82d08035cec0)
Duplicate symbol 'mm.c#write_u64_atomic' (ffff82d08035ce00 != ffff82d08028b780)
Duplicate symbol 'monitor.c#altp2m_vcpu_idx' (ffff82d080221760 != ffff82d0802f6e60)
Duplicate symbol 'monitor.c#constant_test_bit' (ffff82d0802f69e0 != ffff82d080298110)
Duplicate symbol 'monitor.c#get_cpu_info' (ffff82d0802f6800 != ffff82d0802215b0)
Duplicate symbol 'monitor.c#get_cpu_info_from_stack' (ffff82d0802f6e70 != ffff82d0802217f0)
Duplicate symbol 'msi.c#fls' (ffff82d08027fb80 != ffff82d080253380)
Duplicate symbol 'msi.c#get_cpu_info' (ffff82d08027e020 != ffff82d0802530d0)
Duplicate symbol 'msi.c#get_cpu_info_from_stack' (ffff82d080253420 != ffff82d08027fba0)
Duplicate symbol 'msr.c#get_cpu_info' (ffff82d08026c110 != ffff82d080280b40)
Duplicate symbol 'msr.c#get_cpu_info_from_stack' (ffff82d0802810a0 != ffff82d08026c120)
Duplicate symbol 'quirks.c#constant_set_bit' (ffff82d080260650 != ffff82d0802f8d70)
Duplicate symbol 'smp.c#bitmap_andnot' (ffff82d0802a2990 != ffff82d08023c720)
Duplicate symbol 'smp.c#bitmap_empty' (ffff82d08023c800 != ffff82d0802a2970)
Duplicate symbol 'smp.c#bitmap_subset' (ffff82d08023c780 != ffff82d0802a2940)
Duplicate symbol 'smp.c#bitmap_weight' (ffff82d08023c7e0 != ffff82d0802a29b0)
Duplicate symbol 'smp.c#clear_bit' (ffff82d0802a2930 != ffff82d08023c830)
Duplicate symbol 'smp.c#cpumask_andnot' (ffff82d08023c4e0 != ffff82d0802a2620)
Duplicate symbol 'smp.c#cpumask_check' (ffff82d0802a2910 != ffff82d08023c740)
Duplicate symbol 'smp.c#cpumask_clear_cpu' (ffff82d0802a2420 != ffff82d08023c700)
Duplicate symbol 'smp.c#cpumask_empty' (ffff82d0802a25b0 != ffff82d08023c630)
Duplicate symbol 'smp.c#cpumask_of' (ffff82d08023c4f0 != ffff82d0802a2560)
Duplicate symbol 'smp.c#cpumask_subset' (ffff82d0802a2550 != ffff82d08023c600)
Duplicate symbol 'smp.c#cpumask_test_cpu' (ffff82d0802a2320 != ffff82d08023c6e0)
Duplicate symbol 'smp.c#cpumask_weight' (ffff82d08023c620 != ffff82d0802a2790)
Duplicate symbol 'smp.c#get_cpu_info' (ffff82d0802a21e0 != ffff82d08023c530)
Duplicate symbol 'smp.c#get_cpu_info_from_stack' (ffff82d0802a2860 != ffff82d08023c760)
Duplicate symbol 'smp.c#local_irq_is_enabled' (ffff82d08023c5e0 != ffff82d0802a2530)
Duplicate symbol 'smp.c#variable_test_bit' (ffff82d08023c820 != ffff82d0802a2900)
Duplicate symbol 'sysctl.c#bitmap_weight' (ffff82d08023ee10 != ffff82d0802a6390)
Duplicate symbol 'sysctl.c#constant_test_bit' (ffff82d0802a60a0 != ffff82d08023ee70)
Duplicate symbol 'sysctl.c#cpumask_check' (ffff82d0802a6410 != ffff82d08023ef10)
Duplicate symbol 'sysctl.c#cpumask_first' (ffff82d08023eea0 != ffff82d0802a63a0)
Duplicate symbol 'sysctl.c#cpumask_next' (ffff82d0802a63d0 != ffff82d08023eed0)
Duplicate symbol 'sysctl.c#cpumask_test_cpu' (ffff82d0802a6260 != ffff82d08023edd0)
Duplicate symbol 'sysctl.c#cpumask_weight' (ffff82d08023ed00 != ffff82d0802a5910)
Duplicate symbol 'sysctl.c#get_cpu_info' (ffff82d08023ecc0 != ffff82d0802a6280)
Duplicate symbol 'sysctl.c#get_cpu_info_from_stack' (ffff82d0802a6440 != ffff82d08023edf0)
Duplicate symbol 'sysctl.c#variable_test_bit' (ffff82d08023ee90 != ffff82d0802a6430)
Duplicate symbol 'time.c#clear_bit' (ffff82d0802a7480 != ffff82d08031d570)
Duplicate symbol 'time.c#constant_test_bit' (ffff82d0802a6840 != ffff82d08031d340)
Duplicate symbol 'time.c#get_cpu_info' (ffff82d0802a67a0 != ffff82d08031d0f0)
Duplicate symbol 'time.c#get_cpu_info' (ffff82d08023fa10 != ffff82d0802a67a0)
Duplicate symbol 'time.c#get_cpu_info_from_stack' (ffff82d0802a7d70 != ffff82d08023fba0)
Duplicate symbol 'time.c#get_cpu_info_from_stack' (ffff82d08031d620 != ffff82d0802a7d70)
Duplicate symbol 'time.c#set_bit' (ffff82d0802a88f0 != ffff82d08031d640)
Duplicate symbol 'time.c#test_and_clear_bit' (ffff82d0802a8900 != ffff82d08031d580)
Duplicate symbol 'time.c#variable_test_bit' (ffff82d08031d360 != ffff82d0802a7d10)
Duplicate symbol 'trace.c#get_cpu_info' (ffff82d080240f80 != ffff82d0802a8bd0)
Duplicate symbol 'trace.c#get_cpu_info_from_stack' (ffff82d0802a8e00 != ffff82d080241cc0)
Duplicate symbol 'traps.c#_mfn' (ffff82d0802aaa30 != ffff82d08035ec60)
Duplicate symbol 'traps.c#constant_test_bit' (ffff82d08035ee90 != ffff82d0802aad30)
Duplicate symbol 'traps.c#get_cpu_info' (ffff82d0802a9c30 != ffff82d08035e4b0)
Duplicate symbol 'traps.c#get_cpu_info' (ffff82d08035df20 != ffff82d0802a9c30)
Duplicate symbol 'traps.c#get_cpu_info_from_stack' (ffff82d08035e140 != ffff82d0802ab640)
Duplicate symbol 'traps.c#get_cpu_info_from_stack' (ffff82d08035eeb0 != ffff82d08035e140)
Duplicate symbol 'traps.c#get_pte_flags' (ffff82d0802abdf0 != ffff82d08035ec80)
Duplicate symbol 'traps.c#mfn_x' (ffff82d08035ec70 != ffff82d0802aaa20)
Duplicate symbol 'traps.c#pv_inject_hw_exception' (ffff82d0802aae40 != ffff82d08035e000)
Duplicate symbol 'traps.c#read_cr2' (ffff82d0802aa610 != ffff82d08035e580)
Duplicate symbol 'traps.c#read_cr3' (ffff82d08035ec50 != ffff82d0802ab8c0)
Duplicate symbol 'traps.c#read_cr4' (ffff82d08035eee0 != ffff82d0802abe10)
Duplicate symbol 'traps.c#wrmsrl' (ffff82d08035ee30 != ffff82d0802ab310)
Duplicate symbol 'vm_event.c#atomic_read' (ffff82d080242780 != ffff82d0802c9de0)
Duplicate symbol 'vm_event.c#get_cpu_info' (ffff82d0802ffc60 != ffff82d0802426f0)
Duplicate symbol 'vm_event.c#get_cpu_info' (ffff82d0802ca140 != ffff82d0802ffc60)
Duplicate symbol 'vm_event.c#get_cpu_info_from_stack' (ffff82d080243190 != ffff82d0802ca3f0)
Duplicate symbol 'vm_event.c#get_cpu_info_from_stack' (ffff82d0802ffc70 != ffff82d080243190)
Duplicate symbol 'vm_event.c#read_u32_atomic' (ffff82d0802ca3e0 != ffff82d0802431b0)
Duplicate symbol 'xenoprof.c#get_cpu_info' (ffff82d0802463e0 != ffff82d080352c10)
Duplicate symbol 'xenoprof.c#get_cpu_info_from_stack' (ffff82d080352eb0 != ffff82d0802473f0)
gmake[3]: *** [Makefile:143: /root/src/xen/xen/xen-syms] Error 1
gmake[3]: Leaving directory '/root/src/xen/xen/arch/x86'
gmake[2]: *** [Makefile:143: /root/src/xen/xen/xen] Error 2
gmake[2]: Leaving directory '/root/src/xen/xen'
gmake[1]: *** [Makefile:45: install] Error 2
gmake[1]: Leaving directory '/root/src/xen/xen'
gmake: *** [Makefile:130: install-xen] Error 2

Which I think it's expected, we already knew clang had a lot of
duplicate symbols. The only way I know to workaround this ATM is to
use `gmake xen clang=y CONFIG_ENFORCE_UNIQUE_SYMBOLS=n`. It's on my
pile of stuff to look into, but I'm not sure when I will get to it.

Roger.

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

Re: [Xen-devel] Status of 4.13

[Wei Liu]

On Mon, Nov 25, 2019 at 04:59:31PM +0100, Roger Pau Monné wrote:
[...]
> 
> Which I think it's expected, we already knew clang had a lot of
> duplicate symbols. The only way I know to workaround this ATM is to
> use `gmake xen clang=y CONFIG_ENFORCE_UNIQUE_SYMBOLS=n`. It's on my
> pile of stuff to look into, but I'm not sure when I will get to it.

In that case we should make Gitlab CI use the new configuration option.

Wei.

> 
> Roger.

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

Re: [Xen-devel] Status of 4.13

[Roger Pau Monné]

On Mon, Nov 25, 2019 at 05:07:04PM +0000, Wei Liu wrote:
> On Mon, Nov 25, 2019 at 04:59:31PM +0100, Roger Pau Monné wrote:
> [...]
> > 
> > Which I think it's expected, we already knew clang had a lot of
> > duplicate symbols. The only way I know to workaround this ATM is to
> > use `gmake xen clang=y CONFIG_ENFORCE_UNIQUE_SYMBOLS=n`. It's on my
> > pile of stuff to look into, but I'm not sure when I will get to it.
> 
> In that case we should make Gitlab CI use the new configuration option.

IMO the build should work out of the box, so we should disable
CONFIG_ENFORCE_UNIQUE_SYMBOLS automatically if clang is detected.

Thanks, Roger.

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

Re: [Xen-devel] Status of 4.13

[Andrew Cooper]

On 25/11/2019 17:27, Roger Pau Monné wrote:
> On Mon, Nov 25, 2019 at 05:07:04PM +0000, Wei Liu wrote:
>> On Mon, Nov 25, 2019 at 04:59:31PM +0100, Roger Pau Monné wrote:
>> [...]
>>> Which I think it's expected, we already knew clang had a lot of
>>> duplicate symbols. The only way I know to workaround this ATM is to
>>> use `gmake xen clang=y CONFIG_ENFORCE_UNIQUE_SYMBOLS=n`. It's on my
>>> pile of stuff to look into, but I'm not sure when I will get to it.
>> In that case we should make Gitlab CI use the new configuration option.
> IMO the build should work out of the box, so we should disable
> CONFIG_ENFORCE_UNIQUE_SYMBOLS automatically if clang is detected.

Kconfig in 4.13 isn't in a position to know this.  (It will be in 4.14
with Anthony's refresh committed).

Furthermore, the causal chain of LIVEPATCH -> ENFORCE_UNIQUE_SYMBOLS
*is* correct, because livepatching really is bust if duplicate symbols
exist.

The only option (which is kconfig-specific) is to disable LIVEPATCH by
default.

~Andrew

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

Re: [Xen-devel] Status of 4.13

[Wei Liu]

On Mon, Nov 25, 2019 at 05:34:15PM +0000, Andrew Cooper wrote:
> On 25/11/2019 17:27, Roger Pau Monné wrote:
> > On Mon, Nov 25, 2019 at 05:07:04PM +0000, Wei Liu wrote:
> >> On Mon, Nov 25, 2019 at 04:59:31PM +0100, Roger Pau Monné wrote:
> >> [...]
> >>> Which I think it's expected, we already knew clang had a lot of
> >>> duplicate symbols. The only way I know to workaround this ATM is to
> >>> use `gmake xen clang=y CONFIG_ENFORCE_UNIQUE_SYMBOLS=n`. It's on my
> >>> pile of stuff to look into, but I'm not sure when I will get to it.
> >> In that case we should make Gitlab CI use the new configuration option.
> > IMO the build should work out of the box, so we should disable
> > CONFIG_ENFORCE_UNIQUE_SYMBOLS automatically if clang is detected.
> 
> Kconfig in 4.13 isn't in a position to know this.  (It will be in 4.14
> with Anthony's refresh committed).
> 
> Furthermore, the causal chain of LIVEPATCH -> ENFORCE_UNIQUE_SYMBOLS
> *is* correct, because livepatching really is bust if duplicate symbols
> exist.
> 
> The only option (which is kconfig-specific) is to disable LIVEPATCH by
> default.

Are you going to submit a patch for 4.13?

Wei.

> 
> ~Andrew

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

Re: [Xen-devel] Status of 4.13

[Roger Pau Monné]

On Mon, Nov 25, 2019 at 05:34:15PM +0000, Andrew Cooper wrote:
> On 25/11/2019 17:27, Roger Pau Monné wrote:
> > On Mon, Nov 25, 2019 at 05:07:04PM +0000, Wei Liu wrote:
> >> On Mon, Nov 25, 2019 at 04:59:31PM +0100, Roger Pau Monné wrote:
> >> [...]
> >>> Which I think it's expected, we already knew clang had a lot of
> >>> duplicate symbols. The only way I know to workaround this ATM is to
> >>> use `gmake xen clang=y CONFIG_ENFORCE_UNIQUE_SYMBOLS=n`. It's on my
> >>> pile of stuff to look into, but I'm not sure when I will get to it.
> >> In that case we should make Gitlab CI use the new configuration option.
> > IMO the build should work out of the box, so we should disable
> > CONFIG_ENFORCE_UNIQUE_SYMBOLS automatically if clang is detected.
> 
> Kconfig in 4.13 isn't in a position to know this.  (It will be in 4.14
> with Anthony's refresh committed).

We already have Kconfig options that depend on toolchain features,
livepatch itself will be enabled if build id is supported by the
linker, why not use something like:

diff --git a/Config.mk b/Config.mk
index d8f90d75b3..009abda225 100644
--- a/Config.mk
+++ b/Config.mk
@@ -157,6 +157,8 @@ ifndef XEN_HAS_CHECKPOLICY
     export XEN_HAS_CHECKPOLICY
 endif
 
+export XEN_BUILD_WITH_CLANG = $(clang)
+
 # as-insn: Check whether assembler supports an instruction.
 # Usage: cflags-y += $(call as-insn,CC FLAGS,"insn",option-yes,option-no)
 as-insn = $(if $(shell echo 'void _(void) { asm volatile ( $(2) ); }' \
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index f754741972..097996fc6c 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -80,6 +80,10 @@ config HAS_CHECKPOLICY
 	string
 	option env="XEN_HAS_CHECKPOLICY"
 
+config BUILD_WITH_CLANG
+	string
+	option env="XEN_BUILD_WITH_CLANG"
+
 menu "Speculative hardening"
 
 config SPECULATIVE_HARDEN_ARRAY
@@ -350,7 +354,7 @@ config CRYPTO
 config LIVEPATCH
 	bool "Live patching support"
 	default X86
-	depends on HAS_BUILD_ID = "y"
+	depends on HAS_BUILD_ID = "y" && BUILD_WITH_CLANG != "y"
 	---help---
 	  Allows a running Xen hypervisor to be dynamically patched using
 	  binary patches without rebooting. This is primarily used to binarily

This WFM with FreeBSD and clang.

Thanks, Roger.

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

Re: [Xen-devel] Status of 4.13

[Jan Beulich]

On 25.11.2019 18:49, Roger Pau Monné  wrote:
> On Mon, Nov 25, 2019 at 05:34:15PM +0000, Andrew Cooper wrote:
>> On 25/11/2019 17:27, Roger Pau Monné wrote:
>>> On Mon, Nov 25, 2019 at 05:07:04PM +0000, Wei Liu wrote:
>>>> On Mon, Nov 25, 2019 at 04:59:31PM +0100, Roger Pau Monné wrote:
>>>> [...]
>>>>> Which I think it's expected, we already knew clang had a lot of
>>>>> duplicate symbols. The only way I know to workaround this ATM is to
>>>>> use `gmake xen clang=y CONFIG_ENFORCE_UNIQUE_SYMBOLS=n`. It's on my
>>>>> pile of stuff to look into, but I'm not sure when I will get to it.
>>>> In that case we should make Gitlab CI use the new configuration option.
>>> IMO the build should work out of the box, so we should disable
>>> CONFIG_ENFORCE_UNIQUE_SYMBOLS automatically if clang is detected.
>>
>> Kconfig in 4.13 isn't in a position to know this.  (It will be in 4.14
>> with Anthony's refresh committed).
> 
> We already have Kconfig options that depend on toolchain features,
> livepatch itself will be enabled if build id is supported by the
> linker, why not use something like:

I'm sorry to say this, but suggesting workarounds like this when
there's a solution to the problem [1] feels absurd.

Jan

[1] https://lists.xenproject.org/archives/html/xen-devel/2019-11/msg00357.html

> diff --git a/Config.mk b/Config.mk
> index d8f90d75b3..009abda225 100644
> --- a/Config.mk
> +++ b/Config.mk
> @@ -157,6 +157,8 @@ ifndef XEN_HAS_CHECKPOLICY
>      export XEN_HAS_CHECKPOLICY
>  endif
>  
> +export XEN_BUILD_WITH_CLANG = $(clang)
> +
>  # as-insn: Check whether assembler supports an instruction.
>  # Usage: cflags-y += $(call as-insn,CC FLAGS,"insn",option-yes,option-no)
>  as-insn = $(if $(shell echo 'void _(void) { asm volatile ( $(2) ); }' \
> diff --git a/xen/common/Kconfig b/xen/common/Kconfig
> index f754741972..097996fc6c 100644
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -80,6 +80,10 @@ config HAS_CHECKPOLICY
>  	string
>  	option env="XEN_HAS_CHECKPOLICY"
>  
> +config BUILD_WITH_CLANG
> +	string
> +	option env="XEN_BUILD_WITH_CLANG"
> +
>  menu "Speculative hardening"
>  
>  config SPECULATIVE_HARDEN_ARRAY
> @@ -350,7 +354,7 @@ config CRYPTO
>  config LIVEPATCH
>  	bool "Live patching support"
>  	default X86
> -	depends on HAS_BUILD_ID = "y"
> +	depends on HAS_BUILD_ID = "y" && BUILD_WITH_CLANG != "y"
>  	---help---
>  	  Allows a running Xen hypervisor to be dynamically patched using
>  	  binary patches without rebooting. This is primarily used to binarily
> 
> This WFM with FreeBSD and clang.
> 
> Thanks, Roger.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel
> 


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

Re: [Xen-devel] Status of 4.13

[Roger Pau Monné]

On Tue, Nov 26, 2019 at 09:30:47AM +0100, Jan Beulich wrote:
> On 25.11.2019 18:49, Roger Pau Monné  wrote:
> > On Mon, Nov 25, 2019 at 05:34:15PM +0000, Andrew Cooper wrote:
> >> On 25/11/2019 17:27, Roger Pau Monné wrote:
> >>> On Mon, Nov 25, 2019 at 05:07:04PM +0000, Wei Liu wrote:
> >>>> On Mon, Nov 25, 2019 at 04:59:31PM +0100, Roger Pau Monné wrote:
> >>>> [...]
> >>>>> Which I think it's expected, we already knew clang had a lot of
> >>>>> duplicate symbols. The only way I know to workaround this ATM is to
> >>>>> use `gmake xen clang=y CONFIG_ENFORCE_UNIQUE_SYMBOLS=n`. It's on my
> >>>>> pile of stuff to look into, but I'm not sure when I will get to it.
> >>>> In that case we should make Gitlab CI use the new configuration option.
> >>> IMO the build should work out of the box, so we should disable
> >>> CONFIG_ENFORCE_UNIQUE_SYMBOLS automatically if clang is detected.
> >>
> >> Kconfig in 4.13 isn't in a position to know this.  (It will be in 4.14
> >> with Anthony's refresh committed).
> > 
> > We already have Kconfig options that depend on toolchain features,
> > livepatch itself will be enabled if build id is supported by the
> > linker, why not use something like:
> 
> I'm sorry to say this, but suggesting workarounds like this when
> there's a solution to the problem [1] feels absurd.
> 
> Jan
> 
> [1] https://lists.xenproject.org/archives/html/xen-devel/2019-11/msg00357.html

IIRC Juergen had concerns about taking this after rc3. I'm all for
getting this fixed in 4.13, but if that's not the case we should just
disable live patching on clang.

Releasing without Xen building out of the box with clang is not an
option IMO.

Thanks, Roger.

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

Re: [Xen-devel] Status of 4.13

[Jürgen Groß]

On 26.11.19 10:08, Roger Pau Monné wrote:
> On Tue, Nov 26, 2019 at 09:30:47AM +0100, Jan Beulich wrote:
>> On 25.11.2019 18:49, Roger Pau Monné  wrote:
>>> On Mon, Nov 25, 2019 at 05:34:15PM +0000, Andrew Cooper wrote:
>>>> On 25/11/2019 17:27, Roger Pau Monné wrote:
>>>>> On Mon, Nov 25, 2019 at 05:07:04PM +0000, Wei Liu wrote:
>>>>>> On Mon, Nov 25, 2019 at 04:59:31PM +0100, Roger Pau Monné wrote:
>>>>>> [...]
>>>>>>> Which I think it's expected, we already knew clang had a lot of
>>>>>>> duplicate symbols. The only way I know to workaround this ATM is to
>>>>>>> use `gmake xen clang=y CONFIG_ENFORCE_UNIQUE_SYMBOLS=n`. It's on my
>>>>>>> pile of stuff to look into, but I'm not sure when I will get to it.
>>>>>> In that case we should make Gitlab CI use the new configuration option.
>>>>> IMO the build should work out of the box, so we should disable
>>>>> CONFIG_ENFORCE_UNIQUE_SYMBOLS automatically if clang is detected.
>>>>
>>>> Kconfig in 4.13 isn't in a position to know this.  (It will be in 4.14
>>>> with Anthony's refresh committed).
>>>
>>> We already have Kconfig options that depend on toolchain features,
>>> livepatch itself will be enabled if build id is supported by the
>>> linker, why not use something like:
>>
>> I'm sorry to say this, but suggesting workarounds like this when
>> there's a solution to the problem [1] feels absurd.
>>
>> Jan
>>
>> [1] https://lists.xenproject.org/archives/html/xen-devel/2019-11/msg00357.html
> 
> IIRC Juergen had concerns about taking this after rc3. I'm all for
> getting this fixed in 4.13, but if that's not the case we should just
> disable live patching on clang.

I said I'll take only real fixes now. In case the necessary Acks for
Jan's patch are coming soon I'd consider allowing the patch for 4.13.

> 
> Releasing without Xen building out of the box with clang is not an
> option IMO.

I agree.

So in case there are reservations against Jan's patch I'd rather take
this workaround.


Juergen

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

Re: [Xen-devel] Status of 4.13

[Jan Beulich]

On 25.11.2019 15:02, Doug Goldstein wrote:
> 2. The hypervisor currently fails to build with clang using versions 
> that READM says are supported no matter the configuration.

Did you post any details of this anywhere?

Jan

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

Re: [Xen-devel] Status of 4.13

[Rich Persaud]

[-- Attachment #1.1: Type: text/plain, Size: 2847 bytes --]

On Nov 21, 2019, at 17:11, Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> wrote:
> 
> On Thu, Nov 21, 2019 at 11:39:14AM -0800, Roman Shaposhnik wrote:
>>> On Thu, Nov 21, 2019 at 9:38 AM Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>> On 21/11/2019 17:31, Roman Shaposhnik wrote:
>>>>>> On Wed, Nov 20, 2019 at 10:06 PM Jürgen Groß <jgross@suse.com> wrote:
>>>>>>> Where do we stand with Xen 4.13 regarding blockers and related patches?
>>>>>>> 1. OSStest failure regarding nested test:
>>>>>>> I'm not quite sure whether the currently debated patch of Andrew is
>>>>>>> fixing the problem. If not, do we know what is missing or how to
>>>>>>> address the issue? If yes, could we please come to an agreement?
>>>>>>> As an alternative: any thoughts about ignoring this test failure for
>>>>>>> 4.13-RC3 (IOW: doing a force push)?
>>>>>>> 2. Ryzen/Rome failures with Windows guests:
>>>>>>> What is the currently planned way to address the problem? Who is
>>>>>>> working on that?
>>>>>>> 3. Pending patches for 4.13:
>>>>>>> Could I please have feedback which patches tagged as "for-4.13" are
>>>>>>> fixing real regressions or issues? I don't want to take any patches
>>>>>>> not fixing real problems after RC3, and I hope to be able to get a
>>>>>>> push rather sooner than later to be able to let Ian cut RC3.
>>>>>>> 4. Are there any blockers for 4.13 other than 1. and 2. (apart of any
>>>>>>> pending XSAs)?
>>>>>> Any chance the efi=no-rs regression can be added to the list? I understand
>>>>>> that I'm still on the hook to provide more details (I promise to do it on Fri
>>>>>> when I get to my lab to actually have a serial console on all these boxes).
>>>>>> At the same time this is a pretty serious regression for an entire class of
>>>>>> devices where Xen was perfectly happy even during RC1.
>>>>> https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=534f9e29ce28580892b3856036b5e5cd805667cc
>>>>> has been committed.  It is in staging, but not in master yet (because
>>>>> master is blocked by my regression in 1).
>> I'll make sure to test it on Fri, but here's where I'm lost -- my
>> understanding that
>> activation of this patch requires a special build flag to be passed.

Draft doc for the Xen 4.13 improvement:
https://wiki.xen.org/wiki/Xen_EFI#Compatibility_of_UEFI_Host_Firmware.2C_Xen_and_UEFI_Runtime_Services

Corrections and compatibility test reports would be welcome.

Rich

>> Which means,
>> we're still very much in a regresses state when it comes to building
>> out-of-the-box,
>> no?
> 
> No, there are two thing:
> 1. A bug triggered by efi=no-rs flag - fixed in the above commit
> 2. A second commit making efi=no-rs unnecessary on some machines - this
> is what require build flag (CONFIG_EFI_SET_VIRTUAL_ADDRESS_MAP=y).

[-- Attachment #1.2: Type: text/html, Size: 11018 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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