On 04/11/2018 11:04 AM, Razvan Cojocaru wrote:
> Debugging continues.
Finally, the attached patch seems to get the display unstuck in my
scenario, although for one guest I get:
(XEN) d2v0 Unexpected vmexit: reason 49
(XEN) domain_crash called from vmx.c:4120
(XEN) Domain 2 (vcpu#0) crashed
On 04/13/2018 07:38 PM, Tamas K Lengyel wrote:
> On Fri, Apr 13, 2018 at 8:44 AM, Razvan Cojocaru
> wrote:
>> On 04/11/2018 11:04 AM, Razvan Cojocaru wrote:
>>> Debugging continues.
>>
>> Finally, the attached patch seems to get the display unstuck in my
>>
On 04/16/2018 08:47 PM, George Dunlap wrote:
> On 04/13/2018 03:44 PM, Razvan Cojocaru wrote:
>> On 04/11/2018 11:04 AM, Razvan Cojocaru wrote:
>>> Debugging continues.
>>
>> Finally, the attached patch seems to get the display unstuck in my
>> scenario, alth
On 04/16/2018 11:21 PM, George Dunlap wrote:
> On Mon, Apr 16, 2018 at 7:46 PM, Razvan Cojocaru
> wrote:
>> On 04/16/2018 08:47 PM, George Dunlap wrote:
>>> On 04/13/2018 03:44 PM, Razvan Cojocaru wrote:
>>>> On 04/11/2018 11:04 AM, Razvan Cojocaru
On 04/16/2018 11:21 PM, George Dunlap wrote:
> On Mon, Apr 16, 2018 at 7:46 PM, Razvan Cojocaru
> wrote:
>> On 04/16/2018 08:47 PM, George Dunlap wrote:
>>> On 04/13/2018 03:44 PM, Razvan Cojocaru wrote:
>>>> On 04/11/2018 11:04 AM, Razvan Cojocaru
On 04/17/2018 11:24 AM, Razvan Cojocaru wrote:
> On 04/16/2018 11:21 PM, George Dunlap wrote:
>> On Mon, Apr 16, 2018 at 7:46 PM, Razvan Cojocaru
>> wrote:
>>> On 04/16/2018 08:47 PM, George Dunlap wrote:
>>>> On 04/13/2018 03:44 PM, Razvan Cojocaru wrote:
On 04/17/2018 01:49 PM, Razvan Cojocaru wrote:
> On 04/17/2018 11:24 AM, Razvan Cojocaru wrote:
>> On 04/16/2018 11:21 PM, George Dunlap wrote:
>>> On Mon, Apr 16, 2018 at 7:46 PM, Razvan Cojocaru
>>> wrote:
>>>> On 04/16/2018 08:47 PM, George Dunlap wrot
On 04/17/2018 04:53 PM, George Dunlap wrote:
> On 04/17/2018 11:50 AM, Razvan Cojocaru wrote:
>> void p2m_init_altp2m_ept(struct domain *d, unsigned int i)
>> {
>> struct p2m_domain *p2m = d->arch.altp2m_p2m[i];
>> +struct p2m_domain *hostp2m = p2m_
On 04/17/2018 05:58 PM, George Dunlap wrote:
>>> It might be nice to have a more structured way of keeping all these
>>> changes in sync, rather than relying on this open-coding everywhere.
>>
>> Very true. It has also occured to me that some of these issues would be
>> at least partially mitigated
p2m_change_type_range() handles end > max_mapped_pfn, but not
start > max_mapped_pfn. Check the latter just after grabbing the
lock and bail if true.
Signed-off-by: Razvan Cojocaru
Suggested-by: George Dunlap
---
xen/arch/x86/mm/p2m.c | 7 +++
1 file changed, 7 insertions(+)
diff -
On 04/18/2018 10:38 AM, Jan Beulich wrote:
On 17.04.18 at 19:16, wrote:
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -976,6 +976,13 @@ void p2m_change_type_range(struct domain *d,
>> ASSERT(p2m_is_changeable(ot) && p2m_is_changeable(nt));
>>
>> p2m_lock(p2m)
On 04/18/2018 10:48 AM, Razvan Cojocaru wrote:
> On 04/18/2018 10:38 AM, Jan Beulich wrote:
>>>>> On 17.04.18 at 19:16, wrote:
>>> --- a/xen/arch/x86/mm/p2m.c
>>> +++ b/xen/arch/x86/mm/p2m.c
>>> @@ -976,6 +976,13 @@ void p2m_change_type_range(struct
On 04/17/2018 04:53 PM, George Dunlap wrote:
> On 04/17/2018 11:50 AM, Razvan Cojocaru wrote:
>> void p2m_init_altp2m_ept(struct domain *d, unsigned int i)
>> {
>> struct p2m_domain *p2m = d->arch.altp2m_p2m[i];
>> +struct p2m_domain *hostp2m = p2m_
On 04/18/2018 01:45 PM, George Dunlap wrote:
> On 04/18/2018 09:20 AM, Razvan Cojocaru wrote:
>> On 04/17/2018 04:53 PM, George Dunlap wrote:
>>> On 04/17/2018 11:50 AM, Razvan Cojocaru wrote:
>>>> void p2m_init_altp2m_ept(struct domain *d, unsigned int i)
>>&g
p2m_change_type_range() handles end > max_mapped_pfn, but not
start > max_mapped_pfn. Check the latter just after grabbing the
lock and bail if true.
Signed-off-by: Razvan Cojocaru
Suggested-by: George Dunlap
---
Changes since V1:
- Added ASSERT()s.
- Wrapped the new condition in an un
On 04/18/2018 04:12 PM, Razvan Cojocaru wrote:
> p2m_change_type_range() handles end > max_mapped_pfn, but not
> start > max_mapped_pfn. Check the latter just after grabbing the
> lock and bail if true.
>
> Signed-off-by: Razvan Cojocaru
> Suggested-by: George Dunlap
>
On 04/23/2018 02:47 PM, George Dunlap wrote:
> On 04/18/2018 02:12 PM, Razvan Cojocaru wrote:
>> p2m_change_type_range() handles end > max_mapped_pfn, but not
>> start > max_mapped_pfn. Check the latter just after grabbing the
>> lock and bail if true.
>>
On 04/23/2018 05:28 PM, George Dunlap wrote:
> On 04/23/2018 12:56 PM, Razvan Cojocaru wrote:
>> On 04/23/2018 02:47 PM, George Dunlap wrote:
>>> On 04/18/2018 02:12 PM, Razvan Cojocaru wrote:
>>>> p2m_change_type_range() handles end > max_mapped_pfn, but not
>&
Hello,
While testing MSR vm_events, we've come accross some puzzling behaviour
while trying to follow the guest's MSR_LSTAR: it starts out as zero,
then it changes value before the first MSR write event, without going
through svm_msr_write_intercept(). The culprit seems to be a
svm_vmsave_pa() cal
> While testing MSR vm_events, we've come accross some puzzling behaviour
> while trying to follow the guest's MSR_LSTAR: it starts out as zero,
> then it changes value before the first MSR write event, without going
> through svm_msr_write_intercept(). The culprit seems to be a
> svm_vmsave_pa() c
On 04/25/2018 09:49 AM, Jan Beulich wrote:
On 24.04.18 at 20:51, wrote:
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1883,6 +1883,22 @@ static int svm_msr_read_intercept(unsigned int msr,
uint64_t *msr_content)
switch ( msr )
{
case MSR_IA32_SYSENTER_
On 04/25/2018 09:49 AM, Jan Beulich wrote:
On 24.04.18 at 20:51, wrote:
>> --- a/xen/arch/x86/hvm/svm/svm.c
>> +++ b/xen/arch/x86/hvm/svm/svm.c
>> @@ -1883,6 +1883,22 @@ static int svm_msr_read_intercept(unsigned int msr,
>> uint64_t *msr_content)
>> switch ( msr )
>> {
>> cas
On 04/28/2018 12:30 AM, Tamas K Lengyel wrote:
On Mon, Apr 23, 2018 at 2:00 AM, Alexandru Isaila
wrote:
This patch is adding a way to enable/disable inguest pagefault
events. It introduces the xc_monitor_inguest_pagefault function
and adds the inguest_pagefault_disabled in the monitor structure
On 04/28/2018 09:13 AM, Razvan Cojocaru wrote:
On 04/28/2018 12:30 AM, Tamas K Lengyel wrote:
On Mon, Apr 23, 2018 at 2:00 AM, Alexandru Isaila
wrote:
This patch is adding a way to enable/disable inguest pagefault
events. It introduces the xc_monitor_inguest_pagefault function
and adds the
On 04/30/2018 11:11 AM, Jan Beulich wrote:
On 28.04.18 at 08:13, wrote:
>> On 04/28/2018 12:30 AM, Tamas K Lengyel wrote:
>>> On Mon, Apr 23, 2018 at 2:00 AM, Alexandru Isaila
>>> wrote:
This patch is adding a way to enable/disable inguest pagefault
events. It introduces the xc_mon
On 04/23/2018 02:47 PM, George Dunlap wrote:
> On 04/18/2018 02:12 PM, Razvan Cojocaru wrote:
>> p2m_change_type_range() handles end > max_mapped_pfn, but not
>> start > max_mapped_pfn. Check the latter just after grabbing the
>> lock and bail if true.
>>
On 05/03/2018 07:06 AM, Kang, Luwei wrote:
Another thing is Xen's vmevent allows intercepting several other traced states.
It seems that a more generic framework is needed to
make PT work with vmevent subsystem? What is your thought on that?
Hi Wei,
I am not fully clear what is the "vmeve
Hello,
We'd like to retrieve the length of the current instruction in
svm_vmexit_handler(), specifically for the VMEXIT_EXCEPTION_DB and
VMEXIT_EXCEPTION_BP cases.
We've combed the vmcb to no avail. Everything we've thought to check
(exitinfo1, exitinfo2, exitintinfo) turns out to be zero there w
On 03/14/2018 07:06 PM, Andrew Cooper wrote:
> On 14/03/18 15:53, Jan Beulich wrote:
> On 14.03.18 at 15:56, wrote:
>>> We'd like to retrieve the length of the current instruction in
>>> svm_vmexit_handler(), specifically for the VMEXIT_EXCEPTION_DB and
>>> VMEXIT_EXCEPTION_BP cases.
>>>
>>> W
On 03/17/2018 11:45 PM, Andrew Cooper wrote:
> On 17/03/18 21:11, Razvan Cojocaru wrote:
>> On 03/14/2018 07:06 PM, Andrew Cooper wrote:
>>> On 14/03/18 15:53, Jan Beulich wrote:
>>>>>>> On 14.03.18 at 15:56, wrote:
>>>>> We'
On 03/19/2018 04:48 PM, Tamas K Lengyel wrote:
> On Mon, Mar 19, 2018 at 8:07 AM, Alexandru Isaila
> wrote:
>> At this moment the Debug events for the AMD architecture are not
>> forwarded to the monitor layer.
>>
>> This patch adds the Debug event to the common capabilities, adds
>> the VMEXIT_IC
On 03/22/2018 12:22 PM, Lars Kurth wrote:
> Hi all,
>
> please find attached
> a) Meeting details (just a link with timezones) – the meeting invite
> will follow when we have an agenda
> Bridge details – will be sent with the meeting invite
> I am thinking of using GotoMeeting, but want to
event.c
> F: xen/common/mem_access.c
> F: xen/common/monitor.c
> F: xen/common/vm_event.c
>
Acked-by: Razvan Cojocaru
Thanks,
Razvan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 03/13/2018 07:44 PM, Wei Liu wrote:
> On Wed, Dec 13, 2017 at 04:22:20PM +0200, Petre Pircalabu wrote:
> [...]
> Tabs here.
>
> With this fixed, libxc bits:
>
> Acked-by: Wei Liu
We seem to have (again) arrived at an impasse with this patch.
To summarize, the original designers of altp2m ha
Hello,
We're trying to get #VE to work with a "regular" guest page (that is,
not a page that we get via xc_domain_increase_reservation_exact() /
xc_domain_populate_physmap_exact()).
However, the way Xen's code works now, it doesn't seem to be possible:
http://xenbits.xen.org/gitweb/?p=xen.git;a=
On 06/29/2018 06:38 PM, Jan Beulich wrote:
On 28.06.18 at 15:00, wrote:
>> @@ -4666,6 +4667,23 @@ static int do_altp2m_op(
>> }
>> break;
>>
>> +case HVMOP_altp2m_get_mem_access:
>> +if ( a.u.mem_access.pad )
>> +rc = -EINVAL;
>> +else
>> +
On 06/29/2018 07:52 PM, Tamas K Lengyel wrote:
> On Fri, Jun 29, 2018 at 9:25 AM Razvan Cojocaru
> wrote:
>>
>> Hello,
>>
>> We're trying to get #VE to work with a "regular" guest page (that is,
>> not a page t
On 06/29/2018 10:29 PM, Razvan Cojocaru wrote:
> On 06/29/2018 07:52 PM, Tamas K Lengyel wrote:
>> On Fri, Jun 29, 2018 at 9:25 AM Razvan Cojocaru
>> wrote:
>>>
>>> Hello,
>>>
>>> We're trying to get #VE to work with a "
On 07/02/2018 09:34 AM, Jan Beulich wrote:
On 29.06.18 at 18:39, wrote:
>> On 06/29/2018 06:38 PM, Jan Beulich wrote:
>> On 28.06.18 at 15:00, wrote:
@@ -4666,6 +4667,23 @@ static int do_altp2m_op(
}
break;
+case HVMOP_altp2m_get_mem_acces
On 07/05/2018 05:35 PM, Tamas K Lengyel wrote:
> Jan's comment here about the too broad exposure is not without a
> point. For a security application to point in using altp2m and
> memaccess is to have memory protections that the guest can't alter, so
> even if the guest kernel gets compromised, so
On 07/05/2018 07:45 PM, Tamas K Lengyel wrote:
> On Thu, Jul 5, 2018 at 9:22 AM Razvan Cojocaru
> wrote:
>> However, our particular application is only interested in setting (and
>> querying) page restrictions from userspace (from the dom0 agent). It
>> will also ne
On 04/23/2018 05:33 PM, Razvan Cojocaru wrote:
> On 04/23/2018 05:28 PM, George Dunlap wrote:
>> On 04/23/2018 12:56 PM, Razvan Cojocaru wrote:
>>> On 04/23/2018 02:47 PM, George Dunlap wrote:
>>>> On 04/18/2018 02:12 PM, Razvan Cojocaru wrote:
>>>
On 07/09/2018 11:35 AM, Jan Beulich wrote:
On 05.07.18 at 12:44, wrote:
>> Both altp2m get/set memaccess functions use the struct
>> xen_hvm_altp2m_mem_access which has now dropped the `set' part and has
>> been renamed from xen_hvm_altp2m_set_mem_access.
>>
>> Signed-off-by: Adrian Pop
>
>
On 07/09/2018 02:04 PM, George Dunlap wrote:
> On 07/06/2018 05:52 PM, Tamas K Lengyel wrote:
>> On Fri, Jul 6, 2018 at 2:56 AM Razvan Cojocaru
>> wrote:
>>>
>>> On 07/05/2018 07:45 PM, Tamas K Lengyel wrote:
>>>> On Thu, Jul 5, 2018 at 9:22 AM Ra
On 07/09/2018 02:46 PM, George Dunlap wrote:
> On 07/09/2018 12:18 PM, Razvan Cojocaru wrote:
>> On 07/09/2018 02:04 PM, George Dunlap wrote:
>>> On 07/06/2018 05:52 PM, Tamas K Lengyel wrote:
>>>> On Fri, Jul 6, 2018 at 2:56 AM Razvan Cojocaru
>>>>
On 07/02/2018 08:48 AM, Tian, Kevin wrote:
>> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com]
>> Sent: Thursday, June 28, 2018 10:35 PM
>>
>> A VM exit handler executed immediately after enabling #VE might
>> find a stale __vmsave()d EPTP_INDEX, stored by
On 06/28/2018 07:19 PM, Tamas K Lengyel wrote:
> On Thu, Jun 28, 2018 at 1:54 AM Razvan Cojocaru
> wrote:
>>
>> For the hostp2m, access_required starts off as 0, then it can be
>> set with xc_domain_set_access_required(). However, all the altp2ms
>> set it to
ire the page behind the MFN).
>
> Signed-off-by: Julien Grall
Acked-by: Razvan Cojocaru
Thanks,
Razvan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 07/19/2018 11:18 AM, Isaila Alexandru wrote:
> On Mi, 2018-07-18 at 15:33 +, George Dunlap wrote:
>>
>>>
>>> On Jul 2, 2018, at 8:42 AM, Alexandru Isaila >> om> wrote:
>>>
>>> From: Isaila Alexandru
>>>
>>> This patch adds access rights for the NPT pages. The access rights
>>> are
>>> saved
On 07/19/2018 11:30 AM, Jan Beulich wrote:
On 19.07.18 at 10:18, wrote:
>> On Mi, 2018-07-18 at 15:33 +, George Dunlap wrote:
On Jul 2, 2018, at 8:42 AM, Alexandru Isaila >>> +break;
+case p2m_access_x:
+flags &= ~_PAGE_RW;
+
On 07/20/2018 06:07 PM, George Dunlap wrote:
> On 06/28/2018 03:35 PM, Razvan Cojocaru wrote:
>> A VM exit handler executed immediately after enabling #VE might
>> find a stale __vmsave()d EPTP_INDEX, stored by calling
>> altp2m_vcpu_destroy() when SECONDARY_EXEC_ENABLE_VIRT_E
On 07/20/2018 08:18 PM, George Dunlap wrote:
> Furthermore, imagine the following scenario:
>
> * dom0 enables altp2m on domain A
> * dom0 switches altp2m to view 1 on domain A
> * dom0 enables #VE on domain A
> * domain A has a vmexit
> -> At this point, EPTP_INDEX is 0, so the vmexit code will
On 07/23/2018 05:37 AM, sepanta s wrote:
> I have written a program that can share memory pages of two VMs every x
> milliseconds. To do so, I modified xen and added an unshare event to be
> able to capture it. However, for some pages, when I receive the unshare
> event that contains the informati
On 07/23/2018 01:29 PM, George Dunlap wrote:
> It's possible my analysis is wrong there (I'm not intimately familiar
> with the code), but I think my patch is better anyway for a couple of
> reasons:
>
> * The logic to keep EPTP_INDEX in sync is explicit, and all in the same
> file.
>
> * It does
ety-critical
> environment.
>
> C1 would be ideal, but there's nobody at present to do the work.
> Given that, C3 has been seen as the best solution in discussion.
>
> Signed-off-by: George Dunlap
> ---
> Changes since v1:
> - Patch description: clarify that HVM
On 07/24/2018 11:55 AM, Jan Beulich wrote:
>> +if ( cpu_has_svm && !p2m->mem_access_settings )
>> +{
>> +p2m->mem_access_settings = xmalloc(struct radix_tree_root);
>> +
>> +if( !p2m->mem_access_settings )
> Style.
>
>> +{
>> +xfree(d->arch.monitor.msr_b
gt;
> Signed-off-by: Jan Beulich
> ---
> v2: Re-base. Drop guest_cpuid() changes. Fix off-by-1 in
> {do,compat}_dm_op().
Acked-by: Razvan Cojocaru
Thanks,
Razvan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists
On 07/31/2018 08:19 PM, Tamas K Lengyel wrote:
> On Tue, Jul 31, 2018 at 5:53 AM Jan Beulich wrote:
>> I'd like you to outline in the description how you mean an external
>> agent to coordinate the use of this GFN with the guest (and in
>> particular without in-guest agent).
>
> Using #VE without
On 08/01/2018 11:23 AM, Jan Beulich wrote:
On 31.07.18 at 19:19, wrote:
>> On Tue, Jul 31, 2018 at 5:53 AM Jan Beulich wrote:
>> On 25.07.18 at 13:49, wrote:
-vcpu_altp2m(curr).veinfo_gfn = _gfn(a.u.enable_notify.gfn);
-altp2m_vcpu_update_vmfunc_ve(curr);
On 07/23/2018 01:29 PM, George Dunlap wrote:
> On 07/20/2018 07:02 PM, Razvan Cojocaru wrote:
>> On 07/20/2018 08:18 PM, George Dunlap wrote:
>>> Furthermore, imagine the following scenario:
>>>
>>> * dom0 enables altp2m on domain A
>>> * dom0 swi
ly, just out of context).
>
> Return from vmx_vmexit_handler() after the domain_crash(), which also has the
> side effect of reentering the scheduler more promptly.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Razvan Cojocaru
Thanks,
Razvan
__
ctive vcpus for an altp2m will be thrown off.
Fix this by always updating EPTP_INDEX to the current altp2m index
when enabling #VE.
Reported-by: Razvan Cojocaru
Signed-off-by: George Dunlap
Reviewed-by: Razvan Cojocaru
Tested-by: Razvan Cojocaru
---
xen/arch/x86/hvm/vmx/vmx.c | 7 +++
On 08/02/2018 09:32 AM, Tian, Kevin wrote:
>> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com]
>> Sent: Wednesday, August 1, 2018 5:02 PM
>>
>> On 07/23/2018 01:29 PM, George Dunlap wrote:
>>> On 07/20/2018 07:02 PM, Razvan Cojocaru wrote:
>>>>
o test.
>
> NOTE: The test of need_iommu(d) in the AMD IOMMU initialization code has
> been replaced with a test of iommu_dom0_strict since this more
> accurately reflects the meaning of the test and brings it into
> line with a similar test in
Hello,
I'm seeing rare occasions where this backtrace occurs at a point in
__vmx_inject_exception() where there's already a valid interrupt set up
in VM_ENTRY_INTR_INFO (that is, once the value is __vmread(), intr_info
& INTR_INFO_VALID_MASK is non-zero):
Xen call trace:
[] vmx.c#__vmx_inject_
> 2. Is it possible that something else in that path writes into
> VM_ENTRY_INTR_INFO (which the vmx_intr_assist() logic can't possibly
> prevent)? For example, in my Xen 4.7.5 sources, there's a
> pt_restore_timer(v); call in hvm_do_resume() before the vm_event
> emulation code.
Actually even han
On 8/9/18 10:54 AM, Jan Beulich wrote:
On 08.08.18 at 16:26, wrote:
>> 1. Is it possible to already have a valid interrupt written in
>> VM_ENTRY_INTR_INFO at EXIT_REASON_EPT_VIOLATION-time in
>> vmx_vmexit_handler()?
>
> You mean right after the exit? Where would that come from? I'm
> afrai
On 05/18/2018 07:00 PM, Tamas K Lengyel wrote:
> On Fri, May 18, 2018 at 9:32 AM, Jan Beulich wrote:
> On 11.05.18 at 13:11, wrote:
>>> Signed-off-by: Alexandru Isaila
>>
>> It would be helpful to know whether this patch depends on patch 1 in any way.
>> If it doesn't, with Tamas'es ack this
On 05/18/2018 06:30 PM, Jan Beulich wrote:
On 11.05.18 at 13:11, wrote:
>> This patch adds access rights for the NPT pages. The access rights are
>> saved in bits 59:56 of pte that are manipulated through p2m_set_access()
>> and p2m_get_access() functions.
>
> You don't give any rationale fo
This patch mirrors the VMX code that doesn't allow
vmx_disable_intercept_for_msr() to clear interception of MSRs that
an introspection agent is trying to monitor.
Signed-off-by: Razvan Cojocaru
---
xen/arch/x86/hvm/svm/svm.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff
On 05/25/2018 06:19 PM, Boris Ostrovsky wrote:
> On 05/25/2018 08:38 AM, Razvan Cojocaru wrote:
>> This patch mirrors the VMX code that doesn't allow
>> vmx_disable_intercept_for_msr()
>
> vmx_clear_msr_intercept() ?
>
>> to clear interception of MSRs that
>
This patch mirrors the VMX code that doesn't allow
vmx_clear_msr_intercept() to clear interception of MSRs that an
introspection agent is trying to monitor.
Signed-off-by: Razvan Cojocaru
Reviewed-by: Boris Ostrovsky
---
Changes since V1:
- Fixed commit message (updated the function na
ooper
> ---
> CC: Jan Beulich
> CC: Wei Liu
> CC: Roger Pau Monné
> CC: Jun Nakajima
> CC: Kevin Tian
> CC: Boris Ostrovsky
> CC: Suravee Suthikulpanit
> CC: Brian Woods
> CC: Razvan Cojocaru
> CC: Tamas K Lengyel
>
> This is RFC because it probably
On 06/04/2018 05:53 PM, Razvan Cojocaru wrote:
> On 06/04/2018 04:59 PM, Andrew Cooper wrote:
>> Currently, there is a lot of functionality in the #DB intercepts, and some
>> repeated functionality in the *_inject_event() logic.
>>
>> The gdbsx code is impleme
On 06/04/2018 06:39 PM, Andrew Cooper wrote:
> On 04/06/18 14:59, Andrew Cooper wrote:
>> So this started as a small fix for the vmentry failure (penultimate patch),
>> and has snowballed...
>>
>> I'm fairly confident that everything involving DEBUGCTL.BTF is broken, and
>> there are definitely bug
values received via hypecall
too all the active altp2ms, when applicable.
Signed-off-by: Razvan Cojocaru
---
xen/arch/arm/domain.c| 4
xen/arch/x86/domain.c| 17 +
xen/arch/x86/mm/p2m.c| 3 ++-
xen/common/domctl.c | 2 ++
xen/include/xen/domain.h | 2 ++
5
Thanks for the review!
On 06/12/2018 03:23 PM, Jan Beulich wrote:
On 11.06.18 at 17:12, wrote:
>> --- a/xen/arch/x86/domain.c
>> +++ b/xen/arch/x86/domain.c
>> @@ -38,6 +38,7 @@
>> #include
>> #include
>> #include
>> +#include
>
> Not the least to avoid this I think ...
>
>> @@ -719
On 06/12/2018 03:35 PM, Razvan Cojocaru wrote:
>>> @@ -210,7 +211,7 @@ static int p2m_init_altp2m(struct domain *d)
>>> return -ENOMEM;
>>> }
>>> p2m->p2m_class = p2m_alternate;
>>> -p2m->access_requir
P2M). Since MAX_ALTP2M is
currently 10 and INVALID_ALTP2M is #defined as 0x, the
domain will always crash in this case.
Signed-off-by: Razvan Cojocaru
---
Cc: Jun Nakajima
Cc: Kevin Tian
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Tamas K Lengyel
---
xen/arch/x86/hvm/vmx/vmx.c | 2 +-
1 f
values received via hypercall
to all the active altp2ms, when applicable.
Signed-off-by: Razvan Cojocaru
---
Cc: Stefano Stabellini
Cc: Julien Grall
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Konrad Rzeszutek Wilk
Cc: Tim Deegan
Cc: Wei Liu
Cc: George Dunlap
On 06/22/2018 06:28 PM, Jan Beulich wrote:
On 13.06.18 at 10:52, wrote:
>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> @@ -3592,7 +3592,7 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
>> }
>> }
>>
>> -if ( idx != vcpu_altp2m
On 06/22/2018 07:55 PM, Razvan Cojocaru wrote:
> On 06/22/2018 06:28 PM, Jan Beulich wrote:
>>>>> On 13.06.18 at 10:52, wrote:
>>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>>> @@ -3592,7 +3592,7 @@ void
On 06/25/2018 03:28 PM, Jan Beulich wrote:
>>>> On 25.06.18 at 14:12, wrote:
>> On 06/22/2018 07:55 PM, Razvan Cojocaru wrote:
>>> On 06/22/2018 06:28 PM, Jan Beulich wrote:
>>>>>>> On 13.06.18 at 10:52, wrote:
>>>>> --- a/xe
> (XEN) [ 1923.964832] altp2m_vcpu_initialise()
> (XEN) [ 1923.964836] altp2m_vcpu_reset()
> (XEN) [ 1923.964837] 1 altp2m_vcpu_update_p2m()
> (XEN) [ 1923.964838] vmx_vcpu_update_eptp()
> (XEN) [ 1923.964876] HVMOP_altp2m_vcpu_enable_notify
> (XEN) [ 1923.964878] vmx_vcpu_update_vmfunc_ve(0),
> v-
On 06/25/2018 03:54 PM, Jan Beulich wrote:
On 25.06.18 at 14:40, wrote:
>>> Crash:
>>>
>>> (XEN) [ 1924.367273] altp2m_vcpu_initialise()
>>> (XEN) [ 1924.367277] altp2m_vcpu_reset()
>>> (XEN) [ 1924.367278] 1 altp2m_vcpu_update_p2m()
>>> (XEN) [ 1924.367279] vmx_vcpu_update_eptp()
>>> (XEN) [
. This makes it possible for vmx_vmexit_handler()
to __vmread() the stale value after a subsequent call to
xc_altp2m_set_vcpu_enable_notify(), and BUG_ON(idx >= MAX_ALTP2M).
Signed-off-by: Razvan Cojocaru
---
Changes since V1:
- Re-wrote the fix to affect the altp2m code instead of the c
ng altp2m on a
>> domain after xc_altp2m_set_vcpu_enable_notify() has been
>> successfully called, EPTP_INDEX ends up being stored as
>> INVALID_ALTP2M. This makes it possible for vmx_vmexit_handler()
>> to __vmread() the stale value after a subsequent call to
>> xc_altp2m_set_vcpu_enable_notify()
On 06/26/2018 02:56 PM, Jan Beulich wrote:
On 26.06.18 at 12:55, wrote:
>> On 06/26/2018 01:26 PM, Jan Beulich wrote:
>> On 25.06.18 at 16:10, wrote:
--- a/xen/arch/x86/mm/altp2m.c
+++ b/xen/arch/x86/mm/altp2m.c
@@ -58,8 +58,8 @@ altp2m_vcpu_destroy(struct vcpu *v)
On 06/26/2018 03:06 PM, Razvan Cojocaru wrote:
> On 06/26/2018 02:56 PM, Jan Beulich wrote:
>>>>> On 26.06.18 at 12:55, wrote:
>>> On 06/26/2018 01:26 PM, Jan Beulich wrote:
>>>>>>> On 25.06.18 at 16:10, wrote:
>>>>> ---
. This makes it possible for vmx_vmexit_handler()
to __vmread() the stale value after a subsequent call to
xc_altp2m_set_vcpu_enable_notify(), and BUG_ON(idx >= MAX_ALTP2M).
Signed-off-by: Razvan Cojocaru
---
Changes since V2:
- Changed verb tense in commit message subject.
- Now call
On 06/27/2018 12:46 PM, Jan Beulich wrote:
On 26.06.18 at 16:21, wrote:
>> When SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS is set,
>> vmx_vcpu_update_eptp() __vmwrites() EPTP_INDEX in
>> altp2m_vcpu_destroy(). This means that when disabling altp2m on a
>> domain after xc_altp2m_set_vcpu_enable_not
(such as __vmwrite(VM_FUNCTION_CONTROL, ...)).
Signed-off-by: Razvan Cojocaru
---
Changes since V3:
- Expanded and clarified the patch commit message.
---
xen/arch/x86/mm/altp2m.c | 1 -
xen/include/asm-x86/hvm/hvm.h | 2 ++
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/xen/arc
On 06/27/2018 06:04 PM, Jan Beulich wrote:
On 27.06.18 at 15:12, wrote:
>> xc_altp2m_set_vcpu_enable_notify() ends up calling
>> altp2m_vcpu_update_vmfunc_ve(), which sets the
>> SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS bit on
>> vmx_secondary_exec_control. A subsequent call to
>> xc_altp2m_set_
On 06/27/2018 05:09 PM, Wei Liu wrote:
> On Wed, Jun 13, 2018 at 11:52:18AM +0300, Razvan Cojocaru wrote:
>> ---
>> xen/arch/arm/mem_access.c| 5 +
>> xen/arch/x86/mm/mem_access.c | 18 ++
>> xen/arch/x86/mm/p2m.c| 3 ++-
>>
values received via hypercall
to all the active altp2ms, when applicable.
Signed-off-by: Razvan Cojocaru
---
Cc: Stefano Stabellini
Cc: Julien Grall
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Konrad Rzeszutek Wilk
Cc: Tim Deegan
Cc: Wei Liu
Cc: George Dunlap
into one everywhere,
since in p2m_switch_domain_altp2m_by_id() and
p2m_switch_vcpu_altp2m_by_id() the extra work done by
altp2m_vcpu_update_vmfunc_ve() is unnecessary and has side
effects (such as __vmwrite(VM_FUNCTION_CONTROL, ...)).
Signed-off-by: Razvan Cojocaru
---
Changes since V4:
- T
On 06/28/2018 05:53 PM, Alexandru Stefan ISAILA wrote:
> On Jo, 2018-06-28 at 08:40 -0600, Jan Beulich wrote:
>>>
>
> On 28.06.18 at 16:10, wrote:
>>> On Vi, 2018-06-22 at 09:51 -0600, Jan Beulich wrote:
>
>>
>>>
>>> On 18.06.18 at 17:17, wrote:
> From: Isail
On 8/9/18 11:35 AM, Jan Beulich wrote:
On 09.08.18 at 10:20, wrote:
>> On 8/9/18 10:54 AM, Jan Beulich wrote:
>> On 08.08.18 at 16:26, wrote:
1. Is it possible to already have a valid interrupt written in
VM_ENTRY_INTR_INFO at EXIT_REASON_EPT_VIOLATION-time in
vmx_vmexit_h
On 8/13/18 3:22 PM, Jan Beulich wrote:
On 13.08.18 at 13:55, wrote:
>> On 8/9/18 11:35 AM, Jan Beulich wrote:
>> On 09.08.18 at 10:20, wrote:
On 8/9/18 10:54 AM, Jan Beulich wrote:
On 08.08.18 at 16:26, wrote:
>> 1. Is it possible to already have a valid interrupt writ
On 8/13/18 3:58 PM, Jan Beulich wrote:
On 13.08.18 at 14:51, wrote:
>> So first we've got that vmx_idtv_reinject() call writing to the VMCS,
>> then we emulate a CLI, then the failed vmentry. I can't tell if the CLI
>> ran first and then an interrupt popped up, or if an interrupt had
>> alrea
201 - 300 of 595 matches
Mail list logo
