With the research we are doing using Bareflank, we set both of these flags
and also tell Linux that almost all (but a small part) of the lower 1MB is
free RAM to use as we don't emulate any of the legacy devices. From what we
can tell so far, Linux seems to handle this fine without any complaints.
>>> On 04.01.19 at 15:09, wrote:
> Do you agree however that PVH DomU could maybe use reduced hardware
> ACPI while Dom0 using whatever mode (reduced or not) is set by the
> native ACPI tables?
Yes, it's certainly worth exploring.
Jan
___
Xen-devel
On Fri, Jan 04, 2019 at 06:10:29AM -0700, Jan Beulich wrote:
> >>> On 03.01.19 at 18:45, wrote:
> > While looking at some tangential issues I realized that the 'VGA Not
> > Present' flag that Xen currently sets for PVH DomUs might be slightly
> > different from what we expect it to mean. The purpo
>>> On 03.01.19 at 18:45, wrote:
> While looking at some tangential issues I realized that the 'VGA Not
> Present' flag that Xen currently sets for PVH DomUs might be slightly
> different from what we expect it to mean. The purpose was that Xen
> would set this flag to denote there's no VGA MMIO r
On Thu, Jan 03, 2019 at 03:42:18PM -0500, Boris Ostrovsky wrote:
> On 1/3/19 12:45 PM, Roger Pau Monné wrote:
> > Hello,
> >
> > While looking at some tangential issues I realized that the 'VGA Not
> > Present' flag that Xen currently sets for PVH DomUs might be slightly
> > different from what we
On 1/3/19 12:45 PM, Roger Pau Monné wrote:
> Hello,
>
> While looking at some tangential issues I realized that the 'VGA Not
> Present' flag that Xen currently sets for PVH DomUs might be slightly
> different from what we expect it to mean. The purpose was that Xen
> would set this flag to denote t
Hello,
While looking at some tangential issues I realized that the 'VGA Not
Present' flag that Xen currently sets for PVH DomUs might be slightly
different from what we expect it to mean. The purpose was that Xen
would set this flag to denote there's no VGA MMIO region in the low
1MB, so that the
