On 11/22/2017 11:54 AM, Christian KÃnig wrote:
Am 22.11.2017 um 17:24 schrieb Boris Ostrovsky:That memory doesn't belong to the OS (dom0), it is owned by the hypervisor.
On 11/22/2017 05:09 AM, Christian KÃnig wrote:Oh, thanks!
Am 21.11.2017 um 23:26 schrieb Boris Ostrovsky:The problem is that dom0 can be (and was in my case() booted with less
On 11/21/2017 08:34 AM, Christian KÃnig wrote:I still haven't understood what you actually did with Xen.
Hi Boris,Yes, they do fix it but that's because the feature is disabled.
attached are two patches.
The first one is a trivial fix for the infinite loop issue, it now
correctly aborts the fixup when it can't find address space for the
The second is a workaround for your board. It simply checks if there
is exactly one Processor Function to apply this fix on.
Both are based on linus current master branch. Please test if they
Do you know what the actual problem was (on Xen)?
When you used PCI pass through with those devices then you have made a
major configuration error.
When the problem happened on dom0 then the explanation is most likely
that some PCI device ended up in the configured space, but the routing
was only setup correctly on one CPU socket.
than full physical memory and so the "rest" of the host memory is not
necessarily reflected in iomem. Your patch then tried to configure that
memory for MMIO and the system hang.
And so my guess is that this patch will break dom0 on a single-socket
system as well.
I've thought about that possibility before, but wasn't able to find a
system which actually does that.
May I ask why the rest of the memory isn't reported to the OS?
Sounds like I can't trust Linux resource management and probably need
to read the DRAM config to figure things out after all.
My question is whether what you are trying to do should ever be done for
a guest at all (any guest, not necessarily Xen).