From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoffer Dall Subject: Re: [RFC 07/55] KVM: arm/arm64: Add virtual EL2 state emulation framework Date: Fri, 2 Jun 2017 23:15:06 +0200 Message-ID: <20170602211506.GA7654@cbox> References: <1483943091-1364-1-git-send-email-jintack@cs.columbia.edu> <1483943091-1364-8-git-send-email-jintack@cs.columbia.edu> <20170602115140.GB397@cbox> <20170602190622.GF397@cbox> <20170602194353.GG397@cbox> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kvm@vger.kernel.org To: Bandan Das Return-path: Received: from mail-wm0-f43.google.com ([74.125.82.43]:35576 "EHLO mail-wm0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750966AbdFBVPV (ORCPT ); Fri, 2 Jun 2017 17:15:21 -0400 Received: by mail-wm0-f43.google.com with SMTP id b84so34367811wmh.0 for ; Fri, 02 Jun 2017 14:15:20 -0700 (PDT) Content-Disposition: inline In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On Fri, Jun 02, 2017 at 04:18:08PM -0400, Bandan Das wrote: > Christoffer Dall writes: > > > [off list] > > Please keep discussions on list. > ... > > No, it's actually not. You can have entries, which are the same, and > > entire tables where the guest's page table happen to be the same as what > > gets put in the shadow page table. I've worked on hypervisors where > > this was always pretty much the case, because memory was segmented and > > physical addresses were exposed to the guest. > > Ok cool, I believe you! > > > I don't need a lecture from you about how shadow page tables work. > > > > Go back to the review I posted. I merely asked if using "shadow" in the name could > be confusing And that was just fine. > > Nevertheless, I was just trying to explain our rationale for choosing > > the word shadow in our naming, and I suggest in the future you make > > constructive comments with suggesting a better name, instead of pointing > > out your dissatiscation, which is not helpful. > > [...] > > > > I've lost track of what you're refering to. If there is a problem with > > these patches, please comment on that in the right context. But, this > > is an RFC, lots of things will change, and you would provide a more > > helpful code review by focusing on overall design issues etc. at this > > point. > > I know this is a RFC. Changes to RFC include small changes too like > being consistent with using one type or the other. I just didn't want you to waste time on reviewing details thay may change, prematurely, that's all. And I honestly didn't know what you were referring to, and didn't want to go over a very large RFC patch set to find a typedef or missing typedef. Maybe I should have. > If you don't want that > in your reviews, that's fine too. > Anyone can comment on anything they like in a review. > > >> As for the argument, typedefs for structs are > >> discouraged as part of the coding style. > >> > > Please... > > > > I encourage you to consider your audience. I don't think you > > need to lecture me on the Linux kernel coding style. > > I encourage you too to take a review as a review and not as a judgement of your > knowledge of the coding style or other abilities. You are discouraging people > from jumping in. > That was not my intention. > > I started discussing with Jintack and reviewing this series so that I can understand > it better. If I have to constantly think that with every sentence I write I am judging > someone's abilities, or that I have to follow someone's rulebook for constructive comments, > well, thanks and good luck! What can I say. I of course don't have a rulebook. I did not find your tone friendly or the review particularly helpful, but I'll try to be more patient next time. -Christoffer