>>> On 13.05.16 at 17:27, wrote:
> We're approaching the release date so I would like to wrap this up.
>
> As I understand it, there is indeed an issue in the emulator, but a
> proper fix that take into consideration all cases has not been proposed.
>
> Should we make this a blocker for the rele
We're approaching the release date so I would like to wrap this up.
As I understand it, there is indeed an issue in the emulator, but a
proper fix that take into consideration all cases has not been proposed.
Should we make this a blocker for the release? I'm inclined to say no
because it has bee
>>> Razvan Cojocaru 05/05/16 11:24 AM >>>
>On 05/04/2016 04:42 PM, Jan Beulich wrote:
> On 04.05.16 at 13:32, wrote:
>>> But while implementing a stub that falls back to the actual LOCK CMPXCHG
>>> and replacing hvm_copy_to_guest_virt() with it would indeed be an
>>> improvement (with the add
On 05/04/2016 04:42 PM, Jan Beulich wrote:
On 04.05.16 at 13:32, wrote:
>> But while implementing a stub that falls back to the actual LOCK CMPXCHG
>> and replacing hvm_copy_to_guest_virt() with it would indeed be an
>> improvement (with the added advantage of being able to treat
>> non-emula
>>> On 04.05.16 at 13:32, wrote:
> But while implementing a stub that falls back to the actual LOCK CMPXCHG
> and replacing hvm_copy_to_guest_virt() with it would indeed be an
> improvement (with the added advantage of being able to treat
> non-emulated LOCK CMPXCHG cases), I don't understand how
On 05/03/2016 06:13 PM, Jan Beulich wrote:
On 03.05.16 at 16:41, wrote:
>> On 05/03/2016 05:30 PM, Jan Beulich wrote:
>> On 03.05.16 at 16:20, wrote:
I've kept experimenting with the patch but can't quite figure out why
minimizing the lock scope to the writeback part would not
>>> On 03.05.16 at 16:41, wrote:
> On 05/03/2016 05:30 PM, Jan Beulich wrote:
> On 03.05.16 at 16:20, wrote:
>>> I've kept experimenting with the patch but can't quite figure out why
>>> minimizing the lock scope to the writeback part would not be sufficient,
>>> but it isn't.
>>>
>>> I.e. wi
On 05/03/2016 05:30 PM, Jan Beulich wrote:
On 03.05.16 at 16:20, wrote:
>> I've kept experimenting with the patch but can't quite figure out why
>> minimizing the lock scope to the writeback part would not be sufficient,
>> but it isn't.
>>
>> I.e. with this code:
>>
>> 3824 writeback:
>> 38
>>> On 03.05.16 at 16:20, wrote:
> I've kept experimenting with the patch but can't quite figure out why
> minimizing the lock scope to the writeback part would not be sufficient,
> but it isn't.
>
> I.e. with this code:
>
> 3824 writeback:
> 3825 ops->smp_lock(lock_prefix);
> 3826 swit
On 04/27/2016 10:14 AM, Razvan Cojocaru wrote:
> On 04/27/2016 09:22 AM, Jan Beulich wrote:
> On 26.04.16 at 19:23, wrote:
>>> On 04/26/16 19:03, George Dunlap wrote:
On 19/04/16 17:35, Jan Beulich wrote:
Razvan Cojocaru 04/19/16 1:01 PM >>>
>> I think this might be because
On 27/04/2016 07:25, Jan Beulich wrote:
On 26.04.16 at 19:39, wrote:
>> On 26/04/16 18:23, Razvan Cojocaru wrote:
>>> Regarding this version of the patch, Jan has asked for more information
>>> on the performance impact, but I'm not sure how to obtain it in a
>>> rigorous manner. If it is dec
On 04/27/2016 09:22 AM, Jan Beulich wrote:
On 26.04.16 at 19:23, wrote:
>> On 04/26/16 19:03, George Dunlap wrote:
>>> On 19/04/16 17:35, Jan Beulich wrote:
>>> Razvan Cojocaru 04/19/16 1:01 PM >>>
> I think this might be because the LOCK prefix should guarantee that the
> instru
>>> On 26.04.16 at 19:39, wrote:
> On 26/04/16 18:23, Razvan Cojocaru wrote:
>> Regarding this version of the patch, Jan has asked for more information
>> on the performance impact, but I'm not sure how to obtain it in a
>> rigorous manner. If it is decided that a version of this patch is
>> desir
>>> On 26.04.16 at 19:23, wrote:
> On 04/26/16 19:03, George Dunlap wrote:
>> On 19/04/16 17:35, Jan Beulich wrote:
>> Razvan Cojocaru 04/19/16 1:01 PM >>>
I think this might be because the LOCK prefix should guarantee that the
instruction that follows it has exclusive use of shared
On 26/04/16 18:23, Razvan Cojocaru wrote:
> On 04/26/16 19:03, George Dunlap wrote:
>> On 19/04/16 17:35, Jan Beulich wrote:
>> Razvan Cojocaru 04/19/16 1:01 PM >>>
I think this might be because the LOCK prefix should guarantee that the
instruction that follows it has exclusive use o
On 04/26/16 19:03, George Dunlap wrote:
> On 19/04/16 17:35, Jan Beulich wrote:
> Razvan Cojocaru 04/19/16 1:01 PM >>>
>>> I think this might be because the LOCK prefix should guarantee that the
>>> instruction that follows it has exclusive use of shared memory (for both
>>> reads and writes)
On 19/04/16 17:35, Jan Beulich wrote:
Razvan Cojocaru 04/19/16 1:01 PM >>>
>> I think this might be because the LOCK prefix should guarantee that the
>> instruction that follows it has exclusive use of shared memory (for both
>> reads and writes) but I might be misreading the docs:
>
> LOCK
>>> Razvan Cojocaru 04/19/16 1:01 PM >>>
>I think this might be because the LOCK prefix should guarantee that the
>instruction that follows it has exclusive use of shared memory (for both
>reads and writes) but I might be misreading the docs:
LOCK definitely has no effect on other than the instru
On 04/18/2016 07:45 PM, Jan Beulich wrote:
Razvan Cojocaru 04/18/16 2:40 PM >>>
>> On 04/14/2016 07:08 PM, Jan Beulich wrote:
>> Razvan Cojocaru 04/14/16 5:45 PM >>>
On 04/14/2016 06:40 PM, Jan Beulich wrote:
> To be honest, just having remembered that we do the write back for l
>>> Razvan Cojocaru 04/18/16 2:40 PM >>>
>On 04/14/2016 07:08 PM, Jan Beulich wrote:
> Razvan Cojocaru 04/14/16 5:45 PM >>>
>>> On 04/14/2016 06:40 PM, Jan Beulich wrote:
To be honest, just having remembered that we do the write back for locked
instructions using CMPXCHG, I'd first
On 04/14/2016 07:08 PM, Jan Beulich wrote:
Razvan Cojocaru 04/14/16 5:45 PM >>>
>> On 04/14/2016 06:40 PM, Jan Beulich wrote:
>>> To be honest, just having remembered that we do the write back for locked
>>> instructions using CMPXCHG, I'd first of all like to see a proper
>>> description
>>
>>> Razvan Cojocaru 04/14/16 6:00 PM >>>
>On 04/14/2016 06:44 PM, Jan Beulich wrote:
>> That's the performance effect on the hypervisor you talk about. But what
>> about
>> the guest, which all of the sudden gets another domain wide lock applied?
>
>Well, yes, there's bound to be some performance
>>> Andrew Cooper 04/14/16 5:46 PM >>>
>Short of having the instruction emulator convert any locked instruction
>into a stub, I can't think of a solution which works for both emulated
>and non-emulated instructions.
That's my understanding too.
Jan
_
>>> Razvan Cojocaru 04/14/16 5:45 PM >>>
>On 04/14/2016 06:40 PM, Jan Beulich wrote:
>> To be honest, just having remembered that we do the write back for locked
>> instructions using CMPXCHG, I'd first of all like to see a proper description
>> of "the _whole_ issue".
>
>I believe at least part o
On 04/14/2016 06:44 PM, Jan Beulich wrote:
> Razvan Cojocaru 04/14/16 7:57 AM >>>
>> On 04/14/16 07:35, Jan Beulich wrote:
>> Razvan Cojocaru 04/13/16 7:53 PM >>>
@@ -1589,6 +1591,8 @@ x86_emulate(
>>> >}
>>> >done_prefixes:
>>> >
+ops->smp_lock(lock_prefix);
+
On 14/04/16 16:40, Jan Beulich wrote:
Razvan Cojocaru 04/14/16 1:43 PM >>>
>> On 04/14/2016 01:35 PM, David Vrabel wrote:
>>> On 13/04/16 13:26, Razvan Cojocaru wrote:
LOCK-prefixed instructions are currenly allowed to run in parallel
in x86_emulate(), which can lead the guest into
On 04/14/2016 06:40 PM, Jan Beulich wrote:
Razvan Cojocaru 04/14/16 1:43 PM >>>
>> On 04/14/2016 01:35 PM, David Vrabel wrote:
>>> On 13/04/16 13:26, Razvan Cojocaru wrote:
LOCK-prefixed instructions are currenly allowed to run in parallel
in x86_emulate(), which can lead the guest
Razvan Cojocaru 04/14/16 7:57 AM >>>
>On 04/14/16 07:35, Jan Beulich wrote:
> Razvan Cojocaru 04/13/16 7:53 PM >>>
>>> @@ -1589,6 +1591,8 @@ x86_emulate(
>> >}
>> >done_prefixes:
>> >
>>> +ops->smp_lock(lock_prefix);
>>> +
>> >if ( rex_prefix & REX_W )
>> >op_by
On 04/14/2016 06:31 PM, Jan Beulich wrote:
Razvan Cojocaru 04/14/16 10:50 AM >>>
>> On 04/14/2016 07:35 AM, Jan Beulich wrote:
--- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -25,6 +25,8 @@
>>> >#include
>>> >#include
>>> >
> +DEFINE_PERCPU_RWLOC
>>> Razvan Cojocaru 04/14/16 1:43 PM >>>
>On 04/14/2016 01:35 PM, David Vrabel wrote:
>> On 13/04/16 13:26, Razvan Cojocaru wrote:
>>> LOCK-prefixed instructions are currenly allowed to run in parallel
>>> in x86_emulate(), which can lead the guest into an undefined state.
>>> This patch fixes the
>>> Razvan Cojocaru 04/14/16 11:08 AM >>>
>On 04/14/2016 08:56 AM, Razvan Cojocaru wrote:
--- a/xen/arch/x86/mm.c
>> +++ b/xen/arch/x86/mm.c
>> @@ -112,6 +112,7 @@
>>> > >#include
>>> > >#include
>>> > >#include
>> +#include
>>> >
>>> > This header shouldn't be include
>>> Razvan Cojocaru 04/14/16 10:50 AM >>>
>On 04/14/2016 07:35 AM, Jan Beulich wrote:
>>> --- a/xen/arch/x86/hvm/emulate.c
>>> >+++ b/xen/arch/x86/hvm/emulate.c
>>> >@@ -25,6 +25,8 @@
>> >#include
>> >#include
>> >
>>> >+DEFINE_PERCPU_RWLOCK_GLOBAL(emulate_locked_rwlock);
>> You should try ha
On 04/14/2016 01:35 PM, David Vrabel wrote:
> On 13/04/16 13:26, Razvan Cojocaru wrote:
>> LOCK-prefixed instructions are currenly allowed to run in parallel
>> in x86_emulate(), which can lead the guest into an undefined state.
>> This patch fixes the issue.
>
> Is this sufficient? What if anoth
On 13/04/16 13:26, Razvan Cojocaru wrote:
> LOCK-prefixed instructions are currenly allowed to run in parallel
> in x86_emulate(), which can lead the guest into an undefined state.
> This patch fixes the issue.
Is this sufficient? What if another VCPU is running on another PCPU and
doing an unemu
On 04/14/2016 08:56 AM, Razvan Cojocaru wrote:
>>> --- a/xen/arch/x86/mm.c
>>> >> +++ b/xen/arch/x86/mm.c
>>> >> @@ -112,6 +112,7 @@
>> > >#include
>> > >#include
>> > >#include
>>> >> +#include
>> >
>> > This header shouldn't be included here. You need to move the declarations
>> > elsewh
On 04/14/2016 07:35 AM, Jan Beulich wrote:
>> --- a/xen/arch/x86/hvm/emulate.c
>> >+++ b/xen/arch/x86/hvm/emulate.c
>> >@@ -25,6 +25,8 @@
> >#include
> >#include
> >
>> >+DEFINE_PERCPU_RWLOCK_GLOBAL(emulate_locked_rwlock);
> You should try hard to make this static.
On second though, this woul
On 04/14/2016 11:18 AM, Juergen Gross wrote:
> On 14/04/16 10:01, Andrew Cooper wrote:
>> On 14/04/2016 08:46, Juergen Gross wrote:
>>> On 14/04/16 08:31, Razvan Cojocaru wrote:
On 04/14/16 09:09, Juergen Gross wrote:
> On 14/04/16 07:56, Razvan Cojocaru wrote:
>> This indeed doesn't g
On 14/04/16 10:01, Andrew Cooper wrote:
> On 14/04/2016 08:46, Juergen Gross wrote:
>> On 14/04/16 08:31, Razvan Cojocaru wrote:
>>> On 04/14/16 09:09, Juergen Gross wrote:
On 14/04/16 07:56, Razvan Cojocaru wrote:
> This indeed doesn't guard against LOCKed instructions being run in
>
On 04/14/2016 11:07 AM, Andrew Cooper wrote:
> On 14/04/2016 06:56, Razvan Cojocaru wrote:
>>
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -272,6 +272,8 @@ struct domain *domain_create(domid_t domid, unsigned
int domcr_flags,
>>> >
>>> >TRACE_1D(TRC_DOM0_DOM_ADD
On 14/04/2016 06:56, Razvan Cojocaru wrote:
>
>>> --- a/xen/common/domain.c
>>> +++ b/xen/common/domain.c
>>> @@ -272,6 +272,8 @@ struct domain *domain_create(domid_t domid, unsigned
>>> int domcr_flags,
>> >
>> >TRACE_1D(TRC_DOM0_DOM_ADD, d->domain_id);
>> >
>>> +percpu_rwlock_resource
On 14/04/2016 08:46, Juergen Gross wrote:
> On 14/04/16 08:31, Razvan Cojocaru wrote:
>> On 04/14/16 09:09, Juergen Gross wrote:
>>> On 14/04/16 07:56, Razvan Cojocaru wrote:
This indeed doesn't guard against LOCKed instructions being run in
parallel with and without emulation, however th
On 14/04/16 08:31, Razvan Cojocaru wrote:
> On 04/14/16 09:09, Juergen Gross wrote:
>> On 14/04/16 07:56, Razvan Cojocaru wrote:
>>> This indeed doesn't guard against LOCKed instructions being run in
>>> parallel with and without emulation, however that is a case that should
>>> almost never occur
On 04/14/16 09:09, Juergen Gross wrote:
> On 14/04/16 07:56, Razvan Cojocaru wrote:
>> This indeed doesn't guard against LOCKed instructions being run in
>> parallel with and without emulation, however that is a case that should
>> almost never occur - at least not with introspection, where current
On 14/04/16 07:56, Razvan Cojocaru wrote:
> This indeed doesn't guard against LOCKed instructions being run in
> parallel with and without emulation, however that is a case that should
> almost never occur - at least not with introspection, where currently
> all emulation happens as a result of EPT
On 04/14/16 07:35, Jan Beulich wrote:
Razvan Cojocaru 04/13/16 7:53 PM >>>
>> LOCK-prefixed instructions are currenly allowed to run in parallel
>> in x86_emulate(), which can lead the guest into an undefined state.
>> This patch fixes the issue.
>
> ... by ... (read: Too brief a description
>>> Razvan Cojocaru 04/13/16 7:53 PM >>>
>LOCK-prefixed instructions are currenly allowed to run in parallel
>in x86_emulate(), which can lead the guest into an undefined state.
>This patch fixes the issue.
... by ... (read: Too brief a description)
>--- a/xen/arch/x86/hvm/emulate.c
>+++ b/xen/a
LOCK-prefixed instructions are currenly allowed to run in parallel
in x86_emulate(), which can lead the guest into an undefined state.
This patch fixes the issue.
Signed-off-by: Razvan Cojocaru
---
tools/tests/x86_emulator/test_x86_emulator.c | 12
xen/arch/x86/hvm/emulate.c
47 matches
Mail list logo
