On Feb 22, 2016 04:23, "Razvan Cojocaru" wrote:
>
> On 02/19/2016 07:26 PM, Lengyel, Tamas wrote:
> >
> >
> > On Fri, Feb 19, 2016 at 10:18 AM, Andrew Cooper
> > mailto:andrew.coop...@citrix.com>> wrote:
> >
> > On 19/02/16 17:06, Len
On Fri, Feb 19, 2016 at 10:26 AM, Lengyel, Tamas
wrote:
>
>
>
> On Fri, Feb 19, 2016 at 10:18 AM, Andrew Cooper > wrote:
>
>> On 19/02/16 17:06, Lengyel, Tamas wrote:
>>
>>
>>
>> On Tue, Feb 16, 2016 at 3:47 AM, Jan Beulich wrote:
>>
On Fri, Feb 19, 2016 at 10:18 AM, Andrew Cooper
wrote:
> On 19/02/16 17:06, Lengyel, Tamas wrote:
>
>
>
> On Tue, Feb 16, 2016 at 3:47 AM, Jan Beulich wrote:
>
>> >>> On 16.02.16 at 07:58, < kevin.t...@intel.com>
>> wrote:
>> >> --- a/xe
On Tue, Feb 16, 2016 at 3:47 AM, Jan Beulich wrote:
> >>> On 16.02.16 at 07:58, wrote:
> >> --- a/xen/arch/x86/hvm/vmx/vmx.c
> >> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> >> @@ -490,6 +490,7 @@ static void vmx_vmcs_save(struct vcpu *v, struct
> hvm_hw_cpu
> >> *c)
> >> __vmread(GUEST_SYSENTER_CS,
On Mon, Feb 15, 2016 at 10:06 AM, Jan Beulich wrote:
> >>> On 15.02.16 at 17:55, wrote:
> > On Mon, Feb 15, 2016 at 9:48 AM, Jan Beulich wrote:
> >
> >> >>> On 15.02.16 at 17:27, wrote:
> >> > On Fri, Feb 12, 2016 at 8:00 AM, Jan Beulich
> wrote:
> >> >
> >> >> >>> On 12.02.16 at 13:57, wrot
On Mon, Feb 15, 2016 at 9:48 AM, Jan Beulich wrote:
> >>> On 15.02.16 at 17:27, wrote:
> > On Fri, Feb 12, 2016 at 8:00 AM, Jan Beulich wrote:
> >
> >> >>> On 12.02.16 at 13:57, wrote:
> >> > On Feb 12, 2016 02:12, "Jan Beulich" wrote:
> >> >>
> >> >> >>> On 12.02.16 at 01:22, wrote:
> >> >>
On Fri, Feb 12, 2016 at 8:00 AM, Jan Beulich wrote:
> >>> On 12.02.16 at 13:57, wrote:
> > On Feb 12, 2016 02:12, "Jan Beulich" wrote:
> >>
> >> >>> On 12.02.16 at 01:22, wrote:
> >> > Sending the dr7 register during vm_events is useful for various
> > applications,
> >> > but the current way
On Fri, Feb 12, 2016 at 7:57 AM, Jan Beulich wrote:
> >>> On 12.02.16 at 13:50, wrote:
> > On Feb 12, 2016 03:41, "Jan Beulich" wrote:
> >> In which case ASSERT(is_hvm_vcpu(curr)) would be the common
> >> way to document this (at once avoiding the open coding of
> >> is_hvm_vcpu()).
> >>
> >
>
On Feb 12, 2016 02:12, "Jan Beulich" wrote:
>
> >>> On 12.02.16 at 01:22, wrote:
> > Sending the dr7 register during vm_events is useful for various
applications,
> > but the current way the register value is gathered is incorrent. In this
> > patch
> > we extend vmx_vmcs_save so that we get the
On Feb 12, 2016 03:41, "Jan Beulich" wrote:
>
> >>> On 12.02.16 at 11:19, wrote:
> > On 02/12/2016 11:57 AM, Jan Beulich wrote:
> > On 12.02.16 at 01:22, wrote:
> >>> --- a/xen/arch/x86/vm_event.c
> >>> +++ b/xen/arch/x86/vm_event.c
> >>> @@ -122,6 +122,65 @@ void vm_event_set_registers(stru
On Thu, Feb 11, 2016 at 3:30 PM, Andrew Cooper
wrote:
> On 11/02/2016 22:25, Lengyel, Tamas wrote:
>
>
>
> On Thu, Feb 11, 2016 at 2:58 PM, Andrew Cooper
> wrote:
>
>> On 11/02/2016 21:49, Razvan Cojocaru wrote:
>> > On 02/11/2016 11:35 PM, Andrew Cooper wro
On Thu, Feb 11, 2016 at 2:58 PM, Andrew Cooper
wrote:
> On 11/02/2016 21:49, Razvan Cojocaru wrote:
> > On 02/11/2016 11:35 PM, Andrew Cooper wrote:
> >> On 11/02/2016 21:05, Tamas K Lengyel wrote:
> >>
> >>> diff --git a/xen/arch/x86/vm_event.c b/xen/arch/x86/vm_event.c
> >>> index 08d678a..fa5d
On Tue, Feb 9, 2016 at 10:17 AM, Jan Beulich wrote:
> >>> On 05.02.16 at 22:22, wrote:
> > --- a/xen/include/public/memory.h
> > +++ b/xen/include/public/memory.h
> > @@ -423,11 +423,20 @@ struct xen_mem_access_op {
> > /* xenmem_access_t */
> > uint8_t access;
> > domid_t domid;
On Mon, Feb 1, 2016 at 9:21 AM, Jan Beulich wrote:
> >>> On 01.02.16 at 15:45, wrote:
> > On Fri, 2016-01-29 at 09:47 -0700, Jan Beulich wrote:
> >> > > > On 29.01.16 at 17:32, wrote:
> >> > On Fri, Jan 29, 2016 at 9:19 AM, Jan Beulich
> wrote:
> >> > > > > > On 29.01.16 at 17:12, wrote:
> >>
On Mon, Feb 1, 2016 at 9:30 AM, Ian Campbell
wrote:
> On Mon, 2016-02-01 at 09:21 -0700, Jan Beulich wrote:
> > > > > On 01.02.16 at 15:45, wrote:
> > > On Fri, 2016-01-29 at 09:47 -0700, Jan Beulich wrote:
> > > > > > > On 29.01.16 at 17:32, wrote:
> > > > > On Fri, Jan 29, 2016 at 9:19 AM, Ja
On Fri, Jan 29, 2016 at 2:32 PM, Corneliu ZUZU
wrote:
> On 1/29/2016 6:47 PM, Lengyel, Tamas wrote:
>
>
> by leaving there only the x86-specific part, i.e.:
>> struct {
>> uint8_t mov_to_msr_enabled : 1;
>> uint8_t mov_to_msr_extended
> by leaving there only the x86-specific part, i.e.:
> struct {
> uint8_t mov_to_msr_enabled : 1;
> uint8_t mov_to_msr_extended : 1;
> } monitor;
>
> and moving the rest directly into the domain structure, i.e. add @ the end
> of struct domain [@ xen/inclu
On Fri, Jan 29, 2016 at 9:19 AM, Jan Beulich wrote:
> >>> On 29.01.16 at 17:12, wrote:
> > On Fri, Jan 29, 2016 at 4:03 AM, Jan Beulich wrote:
> >> >>> On 28.01.16 at 21:58, wrote:
> >> > --- a/xen/arch/x86/mm/p2m.c
> >> > +++ b/xen/arch/x86/mm/p2m.c
> >> > @@ -1777,14 +1777,57 @@ bool_t p2m_m
On Fri, Jan 29, 2016 at 4:03 AM, Jan Beulich wrote:
> >>> On 28.01.16 at 21:58, wrote:
> > --- a/xen/arch/x86/mm/p2m.c
> > +++ b/xen/arch/x86/mm/p2m.c
> > @@ -1777,14 +1777,57 @@ bool_t p2m_mem_access_check(paddr_t gpa,
> unsigned long gla,
> > return (p2ma == p2m_access_n2rwx);
> > }
> >
On Thu, Jan 28, 2016 at 10:04 AM, Razvan Cojocaru wrote:
> On 01/28/2016 06:40 PM, Lengyel, Tamas wrote:
> >
> >
> > On Thu, Jan 28, 2016 at 9:32 AM, Razvan Cojocaru
> > mailto:rcojoc...@bitdefender.com>> wrote:
> >
> >
On Thu, Jan 28, 2016 at 9:32 AM, Razvan Cojocaru
wrote:
> On 01/28/2016 05:58 PM, Lengyel, Tamas wrote:
> >
> >
> > On Thu, Jan 28, 2016 at 8:20 AM, Razvan Cojocaru
> > mailto:rcojoc...@bitdefender.com>> wrote:
> >
> > On 01/28/2016 05:12 PM, Len
On Thu, Jan 28, 2016 at 8:20 AM, Razvan Cojocaru
wrote:
> On 01/28/2016 05:12 PM, Lengyel, Tamas wrote:
> >
> > On Jan 28, 2016 8:02 AM, "Razvan Cojocaru" > <mailto:rcojoc...@bitdefender.com>> wrote:
> >>
> >> On 01/28/2016 04:42 PM, Leng
On Jan 28, 2016 8:02 AM, "Razvan Cojocaru"
wrote:
>
> On 01/28/2016 04:42 PM, Lengyel, Tamas wrote:
> >
> > On Jan 28, 2016 6:38 AM, "Jan Beulich" > <mailto:jbeul...@suse.com>> wrote:
> >>
> >> >>> On 27.01.16 at 21:06
On Jan 28, 2016 7:56 AM, "Jan Beulich" wrote:
>
> >>> On 28.01.16 at 15:42, wrote:
> > On Jan 28, 2016 6:38 AM, "Jan Beulich" wrote:
> >> >>> On 27.01.16 at 21:06, wrote:
> >> > --- a/xen/arch/x86/mm/p2m.c
> >> > +++ b/xen/arch/x86/mm/p2m.c
> >> > @@ -1572,7 +1572,9 @@ void p2m_mem_access_emula
On Jan 28, 2016 6:38 AM, "Jan Beulich" wrote:
>
> >>> On 27.01.16 at 21:06, wrote:
> > --- a/xen/arch/x86/mm/p2m.c
> > +++ b/xen/arch/x86/mm/p2m.c
> > @@ -1572,7 +1572,9 @@ void p2m_mem_access_emulate_check(struct vcpu *v,
> > bool_t violation = 1;
> > const struct vm_event_mem_
On Jan 28, 2016 6:18 AM, "Jan Beulich" wrote:
>
> >>> On 27.01.16 at 21:06, wrote:
> > --- a/xen/include/public/hvm/hvm_op.h
> > +++ b/xen/include/public/hvm/hvm_op.h
> > @@ -431,18 +431,6 @@ struct xen_hvm_altp2m_view {
> > typedef struct xen_hvm_altp2m_view xen_hvm_altp2m_view_t;
> > DEFINE_X
On Jan 28, 2016 4:00 AM, "Wei Liu" wrote:
>
> On Thu, Jan 28, 2016 at 10:55:36AM +, Ian Campbell wrote:
> > --- a/tools/libxc/include/xenctrl.h
> > > > +++ b/tools/libxc/include/xenctrl.h
> > > > @@ -2027,9 +2027,6 @@ int xc_altp2m_destroy_view(xc_interface
*handle,
> > > > domid_t domid,
> >
On Mon, Dec 7, 2015 at 4:09 AM, Razvan Cojocaru
wrote:
> Hello,
>
> While looking at some code with Tamas these past few days, we discovered
> that xc_mem_access_enable_emulate() doesn't actually do anything other
> that setting the mem_access_emulate_enabled flag.
>
> Fixing that would likely be
On Tue, Jul 14, 2015 at 5:56 AM, Wei Liu wrote:
> On Mon, Jul 13, 2015 at 05:15:03PM -0700, Ed White wrote:
> > From: Tamas K Lengyel
> >
> > Working altp2m test-case. Extended the test tool to support
> singlestepping
> > to better highlight the core feature of altp2m view switching.
> >
> > Si
On Mon, Jul 13, 2015 at 1:14 PM, Razvan Cojocaru
wrote:
> This patch adds support for memory-content hiding, by modifying the
> value returned by emulated instructions that read certain memory
> addresses that contain sensitive data. The patch only applies to
> cases where VM_FLAG_ACCESS_EMULATE
On Fri, Jul 10, 2015 at 7:36 AM, Ian Campbell
wrote:
> On Thu, 2015-07-09 at 09:14 -0400, Tamas K Lengyel wrote:
> > xen/include/asm-arm/vm_event.h | 31 +++
>
> Acked-by: Ian Campbell
>
> > diff --git a/xen/arch/x86/vm_event.c b/xen/arch/x86/vm_event.c
> > new file m
> @@ -546,6 +652,23 @@ int main(int argc, char *argv[])
> }
>
> break;
> +case VM_EVENT_REASON_SINGLESTEP:
> +printf("Singlestep: rip=%016"PRIx64", vcpu %d\n",
> + req.regs.x86.rip,
> + req.vcp
> diff --git a/xen/include/public/vm_event.h b/xen/include/public/vm_event.h
> index 577e971..6dfa9db 100644
> --- a/xen/include/public/vm_event.h
> +++ b/xen/include/public/vm_event.h
> @@ -47,6 +47,16 @@
> #define VM_EVENT_FLAG_VCPU_PAUSED (1 << 0)
> /* Flags to aid debugging mem_event */
>
On Thu, Jul 9, 2015 at 9:17 AM, Razvan Cojocaru
wrote:
> On 07/09/2015 04:14 PM, Tamas K Lengyel wrote:
> > Add tools/tests/xen-acess to the supported list under VM EVENT/MEM
> ACCESS.
> >
> > Signed-off-by: Tamas K Lengyel
> > ---
> > MAINTAINERS | 1 +
> > 1 file changed, 1 insertion(+)
> >
>
>
> I don't feel very strongly about it, so if you really prefer you can
> keep the code as it is, however this looks somewhat counterintuitive to
> me, especially when you compare the new condition to the old one, because
> ...
>
Yea, this patch is not critical. Jan just requested to use a wrappe
On Thu, Jul 9, 2015 at 4:15 AM, Jan Beulich wrote:
> >>> On 09.07.15 at 08:15, wrote:
> > On 07/09/2015 01:52 AM, Tamas K Lengyel wrote:
> >> --- a/xen/include/asm-x86/hvm/hvm.h
> >> +++ b/xen/include/asm-x86/hvm/hvm.h
> >> @@ -514,6 +514,17 @@ static inline enum hvm_intblk
> nhvm_interrupt_bloc
On Jul 9, 2015 5:15 AM, "Ian Campbell" wrote:
>
> On Wed, 2015-07-08 at 18:52 -0400, Tamas K Lengyel wrote:
> > Add option to monitor_op domctl to determine the monitor capabilities
of the
> > system.
> >
> > Signed-off-by: Tamas K Lengyel
> > ---
> > v4: add inline function wrapper for is_single
On Wed, Jul 8, 2015 at 10:39 AM, Jan Beulich wrote:
> >>> On 07.07.15 at 15:52, wrote:
> > --- a/xen/arch/x86/hvm/hvm.c
> > +++ b/xen/arch/x86/hvm/hvm.c
> > @@ -6431,6 +6431,17 @@ int hvm_debug_op(struct vcpu *v, int32_t op)
> > return rc;
> > }
> >
> > +void hvm_toggle_singlestep(struct v
On Wed, Jul 8, 2015 at 10:37 AM, Jan Beulich wrote:
> >>> On 07.07.15 at 15:52, wrote:
> > --- a/xen/arch/x86/monitor.c
> > +++ b/xen/arch/x86/monitor.c
> > @@ -42,10 +42,29 @@ int status_check(struct xen_domctl_monitor_op *mop,
> bool_t status)
> > return 0;
> > }
> >
> > +static inline u
>
> Are the license headers required? I just tried to make the change as
> small as possible, and looking at the other headers (for example in
> xen/include/asm-arm), at least half of them have no license header. I'm
> guessing this is something we'd now like to start correcting in new
> patches?
>
On Wed, Jul 8, 2015 at 6:22 AM, Razvan Cojocaru
wrote:
> This patch adds support for memory-content hiding, by modifying the
> value returned by emulated instructions that read certain memory
> addresses that contain sensitive data. The patch only applies to
> cases where MEM_ACCESS_EMULATE or ME
On Wed, Jul 8, 2015 at 6:22 AM, Razvan Cojocaru
wrote:
> Deny register writes if a vm_client subscribed to mov_to_msr or
> control register write events forbids them. Currently supported for
> MSR, CR0, CR3 and CR4 events.
>
> Signed-off-by: Razvan Cojocaru
> Acked-by: George Dunlap
> Acked-by:
> > Now looking at this more closely - VM_EVENT_FLAG_EMULATE_NOWRITE doesn't
> > get set on rsp->flags. As such, it would make sense to keep it as a
> > separate define (simply VM_EVENT_EMULATE_NOWRITE?). IMHO VM_EVENT_FLAG_*
> > defines should correspond to things set on the req/rsp->flags field.
On Tue, Jul 7, 2015 at 9:54 AM, Razvan Cojocaru
wrote:
> By naming, placing and bit shift convention, it could be taken as
> implied that MEM_ACCESS_EMULATE and MEM_ACCESS_EMULATE_NOWRITE are
> mem_access event specific flags (instead of being generally
> applicable as vm_event flags). This patch
On Tue, Jul 7, 2015 at 9:21 AM, Razvan Cojocaru
wrote:
> On 07/07/2015 04:15 PM, Lengyel, Tamas wrote:
> >
> >
> > On Tue, Jul 7, 2015 at 9:09 AM, Razvan Cojocaru
> > mailto:rcojoc...@bitdefender.com>> wrote:
> >
> > So VM_EVENT_FLAG_FOREIGN (1
On Tue, Jul 7, 2015 at 9:21 AM, Razvan Cojocaru
wrote:
> On 07/07/2015 03:55 PM, Lengyel, Tamas wrote:
> >
> >
> > On Tue, Jul 7, 2015 at 5:06 AM, Razvan Cojocaru
> > mailto:rcojoc...@bitdefender.com>> wrote:
> >
> > On 07/06/2015 08:05 PM, Len
On Tue, Jul 7, 2015 at 9:09 AM, Razvan Cojocaru
wrote:
> On 07/07/2015 03:04 PM, Lengyel, Tamas wrote:
> >
> >
> > On Tue, Jul 7, 2015 at 4:10 AM, Razvan Cojocaru
> > mailto:rcojoc...@bitdefender.com>> wrote:
> >
> > On 07/06/2015 09:30 PM, Lengye
On Tue, Jul 7, 2015 at 5:06 AM, Razvan Cojocaru
wrote:
> On 07/06/2015 08:05 PM, Lengyel, Tamas wrote:
> > @@ -410,6 +414,8 @@ void vm_event_resume(struct domain *d, struct
> > vm_event_domain *ved)
> >
> >
> > #ifdef HAS_MEM_ACCESS
> >
On Tue, Jul 7, 2015 at 4:10 AM, Razvan Cojocaru
wrote:
> On 07/06/2015 09:30 PM, Lengyel, Tamas wrote:
> > If you'd prefer that I do some ground work for the future (i.e.
> rename
> > MEM_ACCESS constants, etc.), please let me know.
> >
> >
> > Ye
On Tue, Jul 7, 2015 at 4:22 AM, Jan Beulich wrote:
> >>> On 07.07.15 at 02:43, wrote:
> > --- a/xen/arch/x86/hvm/hvm.c
> > +++ b/xen/arch/x86/hvm/hvm.c
> > @@ -6431,6 +6431,11 @@ int hvm_debug_op(struct vcpu *v, int32_t op)
> > return rc;
> > }
> >
> > +bool_t hvm_is_singlestep_supported(v
On Tue, Jul 7, 2015 at 5:27 AM, Jan Beulich wrote:
> >>> On 30.06.15 at 16:11, wrote:
> > --- a/xen/arch/x86/hvm/hvm.c
> > +++ b/xen/arch/x86/hvm/hvm.c
> > @@ -6431,6 +6431,17 @@ int hvm_debug_op(struct vcpu *v, int32_t op)
> > return rc;
> > }
> >
> > +void hvm_toggle_singlestep(struct vc
> I believe, unless Tamas says otherwise, that we agreed the
> HVMOP's in question and their implementations are sufficiently
> different that we should not merge them.
I'm still not entirely convinced of this being the case but considering
altp2m will be an experimental feature I'm not going to
>
> If you'd prefer that I do some ground work for the future (i.e. rename
> MEM_ACCESS constants, etc.), please let me know.
Yeap, that sounds reasonable to me.
Thanks,
Tamas
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-
On Mon, Jul 6, 2015 at 1:29 PM, Razvan Cojocaru
wrote:
> On 07/06/2015 08:17 PM, Andrew Cooper wrote:
> > On 06/07/15 18:08, Lengyel, Tamas wrote:
> >>
> >> Having said that (and with the understading that it is beyond the
> >> scope
> >>
> Having said that (and with the understading that it is beyond the scope
> of this patch), a way to validate things like these is a good idea. I
> wonder if, in a future patch, we could not have ./configure detect these
> things and simply disable the relevant VM_EVENT_FLAG constants with
> #if(n)
@@ -410,6 +414,8 @@ void vm_event_resume(struct domain *d, struct
vm_event_domain *ved)
>
> #ifdef HAS_MEM_ACCESS
> case VM_EVENT_REASON_MEM_ACCESS:
> +case VM_EVENT_REASON_MOV_TO_MSR:
> +case VM_EVENT_REASON_WRITE_CTRLREG:
>
This doesn't really make much sense to be ass
On Mon, Jul 6, 2015 at 11:51 AM, Razvan Cojocaru
wrote:
> Added support for a new class of vm_events: VM_EVENT_REASON_REQUEST,
> sent via HVMOP_request_vm_event. The guest can request that a
> generic vm_event (containing only the vm_event-filled guest registers
> as information) be sent to users
Handy feature, thanks for doing it!
@@ -1466,6 +1466,10 @@ void p2m_mem_access_emulate_check(struct vcpu *v,
> }
>
> v->arch.vm_event.emulate_flags = violation ? rsp->flags : 0;
> +
> +if ( rsp->flags & MEM_ACCESS_SET_EMUL_READ_DATA &&
>
So one of the use-cases for this
On Mon, Jul 6, 2015 at 11:54 AM, Jan Beulich wrote:
> >>> On 06.07.15 at 17:35, wrote:
> > On Mon, Jul 6, 2015 at 11:26 AM, Jan Beulich wrote:
> >
> >> >>> On 30.06.15 at 16:40, wrote:
> >> > On Tue, Jun 30, 2015 at 10:18 AM, Andrew Cooper <
> >> andrew.coop...@citrix.com>
> >> > wrote:
> >> >
On Mon, Jul 6, 2015 at 11:26 AM, Jan Beulich wrote:
> >>> On 30.06.15 at 16:40, wrote:
> > On Tue, Jun 30, 2015 at 10:18 AM, Andrew Cooper <
> andrew.coop...@citrix.com>
> > wrote:
> >
> >> On 30/06/15 15:11, Tamas K Lengyel wrote:
> >> > diff --git a/xen/include/public/vm_event.h
> >> b/xen/inc
On Mon, Jul 6, 2015 at 6:26 AM, Jan Beulich wrote:
> >>> On 30.06.15 at 16:48, wrote:
> >> > --- a/xen/include/asm-x86/domain.h
> >
> >> >> +++ b/xen/include/asm-x86/domain.h
> >> >> @@ -342,13 +342,15 @@ struct arch_domain
> >> >>
> >> >> /* Monitor options */
> >> >> struct {
> >> >>
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> index 58d4951..576b28d 100644
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -1514,6 +1514,13 @@ void p2m_mem_access_emulate_check(struct vcpu *v,
> }
> }
>
> +void p2m_altp2m_check(struct vcpu *v, const vm_event_
>> --- a/xen/include/asm-x86/domain.h
> >> +++ b/xen/include/asm-x86/domain.h
> >> @@ -342,13 +342,15 @@ struct arch_domain
> >>
> >> /* Monitor options */
> >> struct {
> >> -uint16_t write_ctrlreg_enabled : 4;
> >> -uint16_t write_ctrlreg_sync : 4;
> >> -
On Tue, Jun 30, 2015 at 10:18 AM, Andrew Cooper
wrote:
> On 30/06/15 15:11, Tamas K Lengyel wrote:
> > diff --git a/xen/include/public/vm_event.h
> b/xen/include/public/vm_event.h
> > index 577e971..b8c3dde 100644
> > --- a/xen/include/public/vm_event.h
> > +++ b/xen/include/public/vm_event.h
> >
On Mon, Jun 29, 2015 at 10:09 AM, Lengyel, Tamas
wrote:
>
>
> On Mon, Jun 29, 2015 at 9:55 AM, Andrew Cooper
> wrote:
>
>> On 29/06/15 14:42, Lengyel, Tamas wrote:
>>
>>
>>
>> > --- a/xen/arch/x86/hvm/hvm.c
>>> > +++ b/xen/arch
On Mon, Jun 29, 2015 at 9:55 AM, Andrew Cooper
wrote:
> On 29/06/15 14:42, Lengyel, Tamas wrote:
>
>
>
> > --- a/xen/arch/x86/hvm/hvm.c
>> > +++ b/xen/arch/x86/hvm/hvm.c
>> > @@ -6431,6 +6431,14 @@ int hvm_debug_op(struct vcpu *v, int32_t op)
>>
On Mon, Jun 29, 2015 at 9:35 AM, Andrew Cooper
wrote:
> On 29/06/15 13:58, Tamas K Lengyel wrote:
> > Add an option to the vm_event response to toggle singlestepping on the
> vCPU.
> >
> > Singed-off-by: Tamas K Lengyel
> > ---
> > MAINTAINERS| 1 +
> > xen/arch/x86/Makefil
On Thu, Jun 25, 2015 at 4:46 PM, Ed White wrote:
> On 06/25/2015 11:23 AM, Lengyel, Tamas wrote:
> > On Thu, Jun 25, 2015 at 12:48 PM, Ed White
> wrote:
> >
> >> On 06/25/2015 06:40 AM, Razvan Cojocaru wrote:
> >>> On 06/25/2015 03:44 PM, Lengyel, Tamas
On Thu, Jun 25, 2015 at 4:27 PM, Ed White wrote:
> On 06/25/2015 10:42 AM, Lengyel, Tamas wrote:
> > On Thu, Jun 25, 2015 at 12:31 PM, Ed White
> wrote:
> >
> >> On 06/24/2015 07:44 PM, Lengyel, Tamas wrote:
> >>>> +if ( altp2m
On Thu, Jun 25, 2015 at 12:48 PM, Ed White wrote:
> On 06/25/2015 06:40 AM, Razvan Cojocaru wrote:
> > On 06/25/2015 03:44 PM, Lengyel, Tamas wrote:
> >> On Wed, Jun 24, 2015 at 2:06 PM, Ed White >> <mailto:edmund.h.wh...@intel.com>> wrote:
> >> On
On Thu, Jun 25, 2015 at 12:31 PM, Ed White wrote:
> On 06/24/2015 07:44 PM, Lengyel, Tamas wrote:
> >> +if ( altp2m_active )
> >> +{
> >> +if ( altp2mhvm_hap_nested_page_fault(v, gpa, gla, npfec, &p2m)
> ==
> >> 1 )
> >>
On Thu, Jun 25, 2015 at 12:38 PM, Ed White wrote:
> On 06/25/2015 02:00 AM, Andrew Cooper wrote:
> > On 24/06/15 23:55, Ed White wrote:
> >> On 06/24/2015 03:45 PM, Lengyel, Tamas wrote:
> >>> On Wed, Jun 24, 2015 at 6:02 PM, Ed White
> wrote:
> >>>
On Wed, Jun 24, 2015 at 2:06 PM, Ed White wrote:
> On 06/24/2015 09:15 AM, Lengyel, Tamas wrote:
> >> +bool_t p2m_set_altp2m_mem_access(struct domain *d, uint16_t idx,
> >> + unsigned long pfn, xenmem_access_t
> >> access)
> >
On Mon, Jun 22, 2015 at 2:56 PM, Ed White wrote:
> Add the remaining routines required to support enabling the alternate
> p2m functionality.
>
> Signed-off-by: Ed White
> ---
> xen/arch/x86/hvm/hvm.c | 60 +-
> xen/arch/x86/mm/hap/Makefile| 1 +
> xen/arch/x86/mm/ha
On Wed, Jun 24, 2015 at 6:02 PM, Ed White wrote:
> On 06/24/2015 02:34 PM, Lengyel, Tamas wrote:
> > Hi Ed,
> > I tried the system using memsharing and I collected the following crash
> > log. In this test I ran memsharing on all pages of the domain before
> > activat
On Wed, Jun 24, 2015 at 12:43 PM, Ed White wrote:
> On 06/24/2015 06:37 AM, Razvan Cojocaru wrote:
> > On 06/24/2015 04:32 PM, Lengyel, Tamas wrote:
> >>
> >>
> >> On Wed, Jun 24, 2015 at 1:39 AM, Razvan Cojocaru
> >> mailto:rcojoc...@bitdefender.com&
On Mon, Jun 22, 2015 at 2:56 PM, Ed White wrote:
> Add the remaining routines required to support enabling the alternate
> p2m functionality.
>
> Signed-off-by: Ed White
> ---
> xen/arch/x86/hvm/hvm.c | 60 +-
> xen/arch/x86/mm/hap/Makefile| 1 +
> xen/arch/x86/mm/ha
On Mon, Jun 22, 2015 at 2:56 PM, Ed White wrote:
> Add a flag to indicate that a memory event occurred in an alternate p2m
> and a field containing the p2m index. Allow the response to switch to
> a different p2m using the same flag and field.
>
> Modify p2m_access_check() to handle alternate p2m
On Tue, Jun 23, 2015 at 9:22 AM, Tim Deegan wrote:
> Razvan and Tamas have been working on this code for a while now, and
> have kindly agreed to act as maintainers.
>
> Signed-off-by: Tim Deegan
> Cc: Razvan Cojocaru
> Cc: Tamas K Lengyel
> ---
> MAINTAINERS | 3 ++-
> 1 file changed, 2 inse
On Wed, Jun 24, 2015 at 1:39 AM, Razvan Cojocaru
wrote:
> On 06/24/2015 12:27 AM, Lengyel, Tamas wrote:
> > I've extended xen-access to exercise this new feature taking into
> > account some of the current limitations. Using the altp2m_write|exec
> > options we crea
> Testability is still a potential issue. We have offered to make our
> internal
> Windows test binaries available for intra-domain testing. Tamas has
> been working on toolstack support for cross-domain testing with a slightly
> earlier patch series, and we hope he will submit that support.
>
Hi
On Tue, Jun 23, 2015 at 2:52 PM, Ed White wrote:
> On 06/23/2015 11:15 AM, Lengyel, Tamas wrote:
> > On Mon, Jun 22, 2015 at 2:56 PM, Ed White
> wrote:
> >
> >> Add the remaining routines required to support enabling the alternate
> >> p2m functionalit
On Mon, Jun 22, 2015 at 2:56 PM, Ed White wrote:
> Add the remaining routines required to support enabling the alternate
> p2m functionality.
>
> Signed-off-by: Ed White
> ---
> xen/arch/x86/hvm/hvm.c | 60 +-
> xen/arch/x86/mm/hap/Makefile| 1 +
> xen/arch/x86/mm/ha
That's indeed sad. I'm actively using the sharing system in my tools and
have a couple branches laying around for improving it, like batch
memsharing for example to support flash-cloning. Now that it's orphaned,
how would I go about merging these into mainline? I'm not yet confident
enough in my un
On Thu, Jun 4, 2015 at 3:53 PM, Tim Deegan wrote:
> At 16:19 +0200 on 03 Jun (1433348379), Lengyel, Tamas wrote:
> > On Wed, Jun 3, 2015 at 3:48 PM, Razvan Cojocaru <
> rcojoc...@bitdefender.com>
> > wrote:
> > > On 06/03/2015 04:29 PM, Lengyel, Tam
On Wed, Jun 3, 2015 at 3:48 PM, Razvan Cojocaru
wrote:
> On 06/03/2015 04:29 PM, Lengyel, Tamas wrote:
> >
> >
> >
> > diff --git a/xen/include/asm-x86/domain.h
> b/xen/include/asm-x86/domain.h
> > index 45b5283..a3c117f 100644
> > --- a/xen/
> diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
> index 45b5283..a3c117f 100644
> --- a/xen/include/asm-x86/domain.h
> +++ b/xen/include/asm-x86/domain.h
> @@ -341,15 +341,9 @@ struct arch_domain
>
> /* Monitor options */
> struct {
> -uint16_t mov_to_cr
On Tue, May 26, 2015 at 5:49 PM, Ian Campbell
wrote:
> On Tue, 2015-05-26 at 17:38 +0200, Lengyel, Tamas wrote:
> > Hi all,
> >
> > I'm wondering if someone can point me in the right direction. I'm
> > trying to understand the process around domain save/r
On Thu, May 28, 2015 at 10:33 AM, Razvan Cojocaru wrote:
> On 05/28/2015 05:12 PM, Lengyel, Tamas wrote:
> > diff --git a/xen/arch/x86/hvm/event.c b/xen/arch/x86/hvm/event.c
> > index 9d5f9f3..a13195d 100644
> > --- a/xen/arch/x86/hvm/event.c
> > +++
diff --git a/xen/arch/x86/hvm/event.c b/xen/arch/x86/hvm/event.c
> index 9d5f9f3..a13195d 100644
> --- a/xen/arch/x86/hvm/event.c
> +++ b/xen/arch/x86/hvm/event.c
> @@ -21,6 +21,7 @@
>
> #include
> #include
> +#include
> #include
>
> static void hvm_event_fill_regs(vm_event_request_t *req)
Hi all,
I'm wondering if someone can point me in the right direction. I'm trying to
understand the process around domain save/restore using XL. I can see the
xl save format and how its appended with the QEMU state aquired via the
xen-save-devices-state qmp command (this is for upstream QEMU).
Howe
91 matches
Mail list logo
