result a preemption check is being added.
>
> Also drop unused parameters from the function.
>
> Signed-off-by: Jan Beulich
Thank you for the patch!
FWIW, Reviewed-by: Razvan Cojocaru
Thanks,
Razvan
___
Xen-devel mailing list
Xen-dev
> On Fri, Oct 13, 2017 at 03:50:57PM +0300, Alexandru Isaila 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_to_msr struct and to the
>> hvm_monitor_msr function. Finally I've changed
On 12/07/2017 04:16 PM, Jan Beulich wrote:
> ..., at least as far as currently possible, i.e. when a mapping can be
> obtained.
>
> Signed-off-by: Jan Beulich
Thank you for the patch!
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://l
On 12/08/2017 02:18 PM, Jan Beulich wrote:
On 24.10.17 at 12:19, wrote:
>> 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, where domains are
On 12/11/2017 03:36 PM, Jan Beulich wrote:
On 11.12.17 at 13:50, wrote:
>> On 12/11/2017 12:12 PM, Jan Beulich wrote:
>> On 11.12.17 at 12:06, wrote:
My suggestion was that we don't break usecases. The Intel usecase
specifically is for an in-guest entity to have full control o
On 12/11/2017 05:54 PM, George Dunlap wrote:
> On 12/11/2017 03:05 PM, Jan Beulich wrote:
>>>>> On 11.12.17 at 15:51, wrote:
>>> On 12/11/2017 02:46 PM, Razvan Cojocaru wrote:
>>>> On 12/11/2017 03:36 PM, Jan Beulich wrote:
>>>>>>>> O
On 12/11/2017 06:00 PM, Tamas K Lengyel wrote:
>>> I think Jan was saying that he would ideally like to remove *all* guest
>>> access to altp2m functionality, even what's currently there. The more
>>> extra features we make available to guests, the harder it will be in the
>>> future to argue to r
uint16_t kind)
>>
>> Why did you choose to have "ept" in the name and also mention it
>> in the commit? Is there anything in here which isn't generic p2m?
>
> The name was suggested by Razvan Cojocaru. I have no preference in th
On 9/11/19 2:41 PM, Jan Beulich wrote:
> On 11.09.2019 13:21, Razvan Cojocaru wrote:
>> On 9/11/19 1:39 PM, Alexandru Stefan ISAILA wrote:
>>>
>>>
>>> On 11.09.2019 12:57, Jan Beulich wrote:
>>>> On 09.09.2019 17:35, Alexandru Stefan ISAILA wrote:
On 9/17/19 5:11 PM, Alexandru Stefan ISAILA wrote:
> +bool hvm_monitor_check_p2m(unsigned long gla, gfn_t gfn, uint32_t pfec,
> + uint16_t kind)
> +{
> +xenmem_access_t access;
> +vm_event_request_t req = {};
> +paddr_t gpa = (gfn_to_gad
On 9/17/19 6:09 PM, Tamas K Lengyel wrote:
> On Tue, Sep 17, 2019 at 8:24 AM Razvan Cojocaru
> wrote:
>>
>> On 9/17/19 5:11 PM, Alexandru Stefan ISAILA wrote:
>>>>>>> +bool hvm_monitor_check_p2m(unsigned long gla, gfn_t gfn, uint32_t pfec,
>>&g
d-off-by: Jan Beulich
>
> Reviewed-by: Boris Ostrovsky
Acked-by: Razvan Cojocaru
Thanks,
Razvan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
laces that consume HVMTRANS* return X86EMUL_RETRY.
>
> hvm_emulate_send_vm_event() can return false if there was no violation,
> if there was an error from monitor_traps() or p2m_get_mem_access().
> -ESRCH from p2m_get_mem_access() is treated as restricted access.
>
> NOTE: hvm_emulate
On 5/1/19 6:01 PM, Tamas K Lengyel wrote:
> On Wed, May 1, 2019 at 8:53 AM Tamas K Lengyel wrote:
>>
>> On Wed, May 1, 2019 at 8:20 AM Razvan Cojocaru
>> wrote:
>>>
>>> On 5/1/19 4:58 PM, Tamas K Lengyel wrote:
>>>>>> It might be wor
e the event
> was recorded. This prevents vm_event subscribers from correctly finding kernel
> structures in the guest when it is trapped while in ring3.
>
> Refresh shadow_gs value when the context being saved is for the current vCPU.
>
> Signed-off-by: Tamas K Lengyel
> Cc: Raz
On 5/2/19 2:57 AM, Tamas K Lengyel wrote:
Receiving this register is useful for introspecting 32-bit Windows when the
event being trapped happened while in ring3.
Signed-off-by: Tamas K Lengyel
Cc: Razvan Cojocaru
Cc: Tamas K Lengyel
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: Roger
On 5/2/19 11:36 AM, Jan Beulich wrote:
On 02.05.19 at 08:20, wrote:
On 5/2/19 2:52 AM, Tamas K Lengyel wrote:
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -779,12 +779,17 @@ static void vmx_load_cpu_state(struct vcpu *v, struct
hvm_hw_cpu *data)
static void vmx_sa
On 5/2/19 11:45 AM, Andrew Cooper wrote:
On 02/05/2019 07:20, Razvan Cojocaru wrote:
On 5/2/19 2:52 AM, Tamas K Lengyel wrote:
Currently the gs_shadow value is only cached when the vCPU is being scheduled
out by Xen. Reporting this (usually) stale value through vm_event is incorrect,
since it
On 5/2/19 11:52 AM, Andrew Cooper wrote:
On 02/05/2019 09:25, Razvan Cojocaru wrote:
On 5/2/19 2:57 AM, Tamas K Lengyel wrote:
Receiving this register is useful for introspecting 32-bit Windows
when the
event being trapped happened while in ring3.
Signed-off-by: Tamas K Lengyel
Cc: Razvan
.
Signed-off-by: Tamas K Lengyel
Cc: Razvan Cojocaru
Cc: Tamas K Lengyel
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: Roger Pau Monne
---
xen/arch/x86/vm_event.c | 5 +
xen/include/public/vm_event.h | 3 ++-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/xen
On 5/3/19 12:42 AM, Tamas K Lengyel wrote:
> Receiving this register is useful for introspecting 32-bit Windows when the
> event being trapped happened while in ring3.
>
> Signed-off-by: Tamas K Lengyel
> Cc: Razvan Cojocaru
> Cc: Tamas K Lengyel
> Cc: Jan Beulich
>
On 5/3/19 11:09 AM, Jan Beulich wrote:
On 03.05.19 at 00:54, wrote:
Receiving this register is useful for introspecting 32-bit Windows when the
event being trapped happened while in ring3.
Signed-off-by: Tamas K Lengyel
Cc: Razvan Cojocaru
Cc: Tamas K Lengyel
Cc: Jan Beulich
Cc: Andrew
On 5/9/19 11:57 PM, Mathieu Tarral wrote:
> Hi,
>
> following a previous conversation, i would like to catch MOV-TO-DRx VMI
> events to prevent the guest from disabling my hardware breakpoints.
>
> @Tamas pointed me to this header:
> https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include
On 5/10/19 12:31 AM, Andrew Cooper wrote:
> What we'll have to do is end up in a position where we can have some
> real %dr settings given by the VMI agent, and some shadow %dr settings
> which the guest interacts with. Also I should warn you at this point
> that, because of how the registers work
On 5/10/19 2:03 AM, Tamas K Lengyel wrote:
>> Either way, everything comes down to what behaviour is wanted to start with.
> As I said, I think adding that monitoring capability is fine as long
> as its limitation is clearly documented.
Right. My thoughts as well.
Thanks,
Razvan
___
On 5/10/19 5:42 PM, Tamas K Lengyel wrote:
On Thu, May 9, 2019 at 10:19 AM Andrew Cooper wrote:
On 09/05/2019 14:38, Tamas K Lengyel wrote:
Hi all,
I'm investigating an issue with altp2m that can easily be reproduced
and leads to a hypervisor deadlock when PML is available in hardware.
I have
On 11/27/18 12:49 PM, Razvan Cojocaru wrote:
With a sufficiently complete insn emulator, single-stepping should
not be needed at all imo. Granted we're not quite there yet with
the emulator, but we've made quite a bit of progress. As before,
if there are particular instructions you kn
On 5/13/19 5:06 PM, Jan Beulich wrote:
On 13.05.19 at 15:58, wrote:
On 11/27/18 12:49 PM, Razvan Cojocaru wrote:
With a sufficiently complete insn emulator, single-stepping should
not be needed at all imo. Granted we're not quite there yet with
the emulator, but we've made quit
On 5/13/19 7:18 PM, Mathieu Tarral wrote:
> Le vendredi, mai 10, 2019 5:21 PM, Andrew Cooper
> a écrit :
>
>> On 10/05/2019 16:17, Mathieu Tarral wrote:
>>
>>> Le jeudi, mai 9, 2019 6:42 PM, Andrew Cooper andrew.coop...@citrix.com a
>>> écrit :
>>>
Therefore, the conclusion to draw is that
On 5/13/19 5:15 PM, Razvan Cojocaru wrote:
On 5/13/19 5:06 PM, Jan Beulich wrote:
On 13.05.19 at 15:58, wrote:
On 11/27/18 12:49 PM, Razvan Cojocaru wrote:
With a sufficiently complete insn emulator, single-stepping should
not be needed at all imo. Granted we're not quite there yet wit
On 5/14/19 5:16 PM, Jan Beulich wrote:
On 14.05.19 at 15:47, wrote:
Mem event emulation failed (5): d5v0 32bit @ 001b:6d96efff -> c5 f9 f5
05 c0 be ad 6d c5 e1 fe 1d a0 20 af 6d
Looking at the source code, the emulator does appear to support
vpmaddwd, however only for EVEX:
http://xenbits.x
All its callers live inside #ifdef CONFIG_HVM sections.
Signed-off-by: Razvan Cojocaru
---
xen/arch/x86/mm/p2m.c | 72 +++
xen/include/asm-x86/p2m.h | 2 ++
2 files changed, 38 insertions(+), 36 deletions(-)
diff --git a/xen/arch/x86/mm/p2m.c b
On 5/14/19 6:42 PM, Jan Beulich wrote:
On 23.04.19 at 16:30, wrote:
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -478,6 +478,43 @@ void p2m_unlock_and_tlb_flush(struct p2m_domain *p2m)
mm_write_unlock(&p2m->lock);
}
+int altp2m_get_effective_entry(struct p2m_domain
part if vm_event_check_ring() returns
false, we should probably return -EOPNOTSUPP from there as well. In
fact, I wonder if any of the -ENOSYS returns in vm_event.c should not be
replaced with return -EOPNOTSUPPs.
Anyway, the change does clearly improve the code even without settling
the
llers.
>
> Signed-off-by: Juergen Gross
> ---
> V2: add blank line (Jan Beulich)
> replace two further ENOSYS returns with EOPNOTSUPP (Razvan Cojocaru)
Acked-by: Razvan Cojocaru
Thanks,
Razvan
___
Xen-devel mailing l
t the begining of do_domctl().
No functional change.
Signed-off-by: Andrew Cooper
Acked-by: Razvan Cojocaru
Thanks,
Razvan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
vm_event_grab_slot(), fold the exit
paths to have a single unlock, as the compiler can't make this
optimisation itself.
No functional change.
Signed-off-by: Andrew Cooper
Acked-by: Razvan Cojocaru
Thanks,
Razvan
___
Xen-devel mailing list
Xen-
change.
Signed-off-by: Andrew Cooper
---
CC: Razvan Cojocaru
CC: Tamas K Lengyel
CC: Petre Pircalabu
---
xen/common/vm_event.c | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
index 72f42b4..e872680 100644
ensible.
Check for repeated enables and an bad HVM_PARAM before allocating
memory, and gather the trivial setup into one place, dropping the
redundant zeroing.
No practical change that callers will notice.
Signed-off-by: Andrew Cooper
Acked-by: Razvan Cojocaru
ete this interface, the safest course of action is to leave it
alone, rather than to end up making things subtly different.
Therefore, no practical change that callers would notice.
Signed-off-by: Andrew Cooper
Acked-by: Razvan Cojocaru
Thanks,
Razvan
__
eed, I've also seem to have missed CC-ing Razvan (fixed now).
Acked-by: Razvan Cojocaru
Thanks,
Razvan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Remove myself as vm_event maintaner, add Alexandru and Petre as
Bitdefender vm_event maintainers.
Signed-off-by: Razvan Cojocaru
---
MAINTAINERS | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 6fbdc2b..d60e3a5 100644
--- a/MAINTAINERS
+++ b
On 6/12/19 7:02 PM, Razvan Cojocaru wrote:
Remove myself as vm_event maintaner, add Alexandru and Petre as
Bitdefender vm_event maintainers.
Signed-off-by: Razvan Cojocaru
---
MAINTAINERS | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index
On 1/2/19 1:50 PM, Wei Liu wrote:
> On Tue, Dec 18, 2018 at 05:11:44PM +0200, Razvan Cojocaru wrote:
>> Allow altp2m users to disable #VE/VMFUNC alone. Currently it is
>> only possible to disable this functionality when we disable altp2m
>> completely; #VE/VMFUNC can onl
On 1/2/19 2:29 PM, Andrew Cooper wrote:
> On 02/01/2019 11:50, Wei Liu wrote:
>> On Tue, Dec 18, 2018 at 05:11:44PM +0200, Razvan Cojocaru wrote:
>>> Allow altp2m users to disable #VE/VMFUNC alone. Currently it is
>>> only possible to disable this functiona
Replace all the TABs with spaces.
Signed-off-by: Razvan Cojocaru
---
tools/libxc/xc_altp2m.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/tools/libxc/xc_altp2m.c b/tools/libxc/xc_altp2m.c
index e61bacf..a86520c 100644
--- a/tools/libxc/xc_altp2m.c
+++ b
t; pass
>
> version targeted for testing:
> xen 9b97818c3d5854caa95d8af20fe7ef6112ff1b06
> baseline version:
> xen 7b6e05c50fc39466fcc685fb6d4216f99af58743
>
> Last test of basis 131670 2019-01-01 08:51:55 Z2 days
> Testing same sin
On 1/7/19 4:26 PM, Tamas K Lengyel wrote:
Fix VGA logdirty with altp2m (v11) Razvan Cojocaru?
This has been merged already.
Indeed, sorry for only seeing this now - I've had a small technical
SNAFU I had to take care of today and missed some emails.
Thanks,
R
On 1/8/19 6:27 PM, Jan Beulich wrote:
On 19.12.18 at 19:52, wrote:
Signed-off-by: Petre Pircalabu
An empty description is not helpful. The immediate question is: Why?
We don't do this for other interface versions. I'm unconvinced a
special purpose piece of information like this one belongs i
On 1/8/19 6:47 PM, Jan Beulich wrote:
On 08.01.19 at 17:37, wrote:
On 1/8/19 6:27 PM, Jan Beulich wrote:
On 19.12.18 at 19:52, wrote:
Signed-off-by: Petre Pircalabu
An empty description is not helpful. The immediate question is: Why?
We don't do this for other interface versions. I'm un
finish_type_change() returns a negative int on error, but the
current code checks if ( !rc ). Also properly indent the out:
label while at it.
Signed-off-by: Razvan Cojocaru
---
xen/arch/x86/mm/p2m.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/mm/p2m.c
eakage was introduced by commit 0fb4b58c8b
("x86/altp2m: fix display frozen when switching to a new view
early").
Properly indent the out: label while at it.
Signed-off-by: Razvan Cojocaru
---
Changes since V1:
- Updated description.
- Now treating finish_type_change()'s return
On 12/20/18 4:28 PM, Paul Durrant wrote:
-Original Message-
From: Petre Ovidiu PIRCALABU [mailto:ppircal...@bitdefender.com]
Sent: 20 December 2018 14:26
To: Paul Durrant ; xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ; Wei Liu
; Razvan Cojocaru ; Konrad
Rzeszutek Wilk ; George
On 1/9/19 6:15 PM, Tamas K Lengyel wrote:
On Mon, Jan 7, 2019 at 2:01 AM Roger Pau Monné wrote:
Adding the introspection guys.
On Fri, Jan 04, 2019 at 08:47:04AM -0700, Jan Beulich wrote:
On 04.01.19 at 16:35, wrote:
On Fri, Jan 04, 2019 at 06:22:19AM -0700, Jan Beulich wrote:
On 04.01.19
On 1/9/19 6:34 PM, Roger Pau Monné wrote:
Maybe this is use-case is different, but how does introspection handle
accesses to the shared info page or the runstate info for example?
I would consider argo to be the same in this regard.
Not exactly: The shared info page is special in any event. Fo
On 1/9/19 6:50 PM, Tamas K Lengyel wrote:
On Wed, Jan 9, 2019 at 9:48 AM Razvan Cojocaru
wrote:
On 1/9/19 6:34 PM, Roger Pau Monné wrote:
Maybe this is use-case is different, but how does introspection handle
accesses to the shared info page or the runstate info for example?
I would
On 1/10/19 11:58 AM, Paul Durrant wrote:
-Original Message-
Why re-invent the wheel here? The ioreq infrastructure already does
pretty much everything you need AFAICT.
Paul
I wanted preseve as much as possible from the existing vm_event DOMCTL
interface and add only the necessa
On 12/25/18 4:29 AM, Tian, Kevin wrote:
From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com]
Sent: Friday, December 14, 2018 7:50 PM
Block interrupts (in vmx_intr_assist()) for the duration of
processing a sync vm_event (similarly to the strategy
currently used for single-stepping
On 1/11/19 6:38 PM, Tamas K Lengyel wrote:
On Fri, Jan 11, 2019 at 8:37 AM Alexandru Stefan ISAILA
wrote:
This patch aims to have mem access vm events sent from the emulator.
This is useful in the case of page-walks that have to emulate
instructions in access denied pages.
I'm a little conf
On 1/11/19 10:51 PM, Tamas K Lengyel wrote:
> On Fri, Jan 11, 2019 at 9:51 AM Razvan Cojocaru
> wrote:
>>
>> On 1/11/19 6:38 PM, Tamas K Lengyel wrote:
>>> On Fri, Jan 11, 2019 at 8:37 AM Alexandru Stefan ISAILA
>>> wrote:
>>>>
>>>>
On 1/12/19 12:04 AM, Boris Ostrovsky wrote:
On 12/14/18 6:49 AM, Razvan Cojocaru wrote:
Block interrupts (in vmx_intr_assist()) for the duration of
processing a sync vm_event (similarly to the strategy
currently used for single-stepping). Otherwise, attempting
to emulate an instruction when
On 1/14/19 11:53 AM, Jan Beulich wrote:
On 14.01.19 at 10:34, wrote:
On 1/12/19 12:04 AM, Boris Ostrovsky wrote:
On 12/14/18 6:49 AM, Razvan Cojocaru wrote:
Block interrupts (in vmx_intr_assist()) for the duration of
processing a sync vm_event (similarly to the strategy
currently used for
On 1/14/19 4:42 PM, Juergen Gross wrote:
On 14/01/2019 11:56, Razvan Cojocaru wrote:
On 1/14/19 11:53 AM, Jan Beulich wrote:
On 14.01.19 at 10:34, wrote:
On 1/12/19 12:04 AM, Boris Ostrovsky wrote:
On 12/14/18 6:49 AM, Razvan Cojocaru wrote:
Block interrupts (in vmx_intr_assist()) for the
On 1/14/19 4:42 PM, Juergen Gross wrote:
> On 14/01/2019 11:56, Razvan Cojocaru wrote:
>> On 1/14/19 11:53 AM, Jan Beulich wrote:
>>>>>> On 14.01.19 at 10:34, wrote:
>>>> On 1/12/19 12:04 AM, Boris Ostrovsky wrote:
>>>>> On 12/14/18 6:49
On 1/16/19 10:58 AM, Jan Beulich wrote:
On 16.01.19 at 08:10, wrote:
On 1/14/19 4:42 PM, Juergen Gross wrote:
On 14/01/2019 11:56, Razvan Cojocaru wrote:
On 1/14/19 11:53 AM, Jan Beulich wrote:
On 14.01.19 at 10:34, wrote:
On 1/12/19 12:04 AM, Boris Ostrovsky wrote:
On 12/14/18 6:49 AM
OPNOTSUPP part of this
> condition is also wrong.
>
> Drop the !sve check entirely.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Razvan Cojocaru
> CC: Tamas K Lengyel
> CC: Jun Nakajima
> CC: Kevin Tian
> CC: Jan Beulich
> CC: Wei Liu
> CC: Rog
anit
CC: Brian Woods
CC: Juergen Gross
CC: Razvan Cojocaru
CC: Tamas K Lengyel
This wants backporting to Xen 4.11
---
xen/arch/x86/hvm/svm/svm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 2584b90..e21091c 100644
--- a/x
On 2/4/19 1:55 PM, Paul Durrant wrote:
-Original Message-
From: Alexandru Stefan ISAILA [mailto:aisa...@bitdefender.com]
Sent: 04 February 2019 11:37
To: xen-devel@lists.xenproject.org
Cc: Paul Durrant ; jbeul...@suse.com; Andrew
Cooper ; Wei Liu ; Roger
Pau Monne ; rcojoc...@bitdefender.
On 2/4/19 5:14 PM, Roger Pau Monné wrote:
On Mon, Feb 04, 2019 at 02:00:40PM +0200, Razvan Cojocaru wrote:
On 2/4/19 1:55 PM, Paul Durrant wrote:
-Original Message-
From: Alexandru Stefan ISAILA [mailto:aisa...@bitdefender.com]
Sent: 04 February 2019 11:37
To: xen-devel
since the
> per-domain IOMMU flag enable flag is currently set to the value
> of the global iommu_enable flag. A subsequent patch will add an
> option to the toolstack to allow it to be turned off if there is
> no intention to assign passthrough hardware to th
is
patch fixes the "external" case.
Signed-off-by: Razvan Cojocaru
---
xen/arch/x86/hvm/hvm.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 21944e9..33038dc 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/
On 2/8/19 12:51 PM, Jan Beulich wrote:
On 08.02.19 at 10:56, wrote:
HVMOP_altp2m_set_domain_state does not domain_pause(), presumably
on purpose (as it was originally supposed to cater to a in-guest
agent, and a domain pausing itself is not a good idea).
This can lead to domain crashes in the
On 2/8/19 1:13 PM, Razvan Cojocaru wrote:
On 2/8/19 12:51 PM, Jan Beulich wrote:
On 08.02.19 at 10:56, wrote:
HVMOP_altp2m_set_domain_state does not domain_pause(), presumably
on purpose (as it was originally supposed to cater to a in-guest
agent, and a domain pausing itself is not a good
On 2/8/19 2:58 PM, Jan Beulich wrote:
Well, to be honest I expected dependencies like this to be there,
and hence I didn't expect it would be a straightforward change.
Just like we do e.g. for the IOMMU enabling, I guess the boolean
wants to become a tristate then (off -> enabling -> enabled),
wh
bool_t's to bool's.
Signed-off-by: Razvan Cojocaru
---
xen/arch/x86/hvm/hvm.c| 17 ++---
xen/arch/x86/hvm/vmx/vmx.c| 4 ++--
xen/arch/x86/mm/altp2m.c | 4 ++--
xen/arch/x86/mm/p2m.c | 4 ++--
xen/include/asm-x86/altp2m.h | 2 +-
xen/include/asm-x8
On 2/8/19 4:00 PM, Razvan Cojocaru wrote:
HVMOP_altp2m_set_domain_state does not domain_pause(), presumably
on purpose (as it was originally supposed to cater to a in-guest
agent, and a domain pausing itself is not a good idea).
This can lead to domain crashes in the vmx_vmexit_handler() code
On 2/8/19 5:50 PM, Jan Beulich wrote:
On 08.02.19 at 15:00, wrote:
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -4525,7 +4525,7 @@ static int do_altp2m_op(
>> case HVMOP_altp2m_set_domain_state:
>> {
>> struct vcpu *v;
>> -bool_t ostate;
>>
On 2/8/19 6:44 PM, Jan Beulich wrote:
On 08.02.19 at 17:30, wrote:
>> On 2/8/19 5:50 PM, Jan Beulich wrote:
>> On 08.02.19 at 15:00, wrote:
/* If the alternate p2m state has changed, handle appropriately */
-if ( d->arch.altp2m_active != ostate &&
+
Right, I now understand what you meant by removing "if ( ostate )" -
you'd like d->arch.altp2m_active to only be set _after_ the for, for the
enable, as well as for the disable case.
No, certainly not. Exactly because of ...
However, I wanted to keep both if()s to avoid another problem with
_active(), to
prevent it from returning a "valid" altp2m pointer between
the moment where d->arch.altp2m_active = false and the
point when v->p2midx actually becomes INVALID_ALTP2M.
While at it, I've changed a couple of bool_t's to bool's.
Signed-off-by: Razvan
On 2/11/19 12:10 PM, Jan Beulich wrote:
On 11.02.19 at 10:13, wrote:
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2150,13 +2150,13 @@ static bool_t vmx_is_singlestep_supported(void)
return !!cpu_has_monitor_trap_flag;
}
-static void vmx_vcpu_update_eptp(struc
On 2/11/19 12:57 PM, Razvan Cojocaru wrote:
On 2/11/19 12:10 PM, Jan Beulich wrote:
On 11.02.19 at 10:13, wrote:
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2150,13 +2150,13 @@ static bool_t vmx_is_singlestep_supported(void)
return !!cpu_has_monitor_trap_flag
On 2/11/19 6:59 PM, Jan Beulich wrote:
>>> Thanks for noticing, actually this appears to invalidate the whole
>>> purpose of the patch (I should have tested this more before sumbitting
>>> V3, sorry).
>>>
>>> The whole point of the new boolean is to have p2m assigned an altp2m
>>> regardless of
On 2/12/19 9:31 AM, Jan Beulich wrote:
On 11.02.19 at 18:21, wrote:
On 2/11/19 6:59 PM, Jan Beulich wrote:
Thanks for noticing, actually this appears to invalidate the whole
purpose of the patch (I should have tested this more before sumbitting
V3, sorry).
The whole point of the new boolean i
On 2/11/19 6:59 PM, Jan Beulich wrote:
Plus I can't see p2m_switch_vcpu_altp2m_by_id() called for
any HVMOP_altp2m_* at all. One of the actual callers is guarded
by altp2m_active(), but the other isn't.
Actually I see that both places are guarded by altp2m_active().
In p2m.c we have:
2312 voi
bool_t's to bool's.
Signed-off-by: Razvan Cojocaru
---
Changes since V3:
- Reverted p2m_get_altp2m() to its original state.
- Added an altp2m_active() check to HVMOP_altp2m_switch_p2m.
- Updated patch description.
---
xen/arch/x86/hvm/hvm.c| 20
xen/arch/
g set before it's called.
While at it, I've changed a couple of bool_t's to bool's.
Signed-off-by: Razvan Cojocaru
FTR - this looks okay to me now. But I don't feel qualified to
give an R-b, so just for the parts where it's applicable
Acked-by: Ja
On 2/12/19 8:13 PM, Tamas K Lengyel wrote:
> On Tue, Jan 8, 2019 at 9:39 AM Razvan Cojocaru
> wrote:
>>
>> On 1/8/19 6:27 PM, Jan Beulich wrote:
>>>>>> On 19.12.18 at 19:52, wrote:
>>>> Signed-off-by: Petre Pircalabu
>>>
>>> A
On 2/14/19 8:06 PM, George Dunlap wrote:
> On 2/12/19 11:42 AM, Razvan Cojocaru wrote:
>> HVMOP_altp2m_set_domain_state does not domain_pause(), presumably
>> on purpose (as it was originally supposed to cater to a in-guest
>> agent, and a domain pausing itself is not a good
On Feb 12, 2019, at 11:42 AM, Razvan Cojocaru wrote:
HVMOP_altp2m_set_domain_state does not domain_pause(), presumably
on purpose (as it was originally supposed to cater to a in-guest
agent, and a domain pausing itself is not a good idea).
Sorry to come in here on v4 and suggest changing
On 2/15/19 3:37 PM, George Dunlap wrote:
On Feb 15, 2019, at 1:24 PM, Jan Beulich wrote:
On 15.02.19 at 13:52, wrote:
On Feb 12, 2019, at 11:42 AM, Razvan Cojocaru wrote:
HVMOP_altp2m_set_domain_state does not domain_pause(), presumably
on purpose (as it was originally supposed to
things, no changes are made here to the mutex.
Attempted nesting of this lock isn't a security issue, because all
that will happen is that the vcpu will livelock taking continuations.
Signed-off-by: George Dunlap
Tested-by: Razvan Cojocaru
---
Release exception justification:
- Fixes a bug in t
switch EPTP without an
exit. That code can __vmread() the host p2m's EPT_POINTER
(before HVMOP_altp2m_set_domain_state "for_each_vcpu()" has a
chance to run altp2m_vcpu_initialise(), but after
d->arch.altp2m_active is set).
Signed-off-by: Razvan Cojocaru
---
CC: Jan Beulich
CC:
tp2m_active is set).
Signed-off-by: Razvan Cojocaru
Acked-by: Jan Beulich
Also I assume you mean to have the same justification here as
you have in patch 1, as to 4.12 inclusion. And for this reason
I'm also Cc-ing Jürgen again.
Ideed, I do. Thank you very
On 2/12/19 7:01 PM, Tamas K Lengyel wrote:
On Thu, Feb 7, 2019 at 9:06 AM Petre Ovidiu PIRCALABU
wrote:
On Thu, 2019-02-07 at 11:46 +, George Dunlap wrote:
On 2/6/19 2:26 PM, Petre Ovidiu PIRCALABU wrote:
On Wed, 2018-12-19 at 20:52 +0200, Petre Pircalabu wrote:
This patchset is a rewor
: Jan Beulich
> CC: Wei Liu
> CC: Roger Pau Monné
> CC: Razvan Cojocaru
> CC: Tamas K Lengyel
> CC: Juergen Gross
> ---
> xen/common/domain.c | 16 +---
> xen/include/xen/domain.h | 4
> 2 files changed, 17 insertions(+), 3 deletions(-)
ned-off-by: Andrew Cooper
Reviewed-by: Razvan Cojocaru
Thanks,
Razvan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
idating, and use INVEPT_ALL_CONTEXT if two or more are in need of
> flushing.
>
> This doesn't have an XSA because altp2m is not yet a security-supported
> feature.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Razvan Cojocaru
Thanks,
Razvan
__
an XSA because altp2m is not yet a security-supported
feature.
Signed-off-by: Andrew Cooper
Tested-by: Razvan Cojocaru
Thanks,
Razvan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
s with
> concurrent calls, use cmpxchg() to locklessly maintain safety.
>
> This doesn't have an XSA because altp2m is not yet a security-supported
> feature.
>
> Signed-off-by: Andrew Cooper
> Release-acked-by: Juergen Gross
Tested-by: Razvan Cojocaru
1 - 100 of 595 matches
Mail list logo
