linux-kernel - Re: [PATCH v5 06/10] KVM: xen: allow shared

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 26 Sep 2023 10:22:07 +0100
From:   Paul Durrant <xadimgnik@...il.com>
To:     David Woodhouse <dwmw2@...radead.org>, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org
Cc:     Paul Durrant <pdurrant@...zon.com>,
        Sean Christopherson <seanjc@...gle.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "H. Peter Anvin" <hpa@...or.com>, x86@...nel.org
Subject: Re: [PATCH v5 06/10] KVM: xen: allow shared_info to be mapped by
 fixed HVA

On 23/09/2023 08:07, David Woodhouse wrote:
> On Fri, 2023-09-22 at 15:00 +0000, Paul Durrant wrote:
>> From: Paul Durrant <pdurrant@...zon.com>
>>
>> The shared_info page is not guest memory as such. It is a dedicated page
>> allocated by the VMM and overlaid onto guest memory in a GFN chosen by the
>> guest. The guest may even request that shared_info be moved from one GFN
>> to another, but the HVA is never going to change. Thus it makes much more
>> sense to map the shared_info page in kernel once using this fixed HVA.
> 
> The words "makes much more sense" are doing a *lot* of work there. :)
> 
> When heckling the cover letter in
> https://lore.kernel.org/kvm/d13e459e221f28fb1865eedea023e583a2277ab1.camel@infradead.org/
> I suggested that the explanation probably wants to make it into a
> commit message rather than just the cover letter which tends not to be
> preserved in the commit history. It's *this* commit which needs it, I
> think.

Ok, I'll try to come up with some concise wording.

   Paul