[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v5 13/17] xenctx: Add convert of more registers to symbols



On 03/24/14 06:49, Ian Campbell wrote:
On Fri, 2014-03-21 at 14:16 -0400, Don Slutz wrote:
On 03/21/14 12:06, Ian Campbell wrote:
On Fri, 2014-03-21 at 15:11 +0000, Jan Beulich wrote:
On 21.03.14 at 16:07, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
On Thu, 2014-03-20 at 15:07 -0400, Don Slutz wrote:

@@ -368,8 +380,11 @@ static void print_ctx_32(vcpu_guest_context_x86_32_t *ctx)
       printf(" gs:     %04x\n", regs->gs);
if (xenctx.disp_all) {
-        print_special(ctx->ctrlreg, "cr", 0x1d, 4);
-        print_special(ctx->debugreg, "dr", 0xcf, 4);
+        uint64_t cr_reg_mask[5] = {0, 0, ~0ULL};
+        uint64_t dr_reg_mask[8] = {~0ULL, ~0ULL, ~0ULL, ~0ULL};
Are you really using 8*64 bits to represent 8 boolean values? Your masks
are all 0 or ~0.
Actually I had asked for this, since special registers may happen to have
(often at their bottom or top) bits not being part of an address.
I thought that might be the case, but I couldn't find any actual
printing of such a register.

Ian.

Getting a kernel value there is not simple.  Using a kdb + 2.6.18
kernel, I got:
I'm afraid I cannot follow what this has to do with the previous
exchange.

Ian.


Re-reading it, I see that you may have been referring to some
register that is not cr0, cr2, cr3, cr4, dr0, dr1, dr2, dr3, dr6, and
dr7.

If that is the case, my reply does not make sense. However CR3
is an example.  Intel and AMD say:


Bits 51:40 of CR3 are reserved and must be 0 (intel).

All CR3 bits are writable, except for unimplemented physical address
bits, which must be cleared to 0 (AMD).


PCD
Page-level Cache Disable (bit 4 of CR3) Â

PWT Page-level Write-Through (bit 3 of CR3) Â

So CR3 looks to be a register of the type in question.  How ever, since it has a
physical address and the map file is all virtual addresses, I used a 0 so a 
false
match would not happen.

Let me know if more is needed.

   -Don Slutz







_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.