Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1245843
| From | Christoffer Dall <christoffer.dall@linaro.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH 13/15] arm64: kvm: Rewrite fake pgd handling |
| Date | 2015-10-13 17:40 +0200 |
| Message-ID | <qj9Qe-2jW-19@gated-at.bofh.it> (permalink) |
| References | <q90Ex-Jd-5@gated-at.bofh.it> <q90Ez-Jd-53@gated-at.bofh.it> <qi3MR-44d-1@gated-at.bofh.it> <qiI3E-3Hd-9@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Mon, Oct 12, 2015 at 10:55:24AM +0100, Suzuki K. Poulose wrote: > On 10/10/15 15:52, Christoffer Dall wrote: > >Hi Suzuki, > > Hi Christoffer, > > Thanks for being patient enough to review the code :-) without much of > the comments. I now realise there needs much more documentation than > what I have put in already. I am taking care of this in the next > revision already. > > >I had to refresh my mind a fair bit to be able to review this, so I > >thought it may be useful to just remind us all what the constraints of > >this whole thing is, and make sure we agree on this: > > > >1. We fix the IPA max width to 40 bits > >2. We don't support systems with a PARange smaller than 40 bits (do we > > check this anywhere or document this anywhere?) > > AFAIT, no we don't check it anywhere. May be we should. We could plug this > into my CPU feature infrastructure[1] and let the is_hype_mode_available() > use the info to decide if we can support 40bit IPA ? > If we support 40bit IPA or more, yes, I think that would be sane. Or at least put a comment somewhere, perhaps in Documenation. > >3. We always assume we are running on a system with PARange of 40 bits > > and we are therefore constrained to use concatination. > > > >As an implication of (3) above, this code will attempt to allocate 256K > >of physically contiguous memory for each VM on the system. That is > >probably ok, but I just wanted to point it out in case it raises any > >eyebrows for other people following this thread. > > Right, I will document this in a comment. > > >>level: 0 1 2 3 > >>bits : [47] [46 - 36] [35 - 25] [24 - 14] [13 - 0] > >> ^ ^ ^ > >> | | | > >> host entry | x---- stage-2 entry > >> | > >> IPA -----x > > > >Isn't the stage-2 entry using bits [39:25], because you resolve > >more than 11 bits on the initial level of lookup when you concatenate > >tables? > > Yes, the stage-2 entry is just supposed to show the entry level (2). > I don't understand, the stage-2 entry level will be at bit 39, not 35? Thanks, -Christoffer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: [PATCH 13/15] arm64: kvm: Rewrite fake pgd handling Christoffer Dall <christoffer.dall@linaro.org> - 2015-10-10 17:00 +0200
Re: [PATCH 13/15] arm64: kvm: Rewrite fake pgd handling "Suzuki K. Poulose" <Suzuki.Poulose@arm.com> - 2015-10-12 12:00 +0200
Re: [PATCH 13/15] arm64: kvm: Rewrite fake pgd handling Christoffer Dall <christoffer.dall@linaro.org> - 2015-10-13 17:40 +0200
Re: [PATCH 13/15] arm64: kvm: Rewrite fake pgd handling "Suzuki K. Poulose" <Suzuki.Poulose@arm.com> - 2015-10-13 18:10 +0200
csiph-web