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
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 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 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
> 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 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
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 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 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 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 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 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 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 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 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: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 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 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 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 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 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 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
> >
>> --- 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;
> >> -
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_
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 {
> >> >>
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 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:
> >> >
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: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
@@ -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
> 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)
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
> >>
>
> 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-
> 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
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
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 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 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 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 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: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: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
> > 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 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:
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
>
> 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 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
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 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 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
>
> 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 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(+)
> >
>
> 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 */
>
> @@ -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
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
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
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)
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
> > +++
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
> 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 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/
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
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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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
> 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 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 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
91 matches
Mail list logo
