>>> On 11.12.18 at 19:05, wrote:
> On Fri, Oct 26, 2018 at 05:20:47AM -0600, Jan Beulich wrote:
>> >>> On 26.10.18 at 12:51, wrote:
>> > The basic solution involves having a xenheap virtual address mapping
>> > area not tied to the physical layout of the memory. domheap and xenheap
>> > memory w
On Fri, Oct 26, 2018 at 05:20:47AM -0600, Jan Beulich wrote:
> >>> On 26.10.18 at 12:51, wrote:
> > On 10/26/2018 10:56 AM, Jan Beulich wrote:
> > On 26.10.18 at 11:28, wrote:
> >>> On Fri, Oct 26, 2018 at 03:16:15AM -0600, Jan Beulich wrote:
> >>> On 25.10.18 at 18:29, wrote:
> > A
On 12/10/18 12:12 PM, George Dunlap wrote:
> On 12/7/18 6:40 PM, Wei Liu wrote:
>> On Thu, Oct 18, 2018 at 06:46:22PM +0100, Andrew Cooper wrote:
>>> Hello,
>>>
>>> This is an accumulation and summary of various tasks which have been
>>> discussed since the revelation of the speculative security is
On 12/7/18 6:40 PM, Wei Liu wrote:
> On Thu, Oct 18, 2018 at 06:46:22PM +0100, Andrew Cooper wrote:
>> Hello,
>>
>> This is an accumulation and summary of various tasks which have been
>> discussed since the revelation of the speculative security issues in
>> January, and also an invitation to disc
On Thu, Oct 18, 2018 at 06:46:22PM +0100, Andrew Cooper wrote:
> Hello,
>
> This is an accumulation and summary of various tasks which have been
> discussed since the revelation of the speculative security issues in
> January, and also an invitation to discuss alternative ideas. They are
> x86 sp
On Fri, 2018-10-26 at 06:01 -0600, Tamas K Lengyel wrote:
> On Fri, Oct 26, 2018, 1:49 AM Dario Faggioli
> wrote:
> >
> > I haven't done this kind of benchmark yet, but I'd say that, if
> > every
> > vCPU of every domain is doing 100% CPU intensive work, core-
> > scheduling
> > isn't going to ma
On Fri, Oct 26, 2018, 1:49 AM Dario Faggioli wrote:
> On Thu, 2018-10-25 at 12:35 -0600, Tamas K Lengyel wrote:
> > On Thu, Oct 25, 2018 at 12:13 PM Andrew Cooper
> > wrote:
> > >
> > > TBH, I'd perhaps start with an admin control which lets them switch
> > > between the two modes, and some inst
>>> On 26.10.18 at 13:43, wrote:
> On 10/26/2018 12:33 PM, Jan Beulich wrote:
> On 26.10.18 at 13:24, wrote:
>>> On 10/26/2018 12:20 PM, Jan Beulich wrote:
>>> On 26.10.18 at 12:51, wrote:
> The basic solution involves having a xenheap virtual address mapping
> area not tied to t
On 10/26/2018 12:33 PM, Jan Beulich wrote:
On 26.10.18 at 13:24, wrote:
>> On 10/26/2018 12:20 PM, Jan Beulich wrote:
>> On 26.10.18 at 12:51, wrote:
The basic solution involves having a xenheap virtual address mapping
area not tied to the physical layout of the memory. domhea
>>> On 26.10.18 at 13:24, wrote:
> On 10/26/2018 12:20 PM, Jan Beulich wrote:
> On 26.10.18 at 12:51, wrote:
>>> 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
On 10/26/2018 12:20 PM, Jan Beulich wrote:
On 26.10.18 at 12:51, wrote:
>> On 10/26/2018 10:56 AM, Jan Beulich wrote:
>> On 26.10.18 at 11:28, wrote:
On Fri, Oct 26, 2018 at 03:16:15AM -0600, Jan Beulich wrote:
On 25.10.18 at 18:29, wrote:
>> A split xenheap model mean
>>> On 26.10.18 at 12:51, wrote:
> On 10/26/2018 10:56 AM, Jan Beulich wrote:
> On 26.10.18 at 11:28, wrote:
>>> On Fri, Oct 26, 2018 at 03:16:15AM -0600, Jan Beulich wrote:
>>> On 25.10.18 at 18:29, wrote:
> A split xenheap model means that data pertaining to other guests isn't
On 10/26/2018 10:56 AM, Jan Beulich wrote:
On 26.10.18 at 11:28, wrote:
>> On Fri, Oct 26, 2018 at 03:16:15AM -0600, Jan Beulich wrote:
>> On 25.10.18 at 18:29, wrote:
A split xenheap model means that data pertaining to other guests isn't
mapped in the context of this vcpu, so
On 10/25/2018 07:13 PM, Andrew Cooper wrote:
> On 25/10/18 18:58, Tamas K Lengyel wrote:
>> On Thu, Oct 25, 2018 at 11:43 AM Andrew Cooper
>> wrote:
>>> On 25/10/18 18:35, Tamas K Lengyel wrote:
On Thu, Oct 25, 2018 at 11:02 AM George Dunlap
wrote:
> On 10/25/2018 05:55 PM, Andrew
>>> On 26.10.18 at 11:28, wrote:
> On Fri, Oct 26, 2018 at 03:16:15AM -0600, Jan Beulich wrote:
>> >>> On 25.10.18 at 18:29, 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 w
On Fri, Oct 26, 2018 at 03:16:15AM -0600, Jan Beulich wrote:
> >>> On 25.10.18 at 18:29, 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 ma
>>> On 25.10.18 at 18:29, 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 as
On Thu, 2018-10-25 at 12:35 -0600, Tamas K Lengyel wrote:
> On Thu, Oct 25, 2018 at 12:13 PM Andrew Cooper
> wrote:
> >
> > TBH, I'd perhaps start with an admin control which lets them switch
> > between the two modes, and some instructions on how/why they might
> > want
> > to try switching.
> >
On Thu, 2018-10-25 at 11:29 -0600, Tamas K Lengyel wrote:
> On Thu, Oct 25, 2018 at 11:23 AM Dario Faggioli
> wrote:
> >
> > Having _everyone_ wanting to do actual stuff on the CPUs is, IMO,
> > one
> > of the worst workloads for hyperthreading, and it is in fact a
> > workload
> > where I've alw
On 25/10/18 19:35, Tamas K Lengyel wrote:
> On Thu, Oct 25, 2018 at 12:13 PM Andrew Cooper
> wrote:
>> On 25/10/18 18:58, Tamas K Lengyel wrote:
>>> On Thu, Oct 25, 2018 at 11:43 AM Andrew Cooper
>>> wrote:
On 25/10/18 18:35, Tamas K Lengyel wrote:
> On Thu, Oct 25, 2018 at 11:02 AM Geor
On Thu, Oct 25, 2018 at 12:13 PM Andrew Cooper
wrote:
>
> On 25/10/18 18:58, Tamas K Lengyel wrote:
> > On Thu, Oct 25, 2018 at 11:43 AM Andrew Cooper
> > wrote:
> >> On 25/10/18 18:35, Tamas K Lengyel wrote:
> >>> On Thu, Oct 25, 2018 at 11:02 AM George Dunlap
> >>> wrote:
> On 10/25/2018
On 25/10/18 18:58, Tamas K Lengyel wrote:
> On Thu, Oct 25, 2018 at 11:43 AM Andrew Cooper
> wrote:
>> On 25/10/18 18:35, Tamas K Lengyel wrote:
>>> On Thu, Oct 25, 2018 at 11:02 AM George Dunlap
>>> wrote:
On 10/25/2018 05:55 PM, Andrew Cooper wrote:
> On 24/10/18 16:24, Tamas K Lengye
On Thu, Oct 25, 2018 at 11:43 AM Andrew Cooper
wrote:
>
> On 25/10/18 18:35, Tamas K Lengyel wrote:
> > On Thu, Oct 25, 2018 at 11:02 AM George Dunlap
> > wrote:
> >> On 10/25/2018 05:55 PM, Andrew Cooper wrote:
> >>> On 24/10/18 16:24, Tamas K Lengyel wrote:
> > A solution to this issue was
On 25/10/18 18:35, Tamas K Lengyel wrote:
> On Thu, Oct 25, 2018 at 11:02 AM George Dunlap
> wrote:
>> On 10/25/2018 05:55 PM, Andrew Cooper wrote:
>>> On 24/10/18 16:24, Tamas K Lengyel wrote:
> A solution to this issue was proposed, whereby Xen synchronises siblings
> on vmexit/entry, s
On Thu, Oct 25, 2018 at 11:02 AM George Dunlap wrote:
>
> On 10/25/2018 05:55 PM, Andrew Cooper wrote:
> > On 24/10/18 16:24, Tamas K Lengyel wrote:
> >>> A solution to this issue was proposed, whereby Xen synchronises siblings
> >>> on vmexit/entry, so we are never executing code in two different
On Thu, Oct 25, 2018 at 11:23 AM Dario Faggioli wrote:
>
> On Thu, 2018-10-25 at 10:25 -0600, Tamas K Lengyel wrote:
> > On Thu, Oct 25, 2018 at 10:01 AM Dario Faggioli
> > wrote:
> > >
> > > Which is indeed very interesting. But, as we're discussing in the
> > > other
> > > thread, I would, in y
On Thu, 2018-10-25 at 10:25 -0600, Tamas K Lengyel wrote:
> On Thu, Oct 25, 2018 at 10:01 AM Dario Faggioli
> wrote:
> >
> > Which is indeed very interesting. But, as we're discussing in the
> > other
> > thread, I would, in your case, do some more measurements, varying
> > the
> > configuration
On 10/25/2018 05:50 PM, Andrew Cooper wrote:
> On 25/10/18 17:43, George Dunlap wrote:
>> On 10/25/2018 05:29 PM, Andrew Cooper wrote:
>>> On 25/10/18 16:02, Jan Beulich wrote:
>>> On 25.10.18 at 16:56, wrote:
> On 10/25/2018 03:50 PM, Jan Beulich wrote:
> On 22.10.18 at 16:55, wr
On 10/25/2018 05:55 PM, Andrew Cooper wrote:
> On 24/10/18 16:24, Tamas K Lengyel wrote:
>>> A solution to this issue was proposed, whereby Xen synchronises siblings
>>> on vmexit/entry, so we are never executing code in two different
>>> privilege levels. Getting this working would make it safe t
On 24/10/18 16:24, Tamas K Lengyel wrote:
>> A solution to this issue was proposed, whereby Xen synchronises siblings
>> on vmexit/entry, so we are never executing code in two different
>> privilege levels. Getting this working would make it safe to continue
>> using hyperthreading even in the pre
On 25/10/18 17:43, George Dunlap wrote:
> On 10/25/2018 05:29 PM, Andrew Cooper wrote:
>> On 25/10/18 16:02, Jan Beulich wrote:
>> On 25.10.18 at 16:56, wrote:
On 10/25/2018 03:50 PM, Jan Beulich wrote:
On 22.10.18 at 16:55, wrote:
>> On Thu, Oct 18, 2018 at 06:46:22PM +0100
On 10/25/2018 05:29 PM, Andrew Cooper wrote:
> On 25/10/18 16:02, Jan Beulich wrote:
> On 25.10.18 at 16:56, wrote:
>>> On 10/25/2018 03:50 PM, Jan Beulich wrote:
>>> On 22.10.18 at 16:55, wrote:
> On Thu, Oct 18, 2018 at 06:46:22PM +0100, Andrew Cooper wrote:
>> An easy first ste
On 25/10/18 16:02, Jan Beulich wrote:
On 25.10.18 at 16:56, wrote:
>> On 10/25/2018 03:50 PM, Jan Beulich wrote:
>> On 22.10.18 at 16:55, wrote:
On Thu, Oct 18, 2018 at 06:46:22PM +0100, Andrew Cooper wrote:
> An easy first step here is to remove Xen's directmap, which will mean
On Thu, Oct 25, 2018 at 10:01 AM Dario Faggioli wrote:
>
> On Wed, 2018-10-24 at 09:24 -0600, Tamas K Lengyel wrote:
> > > A solution to this issue was proposed, whereby Xen synchronises
> > > siblings
> > > on vmexit/entry, so we are never executing code in two different
> > > privilege levels.
On Wed, 2018-10-24 at 09:24 -0600, Tamas K Lengyel wrote:
> > A solution to this issue was proposed, whereby Xen synchronises
> > siblings
> > on vmexit/entry, so we are never executing code in two different
> > privilege levels. Getting this working would make it safe to
> > continue
> > using hy
>>> On 25.10.18 at 16:56, wrote:
> On 10/25/2018 03:50 PM, Jan Beulich wrote:
> On 22.10.18 at 16:55, wrote:
>>> On Thu, Oct 18, 2018 at 06:46:22PM +0100, Andrew Cooper wrote:
An easy first step here is to remove Xen's directmap, which will mean
that guests general RAM isn't mapped
On 10/25/2018 03:50 PM, Jan Beulich wrote:
On 22.10.18 at 16:55, wrote:
>> On Thu, Oct 18, 2018 at 06:46:22PM +0100, Andrew Cooper wrote:
>>> An easy first step here is to remove Xen's directmap, which will mean
>>> that guests general RAM isn't mapped by default into Xen's address
>>> space.
>>> On 22.10.18 at 16:55, wrote:
> On Thu, Oct 18, 2018 at 06:46:22PM +0100, Andrew Cooper wrote:
>> An easy first step here is to remove Xen's directmap, which will mean
>> that guests general RAM isn't mapped by default into Xen's address
>> space. This will come with some performance hit, as t
> A solution to this issue was proposed, whereby Xen synchronises siblings
> on vmexit/entry, so we are never executing code in two different
> privilege levels. Getting this working would make it safe to continue
> using hyperthreading even in the presence of L1TF. Obviously, its going
> to come
On 22/10/18 16:09, Woodhouse, David wrote:
> Adding Stefan to Cc.
>
> Should we take this to the spexen or another mailing list?
Now that L1TF is public, so is all of this. I see no reason to continue
it in private.
~Andrew
___
Xen-devel mailing list
Adding Stefan to Cc.
Should we take this to the spexen or another mailing list?
On Mon, 2018-10-22 at 15:55 +0100, Wei Liu wrote:
> On Thu, Oct 18, 2018 at 06:46:22PM +0100, Andrew Cooper wrote:
> > Hello,
> >
> > This is an accumulation and summary of various tasks which have been
> > discusse
On Thu, Oct 18, 2018 at 06:46:22PM +0100, Andrew Cooper wrote:
> Hello,
>
> This is an accumulation and summary of various tasks which have been
> discussed since the revelation of the speculative security issues in
> January, and also an invitation to discuss alternative ideas. They are
> x86 sp
On Fri, 2018-10-19 at 13:17 +0100, Andrew Cooper wrote:
> [...]
>
> > Therefore, although I certainly think we _must_ have the proper
> > scheduler enhancements in place (and in fact I'm working on that :-D)
> > it should IMO still be possible for the user to decide whether or not
> > to use them
On 19/10/18 09:09, Dario Faggioli wrote:
> On Thu, 2018-10-18 at 18:46 +0100, Andrew Cooper wrote:
>> Hello,
>>
> Hey,
>
> This is very accurate and useful... thanks for it. :-)
>
>> 1) A secrets-free hypervisor.
>>
>> Basically every hypercall can be (ab)used by a guest, and used as an
>> arbitrar
On Thu, 2018-10-18 at 18:46 +0100, Andrew Cooper wrote:
> Hello,
>
Hey,
This is very accurate and useful... thanks for it. :-)
> 1) A secrets-free hypervisor.
>
> Basically every hypercall can be (ab)used by a guest, and used as an
> arbitrary cache-load gadget. Logically, this is the first ha
45 matches
Mail list logo
