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

[Don Slutz <dslutz@xxxxxxxxxxx>]

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