Re: [Xen-devel] further post-Meltdown-bad-aid performance thoughts

2018-01-22 Thread Matt Wilson
On Fri, Jan 19, 2018 at 03:43:26PM +, George Dunlap wrote: [...] > But there will surely be more attacks like this (in fact, there may > already be some in the works[2]). [...] > -George > > [1] https://lwn.net/SubscriberLink/744287/02dd9bc503409ca3/ > [2] skyfallattack.com In case anyo

Re: [Xen-devel] further post-Meltdown-bad-aid performance thoughts

2018-01-22 Thread George Dunlap
On 01/22/2018 05:04 PM, Jan Beulich wrote: On 22.01.18 at 16:15, wrote: >> On 01/22/2018 01:30 PM, Jan Beulich wrote: >> On 22.01.18 at 13:33, wrote: What I'm proposing is something like this: * We have a "global" region of Xen memory that is mapped by all processors.

Re: [Xen-devel] further post-Meltdown-bad-aid performance thoughts

2018-01-22 Thread Jan Beulich
>>> On 22.01.18 at 16:15, wrote: > On 01/22/2018 01:30 PM, Jan Beulich wrote: > On 22.01.18 at 13:33, wrote: >>> What I'm proposing is something like this: >>> >>> * We have a "global" region of Xen memory that is mapped by all >>> processors. This will contain everything we consider not sen

Re: [Xen-devel] further post-Meltdown-bad-aid performance thoughts

2018-01-22 Thread George Dunlap
On 01/22/2018 01:30 PM, Jan Beulich wrote: On 22.01.18 at 13:33, wrote: >> On 01/22/2018 09:25 AM, Jan Beulich wrote: >> On 19.01.18 at 18:00, wrote: On 01/19/2018 04:36 PM, Jan Beulich wrote: On 19.01.18 at 16:43, wrote: >> So what if instead of trying to close the "w

Re: [Xen-devel] further post-Meltdown-bad-aid performance thoughts

2018-01-22 Thread Jan Beulich
>>> On 22.01.18 at 13:33, wrote: > On 01/22/2018 09:25 AM, Jan Beulich wrote: > On 19.01.18 at 18:00, wrote: >>> On 01/19/2018 04:36 PM, Jan Beulich wrote: >>> On 19.01.18 at 16:43, wrote: > So what if instead of trying to close the "windows", we made it so that > there was nothi

Re: [Xen-devel] further post-Meltdown-bad-aid performance thoughts

2018-01-22 Thread George Dunlap
On 01/22/2018 09:25 AM, Jan Beulich wrote: On 19.01.18 at 18:00, wrote: >> On 01/19/2018 04:36 PM, Jan Beulich wrote: >> On 19.01.18 at 16:43, wrote: So what if instead of trying to close the "windows", we made it so that there was nothing through the windows to see? If no mat

Re: [Xen-devel] further post-Meltdown-bad-aid performance thoughts

2018-01-22 Thread Jan Beulich
>>> On 19.01.18 at 18:00, wrote: > On 01/19/2018 04:36 PM, Jan Beulich wrote: > On 19.01.18 at 16:43, wrote: >>> So what if instead of trying to close the "windows", we made it so that >>> there was nothing through the windows to see? If no matter what the >>> hypervisor speculatively execut

Re: [Xen-devel] further post-Meltdown-bad-aid performance thoughts

2018-01-19 Thread Jan Beulich
>>> On 19.01.18 at 16:43, wrote: > On 01/19/2018 02:37 PM, Jan Beulich wrote: >> All, >> >> along the lines of the relatively easy first step submitted yesterday, >> I've had some further thoughts in that direction. A fundamental >> thing for this is of course to first of all establish what kind

Re: [Xen-devel] further post-Meltdown-bad-aid performance thoughts

2018-01-19 Thread George Dunlap
On 01/19/2018 04:36 PM, Jan Beulich wrote: On 19.01.18 at 16:43, wrote: >> On 01/19/2018 02:37 PM, Jan Beulich wrote: >>> All, >>> >>> along the lines of the relatively easy first step submitted yesterday, >>> I've had some further thoughts in that direction. A fundamental >>> thing for this

Re: [Xen-devel] further post-Meltdown-bad-aid performance thoughts

2018-01-19 Thread George Dunlap
On 01/19/2018 02:37 PM, Jan Beulich wrote: > All, > > along the lines of the relatively easy first step submitted yesterday, > I've had some further thoughts in that direction. A fundamental > thing for this is of course to first of all establish what kind of > information we consider safe to expo

[Xen-devel] further post-Meltdown-bad-aid performance thoughts

2018-01-19 Thread Jan Beulich
All, along the lines of the relatively easy first step submitted yesterday, I've had some further thoughts in that direction. A fundamental thing for this is of course to first of all establish what kind of information we consider safe to expose (in the long run) to guests. The current state of t