From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47428) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g8MS0-0001qa-AS for qemu-devel@nongnu.org; Fri, 05 Oct 2018 05:31:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g8MFP-0003EB-9I for qemu-devel@nongnu.org; Fri, 05 Oct 2018 05:18:12 -0400 Received: from mail-ot1-x341.google.com ([2607:f8b0:4864:20::341]:44501) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1g8MFP-0003Dw-4p for qemu-devel@nongnu.org; Fri, 05 Oct 2018 05:18:11 -0400 Received: by mail-ot1-x341.google.com with SMTP id p23so391032otf.11 for ; Fri, 05 Oct 2018 02:18:11 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20181005084835.GB2285@work-vm> References: <20181004150522.sr2woe74vdlpo52k@kamzik.brq.redhat.com> <20181005084835.GB2285@work-vm> From: Peter Maydell Date: Fri, 5 Oct 2018 10:17:50 +0100 Message-ID: Content-Type: text/plain; charset="UTF-8" Subject: Re: [Qemu-devel] [RFC] [PATCH 0/3] qemu: arm: Migration between machines with different MIDR values List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Dr. David Alan Gilbert" Cc: Andrew Jones , mjaggi@caviumnetworks.com, "Nair, Jayachandran" , "quintela@redhat.com" , "qemu-devel@nongnu.org" , "eric.auger@redhat.com" , "Jaggi, Manish" , "Nowicki, Tomasz" On 5 October 2018 at 09:48, Dr. David Alan Gilbert wrote: > * Peter Maydell (peter.maydell@linaro.org) wrote: >> On 4 October 2018 at 16:05, Andrew Jones wrote: >> > On Tue, Oct 02, 2018 at 02:07:38PM +0100, Peter Maydell wrote: >> >> Hi; thanks for this patch. The issue I see with this patch >> >> is that the KVM/ARM QEMU approach to system registers so far >> >> has been "the kernel knows about these and it is in control". >> >> So we ask the kernel for the list of registers, and just save >> >> and restore those. That would suggest that if there are sysregs >> >> where it's OK in fact to ignore a difference between two constant >> >> register values, it should be the kernel doing the "actually, this >> >> mismatch is OK" behaviour... >> > >> > I don't think the kernel should have to maintain all that logic. If a user >> > wants to load guest registers, then the kernel should do it, as long as >> > it's safe from the host's integrity/security PoV, and the hardware would >> > actually support it. Anything that can only break the guest, but not the >> > host, should be allowed. The KVM userspace can certainly ask the kernel >> > what it recommends first (i.e. read the invariant registers first, before >> > deciding what to write), but the decision of what to write should be left >> > up to the user. >> >> I can see the logic of that approach. But right now QEMU >> userspace knows basically nothing about the system registers >> when we're using KVM: all that knowledge is in the kernel. >> So we don't have a place really to put policy info (and >> not really anywhere to put policy info that depends on the >> host CPU type when mostly we let the kernel care about that). > > It would seem wrong to put this logic in the kernel because the > priviliged code should be as small as possible. Agreed. But if we want to move to "QEMU knows about all the possible host CPUs" that's a fair-sized design change and needs more than the minimalist approach this patch has. thanks -- PMM