Re: Ongoing/future speculative mitigation work

From: George Dunlap <george.dunlap@citrix.com>
To: Jan Beulich <JBeulich@suse.com>, Wei Liu <wei.liu2@citrix.com>
Cc: Martin Pohlack <mpohlack@amazon.de>,
	Julien Grall <julien.grall@arm.com>,
	Joao Martins <joao.m.martins@oracle.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Mihai Dontu <mdontu@bitdefender.com>,
	Marek Marczykowski <marmarek@invisiblethingslab.com>,
	Anthony Liguori <aliguori@amazon.com>,
	uwed@amazon.de, Lars Kurth <lars.kurth@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Ross Philipson <ross.philipson@oracle.com>,
	Dario Faggioli <dfaggioli@suse.com>, Matt Wilson <msw@amazon.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Juergen Gross <jgross@suse.com>,
	Sergey Dyasli <sergey.dyasli@citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Xen-devel List <xen-devel@lists.xen.org>,
	Daniel Kiper <daniel.kiper@oracle.com>,
	David Woodhouse <dwmw@amazon.co.uk>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: Ongoing/future speculative mitigation work
Date: Fri, 26 Oct 2018 11:51:13 +0100	[thread overview]
Message-ID: <fa316114-f031-c17f-3af6-0b6893cba813@citrix.com> (raw)
In-Reply-To: <5BD2E4EA02000078001F4F96@prv1-mh.provo.novell.com>

On 10/26/2018 10:56 AM, Jan Beulich wrote:
>>>> On 26.10.18 at 11:28, <wei.liu2@citrix.com> wrote:
>> On Fri, Oct 26, 2018 at 03:16:15AM -0600, Jan Beulich wrote:
>>>>>> On 25.10.18 at 18:29, <andrew.cooper3@citrix.com> wrote:
>>>> A split xenheap model means that data pertaining to other guests isn't
>>>> mapped in the context of this vcpu, so cannot be brought into the cache.
>>>
>>> It was not clear to me from Wei's original mail that talk here is
>>> about "split" in a sense of "per-domain"; I was assuming the
>>> CONFIG_SEPARATE_XENHEAP mode instead.
>>
>> The split heap was indeed referring to CONFIG_SEPARATE_XENHEAP mode, yet
>> I what I wanted most is the partial direct map which reduces the amount
>> of data mapped inside Xen context -- the original idea was removing
>> direct map discussed during one of the calls IIRC. I thought making the
>> partial direct map mode work and make it as small as possible will get
>> us 90% there.
>>
>> The "per-domain" heap is a different work item.
> 
> But if we mean to go that route, going (back) to the separate
> Xen heap model seems just like an extra complication to me.
> Yet I agree that this would remove the need for a fair chunk of
> the direct map. Otoh a statically partitioned Xen heap would
> bring back scalability issues which we had specifically meant to
> get rid of by moving away from that model.

I think turning SEPARATE_XENHEAP back on would just be the first step.
We definitely would then need to sort things out so that it's scalable
again.

After system set-up, the key difference between xenheap and domheap
pages is that xenheap pages are assumed to be always mapped (i.e., you
can keep a pointer to them and it will be valid), whereas domheap pages
cannot assumed to be mapped, and need to be wrapped with
[un]map_domain_page().

The basic solution involves having a xenheap virtual address mapping
area not tied to the physical layout of the memory.  domheap and xenheap
memory would have to come from the same pool, but xenheap would need to
be mapped into the xenheap virtual memory region before being returned.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel