the callers are now switched to _mfn(domain_page_to_mfn(...)).
>
> Signed-off-by: Julien Grall
Acked-by: Razvan Cojocaru
Thanks,
Razvan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 10/30/2017 07:07 PM, Tamas K Lengyel wrote:
> On Mon, Oct 30, 2017 at 11:01 AM, Razvan Cojocaru
> wrote:
>> On 10/30/2017 06:39 PM, Tamas K Lengyel wrote:
>>> On Mon, Oct 30, 2017 at 10:24 AM, Razvan Cojocaru
>>> wrote:
>>>> On 30.10.2017 18:01, T
On 10/30/2017 06:39 PM, Tamas K Lengyel wrote:
> On Mon, Oct 30, 2017 at 10:24 AM, Razvan Cojocaru
> wrote:
>> On 30.10.2017 18:01, Tamas K Lengyel wrote:
>>> On Mon, Oct 30, 2017 at 4:32 AM, Alexandru Isaila
>>> wrote:
>>>> This patch is addin
On 30.10.2017 18:01, Tamas K Lengyel wrote:
> On Mon, Oct 30, 2017 at 4:32 AM, Alexandru Isaila
> wrote:
>> This patch is adding a way to enable/disable nested pagefault
>> events. It introduces the xc_monitor_nested_pagefault function
>> and adds the nested_pagefault_disabled in the monitor struc
gt;>>> HVMOP_altp2m_set_mem_access_multi has been added as a HVMOP (as opposed
>>>>>> to a
>>>>>> DOMCTL) for consistency with its HVMOP_altp2m_set_mem_access counterpart
>> (and
>>>>>> hence with the original altp2m design,
On 23.10.2017 11:10, Jan Beulich wrote:
>>>> On 20.10.17 at 18:32, wrote:
>> On 10/20/2017 07:15 PM, Wei Liu wrote:
>>> On Mon, Oct 16, 2017 at 08:07:41PM +0300, Petre Pircalabu wrote:
>>>> From: Razvan Cojocaru
>>>>
>>>> Fo
On 10/20/2017 07:39 PM, Wei Liu wrote:
> On Fri, Oct 20, 2017 at 07:32:50PM +0300, Razvan Cojocaru wrote:
>> On 10/20/2017 07:15 PM, Wei Liu wrote:
>>> On Mon, Oct 16, 2017 at 08:07:41PM +0300, Petre Pircalabu wrote:
>>>> From: Razvan Cojocaru
>>>
On 10/20/2017 07:15 PM, Wei Liu wrote:
> On Mon, Oct 16, 2017 at 08:07:41PM +0300, Petre Pircalabu wrote:
>> From: Razvan Cojocaru
>>
>> For the default EPT view we have xc_set_mem_access_multi(), which
>> is able to set an array of pages to an array of access rights
On 20.10.2017 11:37, Yi Zhang wrote:
> On 2017-10-19 at 12:07:44 +0300, Razvan Cojocaru wrote:
>> On 19.10.2017 11:04, Zhang Yi wrote:
>>> From: Zhang Yi Z
>>>
>>> Hi All,
>>>
>>> Here is a patch-series which adding EPT-Based Sub-page Wr
On 20.10.2017 11:37, Yi Zhang wrote:
> On 2017-10-19 at 12:07:44 +0300, Razvan Cojocaru wrote:
>> On 19.10.2017 11:04, Zhang Yi wrote:
>>> From: Zhang Yi Z
>>>
>>> Hi All,
>>>
>>> Here is a patch-series which adding EPT-Based Sub-page Wr
On 19.10.2017 11:04, Zhang Yi wrote:
> From: Zhang Yi Z
>
> Hi All,
>
> Here is a patch-series which adding EPT-Based Sub-page Write Protection
> Support. You can get It's software developer manuals from:
>
> https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#define DPRINTF(a, b...) fprintf(stderr, a, ## b)
> +#define ERROR(a, b...) fprintf(stderr, a "\n", ## b)
> +#define PERROR(a, b...)
On 19.10.2017 11:15, Zhang Yi wrote:
> From: Zhang Yi Z
>
> Introduce the Xen Hypercall HVMOP_set_subpage into Xenctl.
> The API is defined as flowing.
>
> int xc_mem_set_subpage(xc_interface *handle, domid_t domid,
>xen_pfn_t gfn, uint32_t access);
>
> Signed-off-by: Zh
On 10/13/2017 07:26 PM, Tamas K Lengyel wrote:
> On Fri, Oct 13, 2017 at 9:50 AM, Jan Beulich wrote:
> On 13.10.17 at 14:50, wrote:
>>> This patch adds the old value param and the onchangeonly option
>>> to the VM_EVENT_REASON_MOV_TO_MSR event.
>>>
>>> The param was added to the vm_event_mov_
On 13.10.2017 13:29, Jan Beulich wrote:
+__set_bit(index + sizeof(struct monitor_msr_bitmap), bitmap);
I think you miss "* 8" here - a bit position plus sizeof() doesn't
produce any useful value.
But what's worse - having read till the end of the patch I don't
see you change any alloca
Hello,
Now that "x86/hvm: implement hvmemul_write() using real mappings" is in,
we can start working again on implementing hvmemul_cmpxchg() with a real
CMPXCHG, and finally fix the SMP emulation race upstream.
However, in order to do that we would need X86EMUL_CMPXCHG_FAILED which
has been
On 10/10/2017 05:24 PM, Jan Beulich wrote:
On 10.10.17 at 16:13, wrote:
>> On Ma, 2017-10-10 at 06:28 -0600, Jan Beulich wrote:> >
>
>>
>> a.u.set_mem_access_multi.pfn_list,
+ a.u.set_mem_access_multi.acc
ess_list,
+
On 09.10.2017 10:23, Jan Beulich wrote:
On 06.10.17 at 18:07, wrote:
On 10/06/2017 06:34 PM, Jan Beulich wrote:
On 05.10.17 at 17:42, wrote:
@@ -4451,6 +4453,7 @@ static int do_altp2m_op(
case HVMOP_altp2m_destroy_p2m:
case HVMOP_altp2m_switch_p2m:
case HVMOP_altp2m_set_mem
On 10/06/2017 06:34 PM, Jan Beulich wrote:
On 05.10.17 at 17:42, wrote:
>> @@ -4451,6 +4453,7 @@ static int do_altp2m_op(
>> case HVMOP_altp2m_destroy_p2m:
>> case HVMOP_altp2m_switch_p2m:
>> case HVMOP_altp2m_set_mem_access:
>> +case HVMOP_altp2m_set_mem_access_multi:
>
>
the callers are now switched to _mfn(domain_page_to_mfn(...)).
>
> Signed-off-by: Julien Grall
Acked-by: Razvan Cojocaru
Thanks,
Razvan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
fn_t by default.
>
> Only reasonable clean-ups are done in this patch because it is
> already quite big. So some of the files now override page_to_mfn and
> mfn_to_page to avoid using mfn_t.
>
> Signed-off-by: Julien Grall
Acked-by:
On 09/21/2017 03:40 PM, Julien Grall wrote:
> Signed-off-by: Julien Grall
>
> ---
>
> Cc: Razvan Cojocaru
> Cc: Tamas K Lengyel
> Cc: George Dunlap
> Cc: Jan Beulich
> Cc: Andrew Cooper
Acked-by: Razvan Cojocaru
Thanks,
Razvan
__
On 09/18/2017 06:35 PM, Jan Beulich wrote:
On 12.09.17 at 15:53, wrote:
>> --- a/xen/arch/x86/domctl.c
>> +++ b/xen/arch/x86/domctl.c
>> @@ -625,6 +625,26 @@ long arch_do_domctl(
>> !is_hvm_domain(d) )
>> break;
>>
>> +if ( domctl->u.hvmcontext_partial.typ
On 09/13/2017 09:27 PM, Julien Grall wrote:
> Hi Andrew,
>
> On 09/13/2017 07:22 PM, Andrew Cooper wrote:
>> On 13/09/2017 18:59, Julien Grall wrote:
>>> diff --git a/xen/arch/x86/mm/p2m-pt.c b/xen/arch/x86/mm/p2m-pt.c
>>> index 0e63d6ed11..57878b1886 100644
>>> --- a/xen/arch/x86/mm/p2m-pt.c
>>>
On 09/13/2017 08:59 PM, Julien Grall wrote:
> Signed-off-by: Julien Grall
>
> Cc: Jan Beulich
> Cc: Andrew Cooper
> Cc: Razvan Cojocaru
> Cc: Tamas K Lengyel
> Cc: George Dunlap
> Cc: Jun Nakajima
> Cc: Kevin Tian
> ---
> xen/arch/x86/hvm/hvm.c
e x86's paging_domctl() and descendants take a properly typed
> handle,
> - add const in a few places.
>
> Signed-off-by: Jan Beulich
Acked-by: Razvan Cojocaru
Thanks,
Razvan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 11.09.2017 14:16, Wei Liu wrote:
Signed-off-by: Wei Liu
---
Cc: Razvan Cojocaru
Cc: Tamas K Lengyel
Cc: Stefano Stabellini
Cc: Julien Grall
Cc: George Dunlap
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/arm/mem_access.c| 4 ++--
xen/arch/x86/mm/mem_access.c | 16
On 08.09.2017 16:44, Wei Liu wrote:
Signed-off-by: Wei Liu
---
Cc: Razvan Cojocaru
Cc: Tamas K Lengyel
---
xen/arch/arm/monitor.c| 4 ++--
xen/arch/x86/hvm/monitor.c| 10 +-
xen/common/monitor.c | 8
xen/include/asm-x86/hvm/monitor.h | 6
On 09/05/2017 11:57 AM, Sergej Proskurin wrote:
> In this commit we move the declaration of the function
> vm_event_toggle_singlestep from to and
> implement the associated functionality on ARM.
>
> Signed-off-by: Sergej Proskurin
Acked-by: Razvan Cojocaru
On 09/05/2017 11:57 AM, Sergej Proskurin wrote:
> In this commit, we extend the capabilities of the monitor to allow
> tracing of single-step events on ARM.
>
> Signed-off-by: Sergej Proskurin
Acked-by: Razvan Cojocaru
___
Xen-devel mail
On 01.09.2017 13:55, Andrew Cooper wrote:
On 01/09/17 11:44, Alexandru Isaila wrote:
diff --git a/xen/include/public/arch-x86/hvm/save.h
b/xen/include/public/arch-x86/hvm/save.h
index fd7bf3f..e6e8e87 100644
--- a/xen/include/public/arch-x86/hvm/save.h
+++ b/xen/include/public/arch-x86/hvm/save
On success, the guest will continue to run. Subsequent
> altp2m access violations will trap into Xen and be forced by xen-access
> to switch to the default view (altp2m[0]) as before. The introduced test
> can be invoked by providing the argument "altp2m_remap".
>
> Sign
On 08/30/2017 09:32 PM, Sergej Proskurin wrote:
> diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
> index 42e6f09029..66f1d83d84 100644
> --- a/xen/common/vm_event.c
> +++ b/xen/common/vm_event.c
> @@ -29,6 +29,7 @@
> #include
> #include
> #include
> +#include
Any reason why this
>
> Signed-off-by: Sergej Proskurin
Acked-by: Razvan Cojocaru
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 08/29/2017 08:41 PM, Wei Liu wrote:
-xfree(d->vm_event);
+#ifdef CONFIG_HAS_MEM_PAGING
+xfree(d->vm_event_paging);
+#endif
+xfree(d->vm_event_monitor);
>>> Why do you unconditionally xfree these vm_event_monitor while you don't
>>> unconditionally allocate th
On 08/16/2017 02:16 AM, Tamas K Lengyel wrote:
> On Tue, Aug 15, 2017 at 2:06 AM, Jan Beulich wrote:
> On 14.08.17 at 17:53, wrote:
>>> On Tue, Aug 8, 2017 at 2:27 AM, Alexandru Isaila
>>> wrote:
--- a/xen/arch/x86/hvm/hypercall.c
+++ b/xen/arch/x86/hvm/hypercall.c
@@ -155,6
On 08/05/2017 04:32 AM, Tamas K Lengyel wrote:
>
>
> On Fri, Aug 4, 2017 at 5:32 AM, Alexandru Isaila
> mailto:aisa...@bitdefender.com>> wrote:
>
> In some introspection usecases, an in-guest agent needs to communicate
> with the external introspection agent. An existing mechanism is
>
On 03/09/2017 06:56 PM, Jan Beulich wrote:
On 09.03.17 at 10:38, wrote:
>> @@ -4535,6 +4536,30 @@ static int do_altp2m_op(
>> a.u.set_mem_access.view);
>> break;
>>
>> +case HVMOP_altp2m_set_mem_access_multi:
>> +if ( a.u.set_mem_acc
On 01.08.2017 19:07, Tamas K Lengyel wrote:
On Tue, Aug 1, 2017 at 4:30 AM, Andrew Cooper wrote:
On 01/08/17 10:46, Alexandru Isaila wrote:
Allow guest userspace code to request that a vm_event be sent out
via VMCALL. This functionality seems to be handy for a number of
Xen developers, as st
On 07/25/2017 08:40 PM, Razvan Cojocaru wrote:
> On 07/18/2017 01:20 PM, Razvan Cojocaru wrote:
>> On 07/18/2017 01:09 PM, Andrew Cooper wrote:
>>> On 18/07/17 10:37, Petre Pircalabu wrote:
>>>> If case of a vm_event with the emulate_flags set, if the instructio
On 07/18/2017 01:20 PM, Razvan Cojocaru wrote:
> On 07/18/2017 01:09 PM, Andrew Cooper wrote:
>> On 18/07/17 10:37, Petre Pircalabu wrote:
>>> If case of a vm_event with the emulate_flags set, if the instruction
>>> cannot be emulated, the monitor should be n
On 07/22/2017 12:33 AM, Tamas K Lengyel wrote:
> Hey Razvan,
Hello,
> the vm_event that is being generated by doing
> VM_EVENT_FLAG_GET_NEXT_INTERRUPT sends almost all required information
> about the interrupt to the listener to allow it to get reinjected,
> except the instruction length. If the
On 07/20/2017 09:52 PM, Tamas K Lengyel wrote:
> On Thu, Jul 20, 2017 at 12:25 PM, Razvan Cojocaru
> wrote:
>> On 07/20/2017 07:46 PM, Tamas K Lengyel wrote:
>>> On Thu, Jul 20, 2017 at 10:43 AM, George Dunlap
>>> wrote:
>>>> On Wed, Jul 19, 201
On 07/20/2017 07:46 PM, Tamas K Lengyel wrote:
> On Thu, Jul 20, 2017 at 10:43 AM, George Dunlap
> wrote:
>> On Wed, Jul 19, 2017 at 7:24 PM, Tamas K Lengyel wrote:
I think the issue would be whether to allow a domain to set/clear the
suppress #VE bit for its pages by calling the new HV
On 07/18/2017 01:09 PM, Andrew Cooper wrote:
> On 18/07/17 10:37, Petre Pircalabu wrote:
>> If case of a vm_event with the emulate_flags set, if the instruction
>> cannot be emulated, the monitor should be notified instead of directly
>> injecting a hw exception.
>> This behavior can be used to re-
On 07/12/2017 08:21 PM, Petre Pircalabu wrote:
> If case of a vm_event with the emulate_flags set, if the instruction
> cannot be emulated, the monitor should be notified instead of directly
> injecting a hw exception.
> This behavior can be used to re-execute an instruction not supported by
> the
On 06/30/2017 08:45 PM, Andrew Cooper wrote:
> On 30/06/17 18:01, Wei Liu wrote:
>> Signed-off-by: Wei Liu
>
> This file falls under introspection maintainership, so CC'ing them (not
> that this change in controversial).
>
> Reviewed-by: Andrew Cooper
Acked-
On 06/27/2017 02:45 PM, Jan Beulich wrote:
>>>> Razvan Cojocaru 06/27/17 1:38 PM >>>
>> On 06/27/2017 02:26 PM, Jan Beulich wrote:
>>>>>> Razvan Cojocaru 06/27/17 10:32 AM >>>
>>>> On 06/27/2017 09:21 AM, Jan Beulich wrote:
&
On 06/27/2017 02:26 PM, Jan Beulich wrote:
>>>> Razvan Cojocaru 06/27/17 10:32 AM >>>
>> On 06/27/2017 09:21 AM, Jan Beulich wrote:
>>>>>> Andrew Cooper 06/26/17 5:11 PM >>>
>>>> There is also a difference in timing; vm_event_i
Hello,
> - Security > Alternative 2pm : Supported – I think we should split this
> out – it is currently implicitly covered under "Virtual Machine
> Introspection"
I agree that altp2m deserves its own space. While we're interested in
it, our current solution makes no use of it, so it's certainly
On 06/27/2017 09:21 AM, Jan Beulich wrote:
Andrew Cooper 06/26/17 5:11 PM >>>
>> There is also a difference in timing; vm_event_init_domain() is called
>> when vm_event is started on the domain, not when the domain is
>> constructed. IMO, the two should happen at the same time to be
>> consi
On 06/26/2017 03:14 PM, Andrew Cooper wrote:
> Razvan: I'd reword this to not mention livepatching. Simply having
> list_empty() working is a good enough reason alone.
Fair enough, I'll change the patch description as soon as we hear from
Tamas, so that I might address as many comments as possibl
On 06/26/2017 02:39 PM, Konrad Rzeszutek Wilk wrote:
> On June 26, 2017 5:48:17 AM EDT, Razvan Cojocaru
> wrote:
>> Pending livepatch code wants to check if the vm_event wait queues
>> are active, and this is made harder by the fact that they were
>
>
> Hmm, it wa
memory, in domain_create(), in
the newly added init_domain_vm_event() function.
Signed-off-by: Razvan Cojocaru
---
xen/common/domain.c| 5 ++---
xen/common/vm_event.c | 23 ---
xen/include/xen/vm_event.h | 2 ++
3 files changed, 24 insertions(+), 6 deletions
Fixed an issue where the maximum index allowed (31) goes beyond the
actual number of array elements (4) of ad->monitor.write_ctrlreg_mask.
Coverity-ID: 1412966
Signed-off-by: Razvan Cojocaru
Reviewed-by: Andrew Cooper
---
Changes since V2:
- Removed stale comment.
- Indentation.
- Ad
(Re-sent with CCs preserved).
On 06/21/2017 07:06 PM, Jan Beulich wrote:
On 21.06.17 at 16:56, wrote:
>> --- a/xen/arch/x86/monitor.c
>> +++ b/xen/arch/x86/monitor.c
>> @@ -133,7 +133,8 @@ int arch_monitor_domctl_event(struct domain *d,
>> bool_t old_status;
>>
>> /* sani
On 06/21/2017 07:06 PM, Jan Beulich wrote:
On 21.06.17 at 16:56, wrote:
>> --- a/xen/arch/x86/monitor.c
>> +++ b/xen/arch/x86/monitor.c
>> @@ -133,7 +133,8 @@ int arch_monitor_domctl_event(struct domain *d,
>> bool_t old_status;
>>
>> /* sanity check: avoid left-shift unde
On 06/21/2017 06:10 PM, Wei Liu wrote:
> On Wed, Jun 21, 2017 at 05:56:02PM +0300, Razvan Cojocaru wrote:
>> Fixed an issue where the maximum index allowed (31) goes beyond the
>> actual number of array elements (4) of ad->monitor.write_ctrlreg_mask.
>> Coverity-ID: 141
Fixed an issue where the maximum index allowed (31) goes beyond the
actual number of array elements (4) of ad->monitor.write_ctrlreg_mask.
Coverity-ID: 1412966
Signed-off-by: Razvan Cojocaru
---
Changes since V1:
- Changed '3' to 'ARRAY_SIZE(...)'.
---
xen/arch/x86/mo
On 06/21/2017 05:33 PM, Andrew Cooper wrote:
> On 21/06/17 15:28, Razvan Cojocaru wrote:
>> Fixed an issue where the maximum index allowed (31) goes beyond the
>> actual number of array elements (4) of ad->monitor.write_ctrlreg_mask.
>> Coverity-ID: 1412966
>>
>
Fixed an issue where the maximum index allowed (31) goes beyond the
actual number of array elements (4) of ad->monitor.write_ctrlreg_mask.
Coverity-ID: 1412966
Signed-off-by: Razvan Cojocaru
---
xen/arch/x86/monitor.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/a
On 06/21/2017 04:58 PM, Wei Liu wrote:
> On Mon, Jun 19, 2017 at 03:24:38PM +0300, Petre Pircalabu wrote:
>> Add support for filtering out the write_ctrlreg monitor events if they
>> are generated only by changing certains bits.
>> A new parameter (bitmask) was added to the xc_monitor_write_ctrlreg
On 06/16/2017 10:20 PM, Petre Pircalabu wrote:
> Add test for write_ctrlreg event handling.
>
> Signed-off-by: Petre Pircalabu
> ---
> tools/tests/xen-access/xen-access.c | 53
> -
> 1 file changed, 52 insertions(+), 1 deletion(-)
>
> diff --git a/tools/test
On 05/26/17 18:38, Jan Beulich wrote:
On 26.05.17 at 16:37, wrote:
>> On 05/26/17 17:29, Jan Beulich wrote:
>> On 25.05.17 at 11:40, wrote:
I've noticed that, with pages marked NX and vm_event emulation, we can
end up emulating an ud2, for which hvm_emulate_one() returns
X
On 05/29/17 15:11, Andrew Cooper wrote:
> On 29/05/2017 12:46, Razvan Cojocaru wrote:
>> On 05/29/17 14:05, Jan Beulich wrote:
>>>>>> On 29.05.17 at 11:20, wrote:
>>>> On 05/26/17 18:11, Andrew Cooper wrote:
>>>>> On 26/05/17 15:29, Jan
On 05/29/17 14:05, Jan Beulich wrote:
On 29.05.17 at 11:20, wrote:
>> On 05/26/17 18:11, Andrew Cooper wrote:
>>> On 26/05/17 15:29, Jan Beulich wrote:
>>> On 25.05.17 at 11:40, wrote:
> I've noticed that, with pages marked NX and vm_event emulation, we can
> end up emulating an
On 05/26/17 18:11, Andrew Cooper wrote:
> On 26/05/17 15:29, Jan Beulich wrote:
> On 25.05.17 at 11:40, wrote:
>>> I've noticed that, with pages marked NX and vm_event emulation, we can
>>> end up emulating an ud2, for which hvm_emulate_one() returns
>>> X86EMUL_EXCEPTION in hvm_emulate_one_vm
On 05/26/17 17:29, Jan Beulich wrote:
On 25.05.17 at 11:40, wrote:
>> I've noticed that, with pages marked NX and vm_event emulation, we can
>> end up emulating an ud2, for which hvm_emulate_one() returns
>> X86EMUL_EXCEPTION in hvm_emulate_one_vm_event().
>
> Could you explain what would le
Hello,
I've noticed that, with pages marked NX and vm_event emulation, we can
end up emulating an ud2, for which hvm_emulate_one() returns
X86EMUL_EXCEPTION in hvm_emulate_one_vm_event().
This, in turn, causes a hvm_inject_event() call in the context of
hvm_do_resume(), which can, if there's alre
On 05/08/17 15:44, Jan Beulich wrote:
On 04.05.17 at 11:00, wrote:
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -404,6 +404,7 @@ S: Supported
>> F: tools/tests/xen-access
>> F: xen/arch/*/monitor.c
>> F: xen/arch/*/vm_event.c
>> +F: xen/arch/*/hvm/vm_event.c
>> F: xen/arch/a
/hvm/vm_event.c and include/asm-x86/hvm/vm_event.h,
>>>>> where HVM-specific vm_event-related code will live. This cleans up
>>>>> hvm_do_resume() and ensures that the vm_event maintainers are
>>>>> responsible for changes to that code.
>>>>
tainers are
>> responsible for changes to that code.
>>
>> Signed-off-by: Razvan Cojocaru
>> Acked-by: Tamas K Lengyel
>
> Acked-by: Jan Beulich
> albeit I wonder ...
>
>> +void hvm_vm_event_do_resume(struct vcpu *v)
>> +{
>> +struct mon
This small series first creates hvm/vm_event.{h,c}, in order to bring
under vm_event maintainership the code that has previously lived in
hvm_do_resume(), and then fixes a __context_switch()-related race
condition when attempting to set registers via vm_event reply.
[PATCH V3 1/2] x86/vm_event: ad
Created arch/x86/hvm/vm_event.c and include/asm-x86/hvm/vm_event.h,
where HVM-specific vm_event-related code will live. This cleans up
hvm_do_resume() and ensures that the vm_event maintainers are
responsible for changes to that code.
Signed-off-by: Razvan Cojocaru
Acked-by: Tamas K Lengyel
used to control setting of CRs
and MSRs).
The patch additionally removes the sync_vcpu_execstate(v) call from
vm_event_resume(), which is no longer necessary, which removes the
associated broadcast TLB flush (read: performance improvement).
Signed-off-by: Razvan Cojocaru
Signed-off-by: Andrew Coo
On 05/03/2017 11:32 PM, Tamas K Lengyel wrote:
> On Wed, May 3, 2017 at 4:16 PM, Razvan Cojocaru
> wrote:
>> On 05/03/2017 11:05 PM, Tamas K Lengyel wrote:
>>>
>>>
>>> On Wed, May 3, 2017 at 6:48 AM, Jan Beulich >> <mailto:jbeul...@suse.c
Beulich wrote:
> >>>>> On 03.05.17 at 11:10, <mailto:rcojoc...@bitdefender.com>> wrote:
> >>> --- /dev/null
> >>> +++ b/xen/arch/x86/hvm/vm_event.c
> >>> @@ -0,0 +1,101 @@
> >>> +/*
> >>> + * a
de=]
> (XEN) Faulting linear address: 830492cbb447
> (XEN)
>
> At the same time pave the way for having zero-length records.
>
> Inspired by an earlier patch from Andrew and Razvan.
>
> Reported-by: Razvan Cojocaru
> Dia
On 05/03/17 12:30, Jan Beulich wrote:
On 03.05.17 at 11:21, wrote:
>> At 10:15 +0100 on 03 May (1493806508), Tim Deegan wrote:
>>> At 00:31 -0600 on 03 May (1493771502), Jan Beulich wrote:
+else if ( ctxt.cur > sizeof(*desc) )
{
uint32_t off;
-con
On 05/03/17 13:01, Jan Beulich wrote:
On 03.05.17 at 11:10, wrote:
>> The introspection agent can reply to a vm_event faster than
>> vmx_vmexit_handler() can complete in some cases, where it is then
>> not safe for vm_event_set_registers() to modify v->arch.user_regs.
>> In the test scenario,
-hvm_inject_hw_exception(TRAP_gp_fault, 0);
>> -
>> - w->do_write.cr3 = 0;
>> -}
>> -}
>> +hvm_vm_event_do_resume(v);
>
> As indicated before, I think we want to keep
>
> if ( unlikely(v->arch.vm_eve
On 05/03/17 12:15, Tim Deegan wrote:
> At 00:31 -0600 on 03 May (1493771502), Jan Beulich wrote:
>> Hmm, with both of you being of that opinion, I've taken another
>> look. I think I see now why you think that way (this being data
>> from an internal producer, overflow/underflow are not a primary
>
dditionally removes the sync_vcpu_execstate(v) call from
vm_event_resume(), which is no longer necessary, which removes the
associated broadcast TLB flush (read: performance improvement).
Signed-off-by: Razvan Cojocaru
Signed-off-by: Andrew Cooper
---
xen/arch/x86/hvm/vm_even
Created arch/x86/hvm/vm_event.c and include/asm-x86/hvm/vm_event.h,
where HVM-specific vm_event-related code will live. This cleans up
hvm_do_resume() and ensures that the vm_event maintainers are
responsible for changes to that code.
Signed-off-by: Razvan Cojocaru
---
MAINTAINERS
This small series first creates hvm/vm_event.{h,c}, in order to bring
under vm_event maintainership the code that has previously lived in
hvm_do_resume(), and then fixes a __context_switch()-related race
condition when attempting to set registers via vm_event reply.
Previously this has been a sing
On 05/02/2017 07:11 PM, Andrew Cooper wrote:
> On 02/05/17 17:02, Tim Deegan wrote:
>> At 18:21 +0300 on 02 May (1493749307), Razvan Cojocaru wrote:
>>> hvm_save_cpu_ctxt() returns success without writing any data into
>>> hvm_domain_context_t when all VCPUs are o
(XEN)
>> (XEN) Pagetable walk from 830492cbb447:
>> (XEN) L4[0x106] = dbc36063
>> (XEN) L3[0x012] =
>> (XEN)
>> (XEN)
>> (XEN) Panic on CPU 5:
>> (XEN) FATAL PAGE FAULT
>> (XEN) [error_
ff830492cbb447
(XEN)
Reported-by: Razvan Cojocaru
Signed-off-by: Andrew Cooper
Signed-off-by: Razvan Cojocaru
Tested-by: Razvan Cojocaru
---
Changes since V1:
- Corrected patch description.
- Now checking whether the function got back any data at all, prior to
On 05/02/17 17:09, Jan Beulich wrote:
On 02.05.17 at 15:54, wrote:
>> On 05/02/17 16:48, Jan Beulich wrote:
>> On 02.05.17 at 15:25, wrote:
--- a/xen/common/hvm/save.c
+++ b/xen/common/hvm/save.c
@@ -113,7 +113,7 @@ int hvm_save_one(struct domain *d, uint16_t typecode,
>>
On 05/02/17 16:48, Jan Beulich wrote:
On 02.05.17 at 15:25, wrote:
>> hvm_save_cpu_ctxt() does a memset(&ctxt, 0, sizeof(ctxt)), which
>> can lead to ctxt.cur being 0. This can then crash the hypervisor
>> (with FATAL PAGE FAULT) in hvm_save_one() via the
>> "off < (ctxt.cur - sizeof(*desc))"
On 05/02/17 16:41, Tim Deegan wrote:
> Hi,
>
> At 16:25 +0300 on 02 May (1493742339), Razvan Cojocaru wrote:
>> hvm_save_cpu_ctxt() does a memset(&ctxt, 0, sizeof(ctxt)), which
>> can lead to ctxt.cur being 0. This can then crash the hypervisor
>> (with FATAL PAGE F
c on CPU 5:
(XEN) FATAL PAGE FAULT
(XEN) [error_code=]
(XEN) Faulting linear address: 830492cbb447
(XEN) ****
Reported-by: Razvan Cojocaru
Signed-off-by: Andrew Cooper
Signed-off-by: Razvan Cojocaru
Tested-by: Razvan Cojocaru
---
xen/common/hvm/save.c |
n might fail, as gva_to_ipa uses the
> guest's translation tables, access to which might be restricted by the
> active VTTBR. To address this issue, we perform the gva to ipa
> translation in software.
>
> Signed-off-by: Sergej Proskurin
> ---
> Cc: Razvan Cojocaru
On 04/28/2017 09:25 AM, Jan Beulich wrote:
On 27.04.17 at 19:31, wrote:
>> On 27/04/17 09:52, Jan Beulich wrote:
>> On 27.04.17 at 10:34, wrote:
On 27/04/2017 09:01, Jan Beulich wrote:
On 27.04.17 at 09:22, wrote:
>> --- a/xen/common/vm_event.c
>> +++ b/xen/common/
On 04/27/17 12:00, Jan Beulich wrote:
On 27.04.17 at 10:34, wrote:
>> On 04/27/17 11:18, Jan Beulich wrote:
>> On 27.04.17 at 10:11, wrote:
On 04/27/17 11:01, Jan Beulich wrote:
On 27.04.17 at 09:22, wrote:
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/
On 04/27/17 11:18, Jan Beulich wrote:
On 27.04.17 at 10:11, wrote:
>> On 04/27/17 11:01, Jan Beulich wrote:
>> On 27.04.17 at 09:22, wrote:
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -473,6 +473,39 @@ static bool hvm_get_pending_event(struct vcpu *v,
>>>
On 04/27/17 11:01, Jan Beulich wrote:
On 27.04.17 at 09:22, wrote:
>> The introspection agent can reply to a vm_event faster than
>> vmx_vmexit_handler() can complete in some cases, where it is then
>> not safe for vm_event_set_registers() to modify v->arch.user_regs.
>
> This needs more exp
ent).
Signed-off-by: Razvan Cojocaru
Signed-off-by: Andrew Cooper
---
xen/arch/x86/hvm/hvm.c | 35 +++
xen/arch/x86/vm_event.c| 22 ++
xen/common/vm_event.c | 14 +++---
xen/include/asm-x86/vm_event.h | 2 ++
4 fi
On 04/18/2017 01:32 PM, Jan Beulich wrote:
> This is an optional feature and hence we should check for it before
> use.
>
> Signed-off-by: Jan Beulich
> ---
> v2: Re-do detection of availability, resulting in almost all of the
> changes done here being different than in
695399/functions/signal.html
>>
>> This removes the warning:
>> #warning redirecting incorrect #include to
>> when building with the musl C-library.
>>
>> Signed-off-by: Alistair Francis
>
> Acked-by: Wei Liu
FWIW:
Acked-by: Razvan Cojocaru
Thank
1 - 100 of 849 matches
Mail list logo
