From: joel.schopp@amd.com (Joel Schopp)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5] arm64: fix VTTBR_BADDR_MASK
Date: Tue, 19 Aug 2014 10:16:12 -0500 [thread overview]
Message-ID: <53F36A3C.4060104@amd.com> (raw)
In-Reply-To: <20140819145933.GF31086@cbox>
> hmmm, the point is that we need to ensure that we have a properly
> aligned allocated PGD, that's what this patch currently addresses, and as
> you pointed out, the BUG_ON() just before trying to run a VM is not the
> nicest solution - we should really be dealing with this properly at
> allocation time.
>
> But, if you don't have time to look at that, then ok, I'll have to pick
> it up myself.
>
> However, you are hinting that we do not support 4 levels of page tables,
> yet you do allow the t0sz_to_vttbr_x funciton to pass even when using
> t0sz values only supported under 4 levels of page tables.... What is
> the rationale for that?
Minimizing merge conflicts. I figure both are going in within the next
month or two.
WARNING: multiple messages have this Message-ID (diff)
From: Joel Schopp <joel.schopp@amd.com>
To: Christoffer Dall <christoffer.dall@linaro.org>
Cc: <kvmarm@lists.cs.columbia.edu>,
<linux-arm-kernel@lists.infradead.org>, <kvm@vger.kernel.org>,
Sungjinn Chung <sungjinn.chung@samsung.com>,
Jungseok Lee <jays.lee@samsung.com>
Subject: Re: [PATCH v5] arm64: fix VTTBR_BADDR_MASK
Date: Tue, 19 Aug 2014 10:16:12 -0500 [thread overview]
Message-ID: <53F36A3C.4060104@amd.com> (raw)
In-Reply-To: <20140819145933.GF31086@cbox>
> hmmm, the point is that we need to ensure that we have a properly
> aligned allocated PGD, that's what this patch currently addresses, and as
> you pointed out, the BUG_ON() just before trying to run a VM is not the
> nicest solution - we should really be dealing with this properly at
> allocation time.
>
> But, if you don't have time to look at that, then ok, I'll have to pick
> it up myself.
>
> However, you are hinting that we do not support 4 levels of page tables,
> yet you do allow the t0sz_to_vttbr_x funciton to pass even when using
> t0sz values only supported under 4 levels of page tables.... What is
> the rationale for that?
Minimizing merge conflicts. I figure both are going in within the next
month or two.
next prev parent reply other threads:[~2014-08-19 15:16 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-18 20:36 [PATCH v5] arm64: fix VTTBR_BADDR_MASK Joel Schopp
2014-08-18 20:36 ` Joel Schopp
2014-08-19 12:24 ` Christoffer Dall
2014-08-19 12:24 ` Christoffer Dall
2014-08-19 14:23 ` Joel Schopp
2014-08-19 14:23 ` Joel Schopp
2014-08-19 14:38 ` Christoffer Dall
2014-08-19 14:38 ` Christoffer Dall
2014-08-19 14:49 ` Joel Schopp
2014-08-19 14:49 ` Joel Schopp
2014-08-19 14:59 ` Christoffer Dall
2014-08-19 14:59 ` Christoffer Dall
2014-08-19 15:16 ` Joel Schopp [this message]
2014-08-19 15:16 ` Joel Schopp
2014-08-26 17:02 ` Marc Zyngier
2014-08-26 17:02 ` Marc Zyngier
2014-08-26 18:35 ` Joel Schopp
2014-08-26 18:35 ` Joel Schopp
2014-08-29 10:06 ` Marc Zyngier
2014-08-29 10:06 ` Marc Zyngier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53F36A3C.4060104@amd.com \
--to=joel.schopp@amd.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.