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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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.

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?

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?

Ian.


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