All of lore.kernel.org
 help / color / mirror / Atom feed
From: Don Slutz <dslutz@verizon.com>
To: George Dunlap <george.dunlap@eu.citrix.com>,
	Don Slutz <dslutz@verizon.com>,
	xen-devel@lists.xen.org
Cc: Kevin Tian <kevin.tian@intel.com>, Keir Fraser <keir@xen.org>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Jun Nakajima <jun.nakajima@intel.com>,
	Eddie Dong <eddie.dong@intel.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	Aravind Gopalakrishnan <Aravind.Gopalakrishnan@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Subject: Re: [PATCH for-4.5 v6 06/16] xen: Convert vmware_port to xentrace usage
Date: Wed, 24 Sep 2014 15:07:38 -0400	[thread overview]
Message-ID: <5423167A.1070901@terremark.com> (raw)
In-Reply-To: <5422FF1D.8000308@eu.citrix.com>


On 09/24/14 13:27, George Dunlap wrote:
> On 09/20/2014 07:07 PM, Don Slutz wrote:
>> Reduce the VMPORT_DBG_LOG calls.
>
> You should also have mentioned that you added hew HVMTRACE macros 
> which will log the TSC value.
>
> The reason the HVMTRACE macros don't log the TSC values is that for 
> the most part you can get all the timing information you need from the 
> TSC on the vmexit and vmenter.  Looking at where you've added the TSC 
> values, I don't really see how it adds anything except bloat to the 
> log.  Is there a reason you need to know exactly when these different 
> things happened, instead of just being able to bracket them between 
> VMENTER and VMEXITs?
>

I did want a way to know how long the VMware code was taking.  I am
not sure this is required.

For example:

CPU1  2899550319282 (+    4170)  VMEXIT      [ exitcode = 0x00000000, 
rIP  = 0x00007fad13ffec8c ]
CPU1  2899550320086 (+     804)  TRAP_GP     [ inst_len = 1 edx = 
0x00005658 exitinfo1 = 0x0000000000000000 exitinfo2 = 0x0000000000000000 ]
CPU1  2899550325054 (+    4968)  VMPORT_READ_BEFORE  [ eax = 0x564d5868 
ebx = 0x000001b3 ecx = 0x0003001e edx = 0x00005658 esi = 0x00000000 edi 
= 0x000001b3 ]
CPU1  2899550326050 (+     996)  VMPORT_READ_AFTER  [ eax = 0x564d5868 
ebx = 0x000001b3 ecx = 0x0001001e edx = 0x00005658 esi = 0x00000000 edi 
= 0x000001b3 ]
CPU1  2899550326722 (+     672)  vlapic_accept_pic_intr [ i8259_target = 
1, accept_pic_int = 0 ]
CPU1  2899550327454 (+     732)  VMENTRY


But I am happy to drop the new log TSC macros.




>>
>> Signed-off-by: Don Slutz <dslutz@verizon.com>
>> ---
>> v6:
>>        Dropped the attempt to use svm_nextrip_insn_length via
>>        __get_instruction_length (added in v2).  Just always look
>>        at upto 15 bytes on AMD.
>>
>> v5:
>>        exitinfo1 is used twice.
>>          Fixed.
>>
>>   xen/arch/x86/hvm/svm/svm.c       | 20 ++++++++++++++---
>>   xen/arch/x86/hvm/vmware/vmport.c | 48 
>> ++++++++++++++++++++++------------------
>>   xen/arch/x86/hvm/vmx/vmx.c       | 12 ++++++++++
>>   xen/include/asm-x86/hvm/trace.h  | 45 
>> +++++++++++++++++++++++++++++++++++++
>>   xen/include/asm-x86/hvm/vmport.h |  6 -----
>>   xen/include/public/trace.h       | 12 ++++++++++
>>   6 files changed, 113 insertions(+), 30 deletions(-)
>>
>> diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
>> index ea99dfb..716dda1 100644
>> --- a/xen/arch/x86/hvm/svm/svm.c
>> +++ b/xen/arch/x86/hvm/svm/svm.c
>> @@ -2081,10 +2081,18 @@ static void svm_vmexit_gp_intercept(struct 
>> cpu_user_regs *regs,
>>        */
>>       unsigned long inst_len = 15;
>>       unsigned long inst_addr = svm_rip2pointer(v);
>> -    int rc;
>> +    uint32_t starting_rdx = regs->rdx;
>> +    int rc = vmport_gp_check(regs, v, &inst_len, inst_addr,
>> +                             vmcb->exitinfo1, vmcb->exitinfo2);
>> +
>> +    if ( hvm_long_mode_enabled(v) )
>> +        HVMTRACE_LONG2_C4D(TRAP_GP, inst_len, starting_rdx,
>> +                           TRC_PAR_LONG(vmcb->exitinfo1),
>> +                           TRC_PAR_LONG(vmcb->exitinfo2));
>> +    else
>> +        HVMTRACE_C4D(TRAP_GP, inst_len, starting_rdx, vmcb->exitinfo1,
>> +                     vmcb->exitinfo2);
>>   -    rc = vmport_gp_check(regs, v, &inst_len, inst_addr,
>> -                         vmcb->exitinfo1, vmcb->exitinfo2);
>>       if ( !rc )
>>           __update_guest_eip(regs, inst_len);
>>       else
>> @@ -2097,6 +2105,12 @@ static void svm_vmexit_gp_intercept(struct 
>> cpu_user_regs *regs,
>>                          (unsigned long)vmcb->exitinfo2, 
>> regs->error_code,
>>                          regs->rip, inst_addr, inst_len, regs->rax, 
>> regs->rbx,
>>                          regs->rcx, regs->rdx, regs->rsi, regs->rdi);
>> +        if ( hvm_long_mode_enabled(v) )
>> +            HVMTRACE_LONG_C5D(TRAP_GP_UNKNOWN, rc, regs->rax, 
>> regs->rbx, regs->rcx,
>> +                              TRC_PAR_LONG(inst_addr));
>> +        else
>> +            HVMTRACE_C5D(TRAP_GP_UNKNOWN, rc, regs->rax, regs->rbx, 
>> regs->rcx,
>> +                         inst_addr);
>>           hvm_inject_hw_exception(TRAP_gp_fault, vmcb->exitinfo1);
>>       }
>>   }
>> diff --git a/xen/arch/x86/hvm/vmware/vmport.c 
>> b/xen/arch/x86/hvm/vmware/vmport.c
>> index 811c303..962ee32 100644
>> --- a/xen/arch/x86/hvm/vmware/vmport.c
>> +++ b/xen/arch/x86/hvm/vmware/vmport.c
>> @@ -18,6 +18,7 @@
>>   #include <asm/hvm/hvm.h>
>>   #include <asm/hvm/support.h>
>>   #include <asm/hvm/vmport.h>
>> +#include <asm/hvm/trace.h>
>>     #include "backdoor_def.h"
>>   #include "guest_msg_def.h"
>> @@ -66,12 +67,15 @@ int vmport_ioport(int dir, uint32_t port, 
>> uint32_t bytes, uint32_t *val)
>>           uint64_t saved_rax = regs->rax;
>>           uint64_t value;
>>   -        VMPORT_DBG_LOG(VMPORT_LOG_TRACE,
>> -                       "VMware trace dir=%d bytes=%u ip=%"PRIx64" 
>> cmd=%d ax=%"
>> -                       PRIx64" bx=%"PRIx64" cx=%"PRIx64" 
>> dx=%"PRIx64" si=%"
>> -                       PRIx64" di=%"PRIx64"\n", dir, bytes,
>> -                       regs->rip, cmd, regs->rax, regs->rbx, regs->rcx,
>> -                       regs->rdx, regs->rsi, regs->rdi);
>> +        if ( dir == IOREQ_READ )
>> +            HVMTRACE_ND(VMPORT_READ_BEFORE, 0, 1/*cycles*/, 6,
>> +                        regs->rax, regs->rbx, regs->rcx,
>> +                        regs->rdx, regs->rsi, regs->rdi);
>> +        else
>> +            HVMTRACE_ND(VMPORT_WRITE_AFTER_BEFORE, 0, 1/*cycles*/, 6,
>> +                        regs->rax, regs->rbx, regs->rcx,
>> +                        regs->rdx, regs->rsi, regs->rdi);
>
> Adding trace points in a separate patch is one thing, but adding code 
> like this and then removing it in a later patch is really poor form; 
> it could potentially make bisection difficult too, if (for example) 
> the output is so verbose in that short window as to make it unusable 
> between those changesets.
>
> I think you should go back to the previous patches and remove all the 
> VMPORT_DBG_LOG()s that don't survive until the end of the series.
>
> Unless, that is, you think that you might be making the case to accept 
> patches 1-5 for 4.5 without this patch; in which case it may make 
> sense to leave it the way it is.
>

That was a big part of it.  I can go and remove the excess.  At this
time I am expecting that 1-7 will make 4.5


> We normally don't log both BEFORE and AFTER states of things like 
> hypercalls -- just logging the outcome of what the hypervisor did 
> should be sufficient, shouldn't it?

Not that clear with this poorly build hyper-call.

> Do you really need to know the value of things that got clobbered?

When checking on the complex state machine that is the "RPC" code
it was very helpful.  With that code moving to QEMU, the before and
after is not so important.

Here is a real example:

CPU2  865821836508576 (+    2562)  VMEXIT      [ exitcode = 0x00000000, 
rIP  = 0x00007f68a8b17c8c ]
CPU2  865821836509362 (+     786)  TRAP_GP     [ inst_len = 1 edx = 
0x00025658 exitinfo1 = 0x0000000000000000 exitinfo2 = 0x0000000000000000 ]
CPU2  865821836514132 (+    4770)  VMPORT_READ_BEFORE  [ eax = 
0x564d5868 ebx = 0x00000034 ecx = 0x0002001e edx = 0x00025658 esi = 
0x00000000 edi = 0x000001be ]
CPU2  865821836597832 (+   83700)  VMPORT_READ_AFTER  [ eax = 0x564d5868 
ebx = 0x00000034 ecx = 0x0001001e edx = 0x00025658 esi = 0x00000000 edi 
= 0x000001be ]
CPU2  865821836598756 (+     924)  vlapic_accept_pic_intr [ i8259_target 
= 1, accept_pic_int = 0 ]
CPU2  865821836605602 (+    6846)  vlapic_accept_pic_intr [ i8259_target 
= 1, accept_pic_int = 0 ]
CPU2  865821836606436 (+     834)  VMENTRY
CPU2  865821836609712 (+    3276)  VMEXIT      [ exitcode = 0x00000000, 
rIP  = 0x00007f68a8b17c8c ]
CPU2  865821836610654 (+     942)  TRAP_GP     [ inst_len = 1 edx = 
0x00025658 exitinfo1 = 0x0000000000000000 exitinfo2 = 0x0000000000000000 ]
CPU2  865821836616828 (+    6174)  VMPORT_READ_BEFORE  [ eax = 
0x564d5868 ebx = 0x00000034 ecx = 0x0003001e edx = 0x00025658 esi = 
0x00000000 edi = 0x000001be ]
CPU2  865821836617800 (+     972)  VMPORT_READ_AFTER  [ eax = 0x564d5868 
ebx = 0x00000011 ecx = 0x0003001e edx = 0x00015658 esi = 0x00000000 edi 
= 0x000001be ]
CPU2  865821836618664 (+     864)  vlapic_accept_pic_intr [ i8259_target 
= 1, accept_pic_int = 0 ]
CPU2  865821836619444 (+     780)  VMENTRY

Note that in the one "RPC" call,


grep VMPORT_READ_BEFORE ~/zz-xentrace-vmware3-0.out | wc
    1592   39800  256312

It took 1592 #GP traps to handle it, and 9643628760 tsc cycles.

> You've got tracing in the error paths for when things don't go as you 
> expected.
>
> Also, same comment with the cycles: I don't see any value in logging 
> how long it took to get from the VMEXIT to here or from here to 
> anywhere else; it just makes the log really bloated.
>

Since you feel so strongly about this, I can drop it.


>> +
>>           switch ( cmd )
>>           {
>>           case BDOOR_CMD_GETMHZ:
>> @@ -143,19 +147,17 @@ int vmport_ioport(int dir, uint32_t port, 
>> uint32_t bytes, uint32_t *val)
>>               regs->rax = 0x0;
>>               break;
>>           default:
>> -            VMPORT_DBG_LOG(VMPORT_LOG_ERROR,
>> -                           "VMware bytes=%d dir=%d cmd=%d",
>> -                           bytes, dir, cmd);
>> +            HVMTRACE_ND(VMPORT_UNKNOWN, 0, 1/*cycles*/, 6,
>> +                        (bytes << 8) + dir, cmd, regs->rbx,
>> +                        regs->rcx, regs->rsi, regs->rdi);
>
> You do realize the maximum number of bytes you can log is 7, not 6, 
> right?  The macro stops at 6, but that's just where Keir got tired, I 
> think; if you want ot log more registers here you can extend it to 7.
>

Nope, that I did not know.  However the 1 additional 32bit value may
not be that helpful.

> Also, I think for clarity you should (bytes << 8) | dir rather than +dir.
>

Sure, will change.

>>               break;
>>           }
>> -        VMPORT_DBG_LOG(VMPORT_LOG_VMWARE_AFTER,
>> -                       "VMware after ip=%"PRIx64" cmd=%d 
>> ax=%"PRIx64" bx=%"
>> -                       PRIx64" cx=%"PRIx64" dx=%"PRIx64" 
>> si=%"PRIx64" di=%"
>> -                       PRIx64"\n",
>> -                       regs->rip, cmd, regs->rax, regs->rbx, regs->rcx,
>> -                       regs->rdx, regs->rsi, regs->rdi);
>> +
>>           if ( dir == IOREQ_READ )
>>           {
>> +            HVMTRACE_ND(VMPORT_READ_AFTER, 0, 1/*cycles*/, 6,
>> +                        regs->rax, regs->rbx, regs->rcx,
>> +                        regs->rdx, regs->rsi, regs->rdi);
>>               switch ( bytes )
>>               {
>>               case 1:
>> @@ -171,17 +173,21 @@ int vmport_ioport(int dir, uint32_t port, 
>> uint32_t bytes, uint32_t *val)
>>               *val = regs->rax;
>>           }
>>           else
>> +        {
>> +            HVMTRACE_ND(VMPORT_WRITE_AFTER, 0, 1/*cycles*/, 6,
>> +                        regs->rax, regs->rbx, regs->rcx,
>> +                        regs->rdx, regs->rsi, regs->rdi);
>>               regs->rax = saved_rax;
>> +        }
>>       }
>>       else
>>       {
>> +        if ( hvm_long_mode_enabled(current) )
>> +            HVMTRACE_LONG_C4D(VMPORT_BAD, dir, bytes, regs->rax,
>> +                              TRC_PAR_LONG(regs->rip));
>> +        else
>> +            HVMTRACE_C4D(VMPORT_BAD, dir, bytes, regs->rax, regs->rip);
>>           rc = X86EMUL_UNHANDLEABLE;
>> -        VMPORT_DBG_LOG(VMPORT_LOG_ERROR,
>> -                       "Not VMware %x vs %x; ip=%"PRIx64" ax=%"PRIx64
>> -                       " bx=%"PRIx64" cx=%"PRIx64" dx=%"PRIx64" 
>> si=%"PRIx64
>> -                       " di=%"PRIx64"",
>> -                       magic, BDOOR_MAGIC, regs->rip, regs->rax, 
>> regs->rbx,
>> -                       regs->rcx, regs->rdx, regs->rsi, regs->rdi);
>>       }
>>         return rc;
>> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
>> index 73f55f2..5395028 100644
>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> @@ -2613,6 +2613,12 @@ static void vmx_vmexit_gp_intercept(struct 
>> cpu_user_regs *regs,
>>       __vmread(VM_EXIT_INSTRUCTION_LEN, &inst_len);
>>       __vmread(VM_EXIT_INTR_ERROR_CODE, &ecode);
>>   +    if ( hvm_long_mode_enabled(v) )
>> +        HVMTRACE_LONG2_C4D(TRAP_GP, inst_len, regs->rdx, 
>> TRC_PAR_LONG(ecode),
>> +                           TRC_PAR_LONG(exit_qualification));
>> +    else
>> +        HVMTRACE_C4D(TRAP_GP, inst_len, regs->rdx, ecode, 
>> exit_qualification);
>
> Do you think anyone will need this 2 years from now?  That is, will 
> this actually be useful in understanding guest behavior, or is this 
> mostly to help you debug the hypervisor as you're developing it?
>

I can see a need for it.  I would hope that Intel (and AMD) would not
change the hardware so this info is needed, but I have seen this
happen in the past.

I would have no issue with making some of these compile time
conditional (like only in debug=y builds).




> I'd like to say more about my general theory for traces, but my brain 
> has about shut down... I'll send this so you can have the comments 
> I've got so far, and I'll come back to it tomorrow.
>
> Just one more thing...
>
>> +
>>   #ifndef NDEBUG
>>       orig_inst_len = inst_len;
>>   #endif
>> @@ -2636,6 +2642,12 @@ static void vmx_vmexit_gp_intercept(struct 
>> cpu_user_regs *regs,
>>                          regs->rip, inst_addr, orig_inst_len, inst_len,
>>                          regs->rax, regs->rbx, regs->rcx, regs->rdx, 
>> regs->rsi,
>>                          regs->rdi);
>> +        if ( hvm_long_mode_enabled(v) )
>> +            HVMTRACE_LONG_C5D(TRAP_GP_UNKNOWN, rc, regs->rax, 
>> regs->rbx, regs->rcx,
>> +                              TRC_PAR_LONG(inst_addr));
>> +        else
>> +            HVMTRACE_C5D(TRAP_GP_UNKNOWN, rc, regs->rax, regs->rbx, 
>> regs->rcx,
>> +                         inst_addr);
>>           hvm_inject_hw_exception(TRAP_gp_fault, ecode);
>>       }
>>   }
>> diff --git a/xen/include/asm-x86/hvm/trace.h 
>> b/xen/include/asm-x86/hvm/trace.h
>> index de802a6..8af2d6a 100644
>> --- a/xen/include/asm-x86/hvm/trace.h
>> +++ b/xen/include/asm-x86/hvm/trace.h
>> @@ -52,8 +52,20 @@
>>   #define DO_TRC_HVM_LMSW64      DEFAULT_HVM_MISC
>>   #define DO_TRC_HVM_REALMODE_EMULATE DEFAULT_HVM_MISC
>>   #define DO_TRC_HVM_TRAP             DEFAULT_HVM_MISC
>> +#define DO_TRC_HVM_TRAP64           DEFAULT_HVM_MISC
>>   #define DO_TRC_HVM_TRAP_DEBUG       DEFAULT_HVM_MISC
>>   #define DO_TRC_HVM_VLAPIC           DEFAULT_HVM_MISC
>> +#define DO_TRC_HVM_TRAP_GP          DEFAULT_HVM_MISC
>> +#define DO_TRC_HVM_TRAP_GP64        DEFAULT_HVM_MISC
>> +#define DO_TRC_HVM_TRAP_GP_UNKNOWN  DEFAULT_HVM_MISC
>> +#define DO_TRC_HVM_TRAP_GP_UNKNOWN64 DEFAULT_HVM_MISC
>> +#define DO_TRC_HVM_VMPORT_READ_BEFORE DEFAULT_HVM_IO
>> +#define DO_TRC_HVM_VMPORT_WRITE_AFTER_BEFORE DEFAULT_HVM_IO
>> +#define DO_TRC_HVM_VMPORT_READ_AFTER DEFAULT_HVM_IO
>> +#define DO_TRC_HVM_VMPORT_WRITE_AFTER DEFAULT_HVM_IO
>> +#define DO_TRC_HVM_VMPORT_BAD         DEFAULT_HVM_IO
>> +#define DO_TRC_HVM_VMPORT_BAD64       DEFAULT_HVM_IO
>> +#define DO_TRC_HVM_VMPORT_UNKNOWN     DEFAULT_HVM_IO
>>       #define TRC_PAR_LONG(par) ((par)&0xFFFFFFFF),((par)>>32)
>> @@ -98,6 +110,21 @@
>>   #define HVMTRACE_0D(evt)                            \
>>       HVMTRACE_ND(evt, 0, 0, 0,  0,  0,  0,  0,  0,  0)
>>   +#define HVMTRACE_C6D(evt, d1, d2, d3, d4, d5, d6)    \
>> +    HVMTRACE_ND(evt, 0, 1, 6, d1, d2, d3, d4, d5, d6)
>> +#define HVMTRACE_C5D(evt, d1, d2, d3, d4, d5)        \
>> +    HVMTRACE_ND(evt, 0, 1, 5, d1, d2, d3, d4, d5,  0)
>> +#define HVMTRACE_C4D(evt, d1, d2, d3, d4)            \
>> +    HVMTRACE_ND(evt, 0, 1, 4, d1, d2, d3, d4,  0,  0)
>> +#define HVMTRACE_C3D(evt, d1, d2, d3)                \
>> +    HVMTRACE_ND(evt, 0, 1, 3, d1, d2, d3,  0,  0,  0)
>> +#define HVMTRACE_C2D(evt, d1, d2)                    \
>> +    HVMTRACE_ND(evt, 0, 1, 2, d1, d2,  0,  0,  0,  0)
>> +#define HVMTRACE_C1D(evt, d1)                        \
>> +    HVMTRACE_ND(evt, 0, 1, 1, d1,  0,  0,  0,  0,  0)
>> +#define HVMTRACE_C0D(evt)                            \
>> +    HVMTRACE_ND(evt, 0, 1, 0,  0,  0,  0,  0,  0,  0)
>> +
>>   #define HVMTRACE_LONG_1D(evt, d1)                  \
>>                      HVMTRACE_2D(evt ## 64, (d1) & 0xFFFFFFFF, (d1) 
>> >> 32)
>>   #define HVMTRACE_LONG_2D(evt, d1, d2, ...)              \
>> @@ -107,6 +134,24 @@
>>   #define HVMTRACE_LONG_4D(evt, d1, d2, d3, d4, ...)  \
>>                      HVMTRACE_5D(evt ## 64, d1, d2, d3, d4)
>>   +#define HVMTRACE_LONG_C1D(evt, d1)                  \
>> +                   HVMTRACE_C2D(evt ## 64, (d1) & 0xFFFFFFFF, (d1) 
>> >> 32)
>> +#define HVMTRACE_LONG_C2D(evt, d1, d2, ...)              \
>> +                   HVMTRACE_C3D(evt ## 64, d1, d2)
>> +#define HVMTRACE_LONG_C3D(evt, d1, d2, d3, ...)      \
>> +                   HVMTRACE_C4D(evt ## 64, d1, d2, d3)
>> +#define HVMTRACE_LONG_C4D(evt, d1, d2, d3, d4, ...)  \
>> +                   HVMTRACE_C5D(evt ## 64, d1, d2, d3, d4)
>> +#define HVMTRACE_LONG_C5D(evt, d1, d2, d3, d4, d5, ...) \
>> +                   HVMTRACE_C6D(evt ## 64, d1, d2, d3, d4, d5)
>> +
>> +#define HVMTRACE_LONG2_C2D(evt, d1, d2, ...)              \
>> +                   HVMTRACE_C4D(evt ## 64, d1, d2)
>> +#define HVMTRACE_LONG2_C3D(evt, d1, d2, d3, ...)      \
>> +                   HVMTRACE_C5D(evt ## 64, d1, d2, d3)
>> +#define HVMTRACE_LONG2_C4D(evt, d1, d2, d3, d4, ...)  \
>> +                   HVMTRACE_C6D(evt ## 64, d1, d2, d3, d4)
>> +
>>   #endif /* __ASM_X86_HVM_TRACE_H__ */
>>     /*
>> diff --git a/xen/include/asm-x86/hvm/vmport.h 
>> b/xen/include/asm-x86/hvm/vmport.h
>> index c4f3926..401cbf4 100644
>> --- a/xen/include/asm-x86/hvm/vmport.h
>> +++ b/xen/include/asm-x86/hvm/vmport.h
>> @@ -25,12 +25,6 @@
>>   #define VMPORT_LOG_VGP_UNKNOWN     (1 << 3)
>>   #define VMPORT_LOG_REALMODE_GP     (1 << 4)
>>   -#define VMPORT_LOG_GP_NOT_VMWARE   (1 << 9)
>> -
>> -#define VMPORT_LOG_TRACE           (1 << 16)
>> -#define VMPORT_LOG_ERROR           (1 << 17)
>> -#define VMPORT_LOG_VMWARE_AFTER    (1 << 18)
>> -
>
> If you remove the debug statements in earlier patches, remember to 
> remove these as well.
>

Sure.

    -Don Slutz

>  -George
>

  reply	other threads:[~2014-09-24 19:07 UTC|newest]

Thread overview: 93+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-20 18:07 [PATCH for-4.5 v6 00/16] Xen VMware tools support Don Slutz
2014-09-20 18:07 ` [PATCH for-4.5 v6 01/16] xen: Add support for VMware cpuid leaves Don Slutz
2014-09-22 11:49   ` Andrew Cooper
2014-09-22 16:53     ` Don Slutz
2014-09-24 14:33   ` George Dunlap
2014-09-20 18:07 ` [PATCH for-4.5 v6 02/16] tools: Add vmware_hw support Don Slutz
2014-09-22 13:34   ` Ian Campbell
2014-09-22 22:08     ` Don Slutz
2014-09-24 14:44   ` George Dunlap
2014-09-24 21:06     ` Don Slutz
2014-09-20 18:07 ` [PATCH for-4.5 v6 03/16] vmware: Add VMware provided include files Don Slutz
2014-09-20 18:07 ` [PATCH for-4.5 v6 04/16] xen: Add vmware_port support Don Slutz
2014-09-23 17:16   ` Boris Ostrovsky
2014-09-24  8:28     ` Jan Beulich
2014-09-26 19:09     ` Don Slutz
2014-09-24 16:01   ` George Dunlap
2014-09-24 16:48     ` Don Slutz
2014-09-24 17:42       ` Andrew Cooper
2014-09-20 18:07 ` [PATCH for-4.5 v6 05/16] tools: " Don Slutz
2014-09-22 13:41   ` Ian Campbell
2014-09-22 16:34     ` Andrew Cooper
2014-09-22 21:22       ` Don Slutz
2014-09-24 16:24         ` George Dunlap
2014-09-24 18:25           ` Don Slutz
2014-09-22 16:42     ` Don Slutz
2014-09-23 12:20       ` Ian Campbell
2014-09-24 16:31         ` Don Slutz
2014-09-24 16:44           ` George Dunlap
2014-09-24 18:29             ` Don Slutz
2014-09-25 11:24           ` Ian Campbell
2014-09-25 14:17             ` George Dunlap
2014-09-25 14:21               ` Ian Campbell
2014-09-26 19:19             ` Don Slutz
2014-09-20 18:07 ` [PATCH for-4.5 v6 06/16] xen: Convert vmware_port to xentrace usage Don Slutz
2014-09-24 17:27   ` George Dunlap
2014-09-24 19:07     ` Don Slutz [this message]
2014-09-25 15:14       ` George Dunlap
2014-09-29 18:10         ` Don Slutz
2014-09-20 18:07 ` [PATCH for-4.5 v6 07/16] tools: " Don Slutz
2014-09-25 15:18   ` George Dunlap
2014-09-20 18:07 ` [PATCH for-4.5 v6 08/16] xen: Add limited support of VMware's hyper-call rpc Don Slutz
2014-09-22 13:47   ` Ian Campbell
2014-09-22 21:18     ` Don Slutz
2014-09-23 12:34       ` Ian Campbell
2014-09-23 22:03         ` Slutz, Donald Christopher
2014-09-25 16:28     ` George Dunlap
2014-09-20 18:07 ` [PATCH for-4.5 v6 09/16] tools: " Don Slutz
2014-09-22 13:52   ` Ian Campbell
2014-09-22 21:32     ` Don Slutz
2014-09-23 12:35       ` Ian Campbell
2014-09-20 18:07 ` [PATCH for-4.5 v6 10/16] Add VMware tool's triggers Don Slutz
2014-09-20 18:07 ` [PATCH for-4.5 v6 11/16] Add live migration of VMware's hyper-call RPC Don Slutz
2014-09-20 18:07 ` [PATCH for-4.5 v6 12/16] Add dump of HVM_SAVE_CODE(VMPORT) to xen-hvmctx Don Slutz
2014-09-20 18:07 ` [OPTIONAL][PATCH for-4.5 v6 13/16] Add xen-hvm-param Don Slutz
2014-09-20 18:07 ` [OPTIONAL][PATCH for-4.5 v6 14/16] Add xen-vmware-guestinfo Don Slutz
2014-09-20 18:07 ` [OPTIONAL][PATCH for-4.5 v6 15/16] Add xen-list-vmware-guestinfo Don Slutz
2014-09-20 18:07 ` [OPTIONAL][PATCH for-4.5 v6 16/16] Add xen-hvm-send-trigger Don Slutz
2014-09-22 13:56 ` [PATCH for-4.5 v6 00/16] Xen VMware tools support Ian Campbell
2014-09-22 15:19   ` George Dunlap
2014-09-22 15:34     ` Ian Campbell
2014-09-22 15:38       ` George Dunlap
2014-09-22 15:50         ` Ian Campbell
2014-09-22 15:55           ` George Dunlap
2014-09-22 17:19             ` Don Slutz
2014-09-22 22:00               ` Tian, Kevin
2014-09-23 12:30               ` Ian Campbell
2014-09-23 12:35                 ` George Dunlap
2014-09-23 12:40                   ` Ian Campbell
2014-09-24 15:52                 ` George Dunlap
2014-09-24 18:09                   ` Don Slutz
2014-09-24 17:19                 ` Don Slutz
2014-09-24 20:21                   ` Konrad Rzeszutek Wilk
2014-09-26 19:03                     ` Don Slutz
2014-09-26 19:28                       ` Konrad Rzeszutek Wilk
2014-09-25 11:35                   ` Ian Campbell
2014-09-22 16:18         ` Jan Beulich
2014-09-22 18:32           ` Don Slutz
2014-09-25 10:37           ` Tim Deegan
2014-09-26 20:00             ` Don Slutz
2014-09-29  6:50               ` Jan Beulich
2014-09-29 13:27                 ` George Dunlap
2014-09-29 13:49                   ` Jan Beulich
2014-09-29 23:13                   ` Don Slutz
2014-09-30  7:05                     ` Jan Beulich
2014-09-30 10:02                       ` George Dunlap
2014-09-30 22:11                         ` Slutz, Donald Christopher
2014-09-30 10:09                     ` George Dunlap
2014-09-30 22:23                       ` Slutz, Donald Christopher
2014-10-02 10:05               ` Tim Deegan
2014-10-02 19:20                 ` Don Slutz
2014-10-03  7:09                   ` Tim Deegan
2014-09-22 15:52       ` Andrew Cooper
2014-09-22 18:39         ` Don Slutz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5423167A.1070901@terremark.com \
    --to=dslutz@verizon.com \
    --cc=Aravind.Gopalakrishnan@amd.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=eddie.dong@intel.com \
    --cc=george.dunlap@eu.citrix.com \
    --cc=ian.campbell@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=jbeulich@suse.com \
    --cc=jun.nakajima@intel.com \
    --cc=keir@xen.org \
    --cc=kevin.tian@intel.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=tim@xen.org \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.