Re: Error during update_runstate_area with KPTI activated

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Fri, May 15, 2020 at 12:34:08PM +0000, Bertrand Marquis wrote:
> [CAUTION - EXTERNAL EMAIL] DO NOT reply, click links, or open attachments 
> unless you have verified the sender and know the content is safe.
> 
> Hi Roger
> 
> > On 15 May 2020, at 11:07, Roger Pau Monné <roger.pau@xxxxxxxxxx> wrote:
> > 
> > Can you please fix your email client to properly indent replies? It's
> > impossible to distinguish your added text when you reply from the
> > original email, as it's not indented in any way.
> 
> Sorry for that it seems my email client is detecting mail as being in rich 
> text and was answering keeping this format
> Please tell me if this was not fixed in this email.

Yes, this looks much better, thanks!

> > 
> > On Fri, May 15, 2020 at 09:21:34AM +0000, Bertrand Marquis wrote:
> >> On 15 May 2020, at 10:10, Roger Pau Monné 
> >> <roger.pau@xxxxxxxxxx<mailto:roger.pau@xxxxxxxxxx>> wrote:
> >> 
> >> On Fri, May 15, 2020 at 09:53:54AM +0100, Julien Grall wrote:
> >> [CAUTION - EXTERNAL EMAIL] DO NOT reply, click links, or open attachments 
> >> unless you have verified the sender and know the content is safe.
> >> 
> >> Hi,
> >> 
> >> On 15/05/2020 09:38, Roger Pau Monné wrote:
> > ... it's hard for the guest to figure out which non-populated areas
> > are safe for mapping arbitrary things. Ie: you might attempt to map
> > the runstate area on top of some MMIO area the guest is not aware of
> > for example if it has passthrough enabled.
> 
> With you answer and Julian ones it is now clear that the only solution is to 
> have the area provided by the guest.
> 
> > 
> >> - Xen maps read-only its own area to the guest at the provided address
> >> - Xen shall not modify any data in the runstate area of other cores/guests 
> >> (should already be the case)
> > 
> > I'm not sure those two restrictions are relevant, it's not relevant to
> > Xen whether the guest decided to overwrite the runstate area. Xen will
> > just write to it when doing a context switch in order to update it,
> > but it should never read from it.
> > 
> > Or are you meaning to map vcpu->runstate directly into the guest
> > physmap?
> > 
> > I think that's a bad idea as we would then have to force each vCPU
> > runstate to take up to a whole page, wasting lots of memory.
> 
> I was more thinking in putting all the runstate of all vCPUs in the same page 
> (or in several if this was not enough)
> 
> My main point was to have Xen directly modifying this one instead of doing 
> copies as Xen is just writing to it and never reads from it and the guest is 
> not suppose to write to it (but if it does that’s more or less an error on 
> its side).

I'm not saying it's not possible, but IMO having Xen allocate such
memory will be much more complicated than just using a guest provided
memory area and doing a copy.

Roger.