Re: Error during update_runstate_area with KPTI activated

[Julien Grall <julien@xxxxxxx>]

Hi,

On 15/05/2020 10:57, Roger Pau Monné wrote:
> On Fri, May 15, 2020 at 10:23:16AM +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.
> >
> >
> > On 15/05/2020 10:10, Roger Pau Monné 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:
> > > > > On Fri, May 15, 2020 at 07:39:16AM +0000, Bertrand Marquis wrote:
> > > > > > On 14 May 2020, at 20:13, Julien Grall 
> > > > > > <julien.grall.oss@xxxxxxxxx<mailto:julien.grall.oss@xxxxxxxxx>> wrote:
> > > > > > "I'd love to do this, but we cant.  Older Linux used to have a virtual
> > > > > > buffer spanning a page boundary.  Changing the behaviour under that will
> > > > > > cause older setups to explode."
> > > > > Sorry this was long time ago, and details have faded. IIRC there was
> > > > > even a proposal (or patch set) that took that into account and allowed
> > > > > buffers to span across a page boundary by taking a reference to two
> > > > > different pages in that case.
> > > > I am not aware of a patch set. Juergen suggested a per-domain mapping but
> > > > there was no details how this could be done (my e-mail was left unanswered
> > > > [1]).
> > > >
> > > > If we were using the vmap() then we would need up 1MB per domain (assuming
> > > > 128 vCPUs). This sounds quite a bit and I think we need to agree whether it
> > > > would be an acceptable solution (this was also left unanswered [1]).
> > > Could we map/unmap the runtime area on domain switch at a per-cpu
> > > based linear space area? There's no reason to have all the runtime
> > > areas mapped all the time, you just care about the one from the
> > > running vcpu.
> > AFAICT, this is only used during context switching. This is a bit surprising
> > because I would expect it to be updated when the vCPU is running.
> >
> > So maybe we could just use map_domain_page() and take care manually about
> > cross-page boundary.
> >
> > > Maybe the overhead of that mapping and unmapping would be
> > > too high? But seeing that we are aiming at a secret-free Xen we would
> > > have to eventually go that route anyway.
> > The overhead is likely to be higher with the existing code as you have to
> > walk the guest page-tables and the p2m everytime in order to translate the
> > guest virtual address to a host physical address.
> Maybe I'm getting confused, but you actually want to avoid the guest
> page table walk, as the guest might be running with user-space page
> tables that don't have the linear address of the runtime area mapped,
> and hence you would like to do the walk only once (at hypercall
> registration time) and keep a reference to the page(s)?
That's right.

> I assumed the whole point of this was to avoid doing the page table
> walk when you need to update the runstate info area.
Sorry I wasn't clear. I was trying to answer to your question about the 
overhead.
The overhead with SH and the existing runstate implementation is going 
to be quite high because you would need to map/unmap each table during 
your walk. By removing the walk, you would now have only one map/unmap 
for the update which I think is acceptable.
So the change discussed in this thread is also going to be beneficial 
for SH even if we keep a map/unmap in the process.
Cheers,

--
Julien Grall