On Fri, Jun 24, 2022 at 11:19 AM Marc Orr <marcorr@xxxxxxxxxx> wrote: > > On Fri, Jun 24, 2022 at 10:10 AM Dave Hansen <dave.hansen@xxxxxxxxx> wrote: > > > > On 6/24/22 10:06, Marc Orr wrote: > > > I think Peter's point is a little more nuanced than that. Once lazy > > > accept goes into the guest firmware -- without the feature negotiation > > > that Peter is suggesting -- cloud providers now have a bookkeeping > > > problem. Which images have kernels that can boot from a guest firmware > > > that doesn't pre-validate all the guest memory? > > > > Hold on a sec though... > > > > Is this a matter of > > > > can boot from a guest firmware that doesn't pre-validate all the > > guest memory? > > > > or > > > > can boot from a guest firmware that doesn't pre-validate all the > > guest memory ... with access to all of that guest's RAM? > > > > In other words, are we talking about "fails to boot" or "can't see all > > the RAM"? > > Ah... yeah, you're right, Dave -- I guess it's the latter. The guest > won't have access to all of the memory that the customer is paying > for. But that's still bad. If the customer buys a 96 GB VM and can > only see 4GB because they're kernel doesn't have these patches they're > going to be confused and frustrated. The other error case which might be more confusing to the customer is their kernel does have these patches, there is some misconfiguration and their VM boots slowly because the FW uses the accept all memory approach.
