From mboxrd@z Thu Jan 1 00:00:00 1970 From: Don Slutz Subject: Re: [PATCH v5 13/17] xenctx: Add convert of more registers to symbols Date: Thu, 27 Mar 2014 12:52:45 -0400 Message-ID: <5334575D.3070506@terremark.com> References: <1395342425-16260-1-git-send-email-dslutz@verizon.com> <1395342425-16260-14-git-send-email-dslutz@verizon.com> <1395414424.19839.134.camel@kazak.uk.xensource.com> <532C56B602000078000AF422@nat28.tlf.novell.com> <1395417977.19839.166.camel@kazak.uk.xensource.com> <532C81EB.3050605@terremark.com> <1395658181.19365.40.camel@kazak.uk.xensource.com> <53303C8F.8090200@terremark.com> <1395936391.22909.176.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1395936391.22909.176.camel@kazak.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell , Don Slutz Cc: George Dunlap , xen-devel@lists.xen.org, Ian Jackson , Jan Beulich , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org 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 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. >