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

[Don Slutz <dslutz@verizon.com>]

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@citrix.com> 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.
>