[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/27/14 12:06, Ian Campbell wrote:
On Mon, 2014-03-24 at 10:09 -0400, Don Slutz wrote:
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.
I was saying that I could not find a call to print_special where all
members of reg_is_addr_mask were not either 0 or ~0ULL and then you
starting talking about kdb + 2.6.18 kernels.

I did get off track, sorry about that.

Have I missed a call to print_special with a mask value of something
other than 0 or ~0ULL somewhere in this patch or perhaps a subsequent
patch?

Not that I know of.

If I haven't missed it because it doesn't actually exist then
reg_is_addr_mask could be replaced by a bitmask, or maybe the
theoretical possibility of printing out a special register which does
need masking makes it worthwhile to keep this functionality, or maybe it
should be put aside until a patch which adds the printing of such a
register.

[...]
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.
So in the end there are no special registers which have a symbol printed
and which have any bits to mask?

Yes.  I am happy to go either way.  Since I am putting the finishing
comments on the next version (v8) of all these, for now I will continue
with Jan's requested way (mask values of 0 or ~0ULL ).

   -Don Slutz
Ian.



_______________________________________________
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®.