* Re: [Xen-devel] UEFI support on Dell boxes (was: Re: Status of 4.13)
@ 2019-11-26 21:20 Rich Persaud
2019-11-26 21:54 ` Roman Shaposhnik
2019-11-27 9:14 ` Jan Beulich
0 siblings, 2 replies; 13+ messages in thread
From: Rich Persaud @ 2019-11-26 21:20 UTC (permalink / raw)
To: Andrew Cooper
Cc: xen-devel, Roman Shaposhnik, Marek Marczykowski-Górecki, Lars Kurth
[-- Attachment #1.1: Type: text/plain, Size: 5828 bytes --]
On Nov 26, 2019, at 15:23, Andrew Cooper <Andrew.Cooper3@citrix.com> wrote:
> 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.
As an intermediate step, could we have an umbrella opt-in Kconfig option (CONFIG_EFI_NONSPEC_COMPATIBILITY?) that enables multiple EFI options for maximum hardware compatibility? For this thread and Xen 4.13, that would be EFI_SET_VIRTUAL_ADDRESS_MAP and efi=attr=uc. If more options/quirks are added in the future, downstreams using EFI_NONSPEC_COMPATIBILITY would get them by default.
The long-term solution is an OSS virtualization-security test tool (e.g. with Xen and QEMU KVM) that can be run by OEM/ODM QA factory teams on pre-production firmware and hardware. That is the most OEM-actionable development window where firmware quality issues can be detected and fixed. Microsoft's hardware logo/certification work with Windows 10 OEMs on "secured core" features is also tackling firmware improvements for virtualization-based security.
From the business side, Dell/HP/Lenovo + other OEMs and ODMs could add premium "FirmCare" SKUs into their custom build ordering systems, where customers could pay a small fee for additional firmware support, custom root-of-trust (e.g. BootGuard) key management, or even coreboot. This could move from cost-center incentives [1] to high-margin incentives [2] for firmware and platform health, safety & security. Another step would be including firmware requirements in supply chain contracts [3] for large customer orders.
While we wait on these ecosystem improvements, CONFIG_EFI_NONSPEC_COMPATIBILITY or a similar option for Xen 4.13 would help users of existing platforms.
Rich
[1] Firmware is the new Software, https://www.platformsecuritysummit.com/2018/speaker/hudson/
[2] https://i.blackhat.com/USA-19/Thursday/us-19-Krstic-Behind-The-Scenes-Of-IOS-And-Mas-Security.pdf
[3] "Humans" videos and Q&A, https://www.platformsecuritysummit.com/2019/videos/
[-- Attachment #1.2: Type: text/html, Size: 13664 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
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [Xen-devel] UEFI support on Dell boxes (was: Re: Status of 4.13) 2019-11-26 21:20 [Xen-devel] UEFI support on Dell boxes (was: Re: Status of 4.13) Rich Persaud @ 2019-11-26 21:54 ` Roman Shaposhnik 2019-11-27 9:14 ` Jan Beulich 1 sibling, 0 replies; 13+ messages in thread From: Roman Shaposhnik @ 2019-11-26 21:54 UTC (permalink / raw) To: Rich Persaud Cc: Andrew Cooper, Lars Kurth, Marek Marczykowski-Górecki, xen-devel On Tue, Nov 26, 2019 at 1:20 PM Rich Persaud <persaur@gmail.com> wrote: > > On Nov 26, 2019, at 15:23, Andrew Cooper <Andrew.Cooper3@citrix.com> wrote: > > > 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. > > > As an intermediate step, could we have an umbrella opt-in Kconfig option (CONFIG_EFI_NONSPEC_COMPATIBILITY?) that enables multiple EFI options for maximum hardware compatibility? For this thread and Xen 4.13, that would be EFI_SET_VIRTUAL_ADDRESS_MAP and efi=attr=uc. If more options/quirks are added in the future, downstreams using EFI_NONSPEC_COMPATIBILITY would get them by default. As one of those downstream users I have to say I like this A LOT! > The long-term solution is an OSS virtualization-security test tool (e.g. with Xen and QEMU KVM) that can be run by OEM/ODM QA factory teams on pre-production firmware and hardware. That is the most OEM-actionable development window where firmware quality issues can be detected and fixed. Microsoft's hardware logo/certification work with Windows 10 OEMs on "secured core" features is also tackling firmware improvements for virtualization-based security. That's a good proposal, but the question, as always becomes who moves the needle on this one so we avoid a sort of "tragedy of the commons" type of situation. Now, I'm not even talking about writing (and maintaining!) the actual code -- but rather all the BD activities that would have to take place to make it a reality. This actually may be a good question to ask Linux Foundation since I've seen them be helpful in situations like this. > From the business side, Dell/HP/Lenovo + other OEMs and ODMs could add premium "FirmCare" SKUs into their custom build ordering systems, where customers could pay a small fee for additional firmware support, custom root-of-trust (e.g. BootGuard) key management, or even coreboot. This could move from cost-center incentives [1] to high-margin incentives [2] for firmware and platform health, safety & security. Another step would be including firmware requirements in supply chain contracts [3] for large customer orders. Yup! I could see this as well! > While we wait on these ecosystem improvements, CONFIG_EFI_NONSPEC_COMPATIBILITY or a similar option for Xen 4.13 would help users of existing platforms. Right -- because at the end of the day -- as I am discovering now, there seems to be a non-trivial downstream constituency "curating" those types of patches in separate silos (Project EVE included) it would be great to at least have one central bucket (even if non-default and protect by XXX_OPTION) for these patches to be curated -- and that's upstream Xen. Thanks, Roman. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Xen-devel] UEFI support on Dell boxes (was: Re: Status of 4.13) 2019-11-26 21:20 [Xen-devel] UEFI support on Dell boxes (was: Re: Status of 4.13) Rich Persaud 2019-11-26 21:54 ` Roman Shaposhnik @ 2019-11-27 9:14 ` Jan Beulich 2019-11-27 11:34 ` Marek Marczykowski-Górecki 1 sibling, 1 reply; 13+ messages in thread From: Jan Beulich @ 2019-11-27 9:14 UTC (permalink / raw) To: Rich Persaud Cc: Andrew Cooper, Roman Shaposhnik, xen-devel, Marek Marczykowski-Górecki, Lars Kurth On 26.11.2019 22:20, Rich Persaud wrote: > As an intermediate step, could we have an umbrella opt-in > Kconfig option (CONFIG_EFI_NONSPEC_COMPATIBILITY?) that > enables multiple EFI options for maximum hardware compatibility? > For this thread and Xen 4.13, that would be > EFI_SET_VIRTUAL_ADDRESS_MAP and efi=attr=uc. If more > options/quirks are added in the future, downstreams using > EFI_NONSPEC_COMPATIBILITY would get them by default. While I don't particularly like it, I'd be okay with having such an option, provided it doesn't hamper code readability too much. However - why would you stop at those two things? Why not also exclude reboot through UEFI (as indicated by Andrew), or use of runtime services as a whole? What about /mapbs? The fundamental problem I see here really is - where would we draw the line? Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Xen-devel] UEFI support on Dell boxes (was: Re: Status of 4.13) 2019-11-27 9:14 ` Jan Beulich @ 2019-11-27 11:34 ` Marek Marczykowski-Górecki 0 siblings, 0 replies; 13+ messages in thread From: Marek Marczykowski-Górecki @ 2019-11-27 11:34 UTC (permalink / raw) To: Jan Beulich Cc: Andrew Cooper, Rich Persaud, Roman Shaposhnik, Lars Kurth, xen-devel [-- Attachment #1.1: Type: text/plain, Size: 2332 bytes --] On Wed, Nov 27, 2019 at 10:14:56AM +0100, Jan Beulich wrote: > On 26.11.2019 22:20, Rich Persaud wrote: > > As an intermediate step, could we have an umbrella opt-in > > Kconfig option (CONFIG_EFI_NONSPEC_COMPATIBILITY?) that > > enables multiple EFI options for maximum hardware compatibility? > > For this thread and Xen 4.13, that would be > > EFI_SET_VIRTUAL_ADDRESS_MAP and efi=attr=uc. If more > > options/quirks are added in the future, downstreams using > > EFI_NONSPEC_COMPATIBILITY would get them by default. > > While I don't particularly like it, I'd be okay with having such > an option, provided it doesn't hamper code readability too much. > However - why would you stop at those two things? Why not also > exclude reboot through UEFI (as indicated by Andrew), or use of > runtime services as a whole? What about /mapbs? The fundamental > problem I see here really is - where would we draw the line? Yes, it isn't easy to draw that line for all the downstream projects at once. For example it looks like efi=no-rs is an acceptable compromise for Project EVE, while it isn't for Qubes or OpenXT. But moving from "apply this set of patches" to "enable those options" would be an improvement. Ideally Xen should work out of the box on as many boxes as possible. If that means enabling some workarounds by default, I'm fine with it (unless it _severely_ impact other configurations). In Qubes we struggle with hardware compatibility because of large variety of client hardware, firmware and configuration. Whatever we say here, in the end it boils down to "does project X work on my hardware?". Not sure about other Xen use cases, but we prefer to have the answer "yes", whenever it's reasonably possible. I think enabling efi=attr=uc and EFI_SET_VIRTUAL_ADDRESS_MAP by default is a reasonable approach. Defaulting to a different reboot method may be too, but I haven't seen too many machines impacted by this particular issue. Maybe because Xen+UEFI breaks much earlier there. FWIW we do enable efi=attr=uc, /mapbs and /noexitboot by default (until EFI_SET_VIRTUAL_ADDRESS_MAP was added). -- 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Xen-devel] UEFI support on Dell boxes (was: Re: Status of 4.13)
@ 2019-11-27 11:57 Rich Persaud
0 siblings, 0 replies; 13+ messages in thread
From: Rich Persaud @ 2019-11-27 11:57 UTC (permalink / raw)
To: Jan Beulich
Cc: Andrew Cooper, Lars Kurth, Roman Shaposhnik,
Marek Marczykowski-Górecki, xen-devel
On Nov 27, 2019, at 04:16, Jan Beulich <JBeulich@suse.com> wrote:
>
> On 26.11.2019 22:20, Rich Persaud wrote:
>> As an intermediate step, could we have an umbrella opt-in
>> Kconfig option (CONFIG_EFI_NONSPEC_COMPATIBILITY?) that
>> enables multiple EFI options for maximum hardware compatibility?
>> For this thread and Xen 4.13, that would be
>> EFI_SET_VIRTUAL_ADDRESS_MAP and efi=attr=uc. If more
>> options/quirks are added in the future, downstreams using
>> EFI_NONSPEC_COMPATIBILITY would get them by default.
>
> While I don't particularly like it, I'd be okay with having such
> an option, provided it doesn't hamper code readability too much.
> However - why would you stop at those two things? Why not also
> exclude reboot through UEFI (as indicated by Andrew), or use of
> runtime services as a whole? What about /mapbs? The fundamental
> problem I see here really is - where would we draw the line?
If we take this thread as an example, a middle ground was found among developers motivated to maintain the workarounds for downstream projects with affected hardware. Qubes, EVE & OpenXT are used on edge/client devices that often have (relative to servers) a shorter lifetime, with more device churn and support costs.
These two initial options would address current pain points and enable the use of upstream Xen + EFI RS on more devices, e.g. for OTA updates with forward-sealed integrity measurements. The line could change if more downstreams adopt the option and/or new devices appear that have both customer adoption and problematic firmware behavior.
Rich
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 13+ messages in thread* [Xen-devel] Status of 4.13
@ 2019-11-21 6:05 Jürgen Groß
2019-11-21 17:31 ` Roman Shaposhnik
0 siblings, 1 reply; 13+ messages in thread
From: Jürgen Groß @ 2019-11-21 6:05 UTC (permalink / raw)
To: xen-devel
Cc: Wei Liu, George Dunlap, Andrew Cooper, Ian Jackson, Julien Grall,
Jan Beulich
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
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [Xen-devel] Status of 4.13 2019-11-21 6:05 [Xen-devel] Status of 4.13 Jürgen Groß @ 2019-11-21 17:31 ` Roman Shaposhnik 2019-11-21 17:38 ` Andrew Cooper 0 siblings, 1 reply; 13+ messages in thread From: Roman Shaposhnik @ 2019-11-21 17:31 UTC (permalink / raw) To: Jürgen Groß Cc: Wei Liu, George Dunlap, Andrew Cooper, Ian Jackson, Julien Grall, Jan Beulich, xen-devel 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Xen-devel] Status of 4.13 2019-11-21 17:31 ` Roman Shaposhnik @ 2019-11-21 17:38 ` Andrew Cooper 2019-11-23 6:00 ` Roman Shaposhnik 0 siblings, 1 reply; 13+ messages in thread From: Andrew Cooper @ 2019-11-21 17:38 UTC (permalink / raw) To: Roman Shaposhnik, Jürgen Groß Cc: Wei Liu, George Dunlap, Ian Jackson, Julien Grall, Jan Beulich, xen-devel 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Xen-devel] Status of 4.13 2019-11-21 17:38 ` Andrew Cooper @ 2019-11-23 6:00 ` Roman Shaposhnik 2019-11-25 0:47 ` [Xen-devel] UEFI support on Dell boxes (was: Re: Status of 4.13) Marek Marczykowski-Górecki 0 siblings, 1 reply; 13+ messages in thread From: Roman Shaposhnik @ 2019-11-23 6:00 UTC (permalink / raw) To: Andrew Cooper Cc: Jürgen Groß, Wei Liu, George Dunlap, Ian Jackson, Julien Grall, Jan Beulich, xen-devel 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* [Xen-devel] UEFI support on Dell boxes (was: Re: Status of 4.13) 2019-11-23 6:00 ` Roman Shaposhnik @ 2019-11-25 0:47 ` Marek Marczykowski-Górecki 2019-11-26 3:44 ` Roman Shaposhnik 0 siblings, 1 reply; 13+ messages in thread From: Marek Marczykowski-Górecki @ 2019-11-25 0:47 UTC (permalink / raw) To: Roman Shaposhnik; +Cc: xen-devel [-- 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Xen-devel] UEFI support on Dell boxes (was: Re: Status of 4.13) 2019-11-25 0:47 ` [Xen-devel] UEFI support on Dell boxes (was: Re: Status of 4.13) Marek Marczykowski-Górecki @ 2019-11-26 3:44 ` Roman Shaposhnik 2019-11-26 3:55 ` Marek Marczykowski-Górecki 0 siblings, 1 reply; 13+ messages in thread From: Roman Shaposhnik @ 2019-11-26 3:44 UTC (permalink / raw) To: Marek Marczykowski-Górecki; +Cc: xen-devel [-- 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Xen-devel] UEFI support on Dell boxes (was: Re: Status of 4.13) 2019-11-26 3:44 ` Roman Shaposhnik @ 2019-11-26 3:55 ` Marek Marczykowski-Górecki 2019-11-26 7:02 ` Roman Shaposhnik 0 siblings, 1 reply; 13+ messages in thread From: Marek Marczykowski-Górecki @ 2019-11-26 3:55 UTC (permalink / raw) To: Roman Shaposhnik; +Cc: xen-devel [-- 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Xen-devel] UEFI support on Dell boxes (was: Re: Status of 4.13) 2019-11-26 3:55 ` Marek Marczykowski-Górecki @ 2019-11-26 7:02 ` Roman Shaposhnik 2019-11-26 17:56 ` Roman Shaposhnik 0 siblings, 1 reply; 13+ messages in thread From: Roman Shaposhnik @ 2019-11-26 7:02 UTC (permalink / raw) To: Marek Marczykowski-Górecki; +Cc: xen-devel [-- 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Xen-devel] UEFI support on Dell boxes (was: Re: Status of 4.13) 2019-11-26 7:02 ` Roman Shaposhnik @ 2019-11-26 17:56 ` Roman Shaposhnik 2019-11-26 18:32 ` Marek Marczykowski-Górecki 0 siblings, 1 reply; 13+ messages in thread From: Roman Shaposhnik @ 2019-11-26 17:56 UTC (permalink / raw) To: Marek Marczykowski-Górecki; +Cc: xen-devel [-- 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Xen-devel] UEFI support on Dell boxes (was: Re: Status of 4.13) 2019-11-26 17:56 ` Roman Shaposhnik @ 2019-11-26 18:32 ` Marek Marczykowski-Górecki 2019-11-26 20:12 ` Roman Shaposhnik 0 siblings, 1 reply; 13+ messages in thread From: Marek Marczykowski-Górecki @ 2019-11-26 18:32 UTC (permalink / raw) To: Roman Shaposhnik; +Cc: xen-devel [-- 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Xen-devel] UEFI support on Dell boxes (was: Re: Status of 4.13) 2019-11-26 18:32 ` Marek Marczykowski-Górecki @ 2019-11-26 20:12 ` Roman Shaposhnik 2019-11-26 20:18 ` Andrew Cooper 0 siblings, 1 reply; 13+ messages in thread From: Roman Shaposhnik @ 2019-11-26 20:12 UTC (permalink / raw) To: Marek Marczykowski-Górecki; +Cc: xen-devel 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Xen-devel] UEFI support on Dell boxes (was: Re: Status of 4.13) 2019-11-26 20:12 ` Roman Shaposhnik @ 2019-11-26 20:18 ` Andrew Cooper 0 siblings, 0 replies; 13+ messages in thread From: Andrew Cooper @ 2019-11-26 20:18 UTC (permalink / raw) To: Roman Shaposhnik, Marek Marczykowski-Górecki; +Cc: xen-devel 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2019-11-27 11:57 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-11-26 21:20 [Xen-devel] UEFI support on Dell boxes (was: Re: Status of 4.13) Rich Persaud 2019-11-26 21:54 ` Roman Shaposhnik 2019-11-27 9:14 ` Jan Beulich 2019-11-27 11:34 ` Marek Marczykowski-Górecki -- strict thread matches above, loose matches on Subject: below -- 2019-11-27 11:57 Rich Persaud 2019-11-21 6:05 [Xen-devel] Status of 4.13 Jürgen Groß 2019-11-21 17:31 ` Roman Shaposhnik 2019-11-21 17:38 ` Andrew Cooper 2019-11-23 6:00 ` Roman Shaposhnik 2019-11-25 0:47 ` [Xen-devel] UEFI support on Dell boxes (was: Re: Status of 4.13) Marek Marczykowski-Górecki 2019-11-26 3:44 ` Roman Shaposhnik 2019-11-26 3:55 ` Marek Marczykowski-Górecki 2019-11-26 7:02 ` Roman Shaposhnik 2019-11-26 17:56 ` Roman Shaposhnik 2019-11-26 18:32 ` Marek Marczykowski-Górecki 2019-11-26 20:12 ` Roman Shaposhnik 2019-11-26 20:18 ` Andrew Cooper
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.