On Tue, 2024-06-04 at 12:34 -0700, Sean Christopherson wrote:
>
> If we're willing to suffer a few gnarly macros, I think we get a satisfactory
> mix
> of standardized arguments and explicit operands, and generate vastly better
> code.
Hi Sean,
We are kind of stuck on improving the code generati
On Sat, 2024-07-27 at 00:33 -0500, Dan Carpenter wrote:
> Commit 211f514ebf1e ("Drivers: hv: vmbus: Track decrypted status in
> vmbus_gpadl") from Mar 11, 2024 (linux-next), leads to the following
> Smatch static checker warning:
>
> drivers/hv/channel.c:870 vmbus_teardown_gpadl()
>
On Wed, 2024-04-10 at 21:34 +, Wei Liu wrote:
>
> Applied to hyperv-fixes. Thanks.
Thanks, and thanks to Michael for getting it across the finish line.
On Thu, 2024-03-07 at 17:11 +, Michael Kelley wrote:
> Using your patches plus the changes in my comments, I've
> done most of the testing described above. The normal
> paths work, and when I hack set_memory_encrypted()
> to fail, the error paths correctly did not free the memory.
> I checked b
On Fri, 2024-03-01 at 20:21 +, Michael Kelley wrote:
>
> The Hyper-V case can actually be a third path when a paravisor
> is being used. In that case, for both TDX and SEV-SNP, the
> hypervisor callbacks in __set_memory_enc_pgtable() go
> to Hyper-V specific functions that talk to the paravis
On Fri, 2024-03-01 at 19:00 +, Michael Kelley wrote:
> From: Rick Edgecombe Sent: Wednesday,
> February 21, 2024 6:10 PM
> >
>
> Historically, the preferred Subject prefix for changes to
> connection.c has
> been "Drivers: hv: vmbus:", not just "hv:". Sometimes that
> preference
> isn't fol
On Fri, 2024-03-01 at 09:26 +, Wei Liu wrote:
> > Hyperv could free decrypted/shared pages if set_memory_encrypted()
> > fails.
>
> "Hyper-V" throughout.
Ok.
>
> > Leak the pages if this happens.
> >
> > Only compile tested.
> >
> > Cc: "K. Y. Srinivasan"
> > Cc: Haiyang Zhang
> > Cc: W
On Fri, 2024-01-12 at 15:07 +, Michael Kelley wrote:
> The comment is Kirill Shutemov's suggestion based on comments in
> an earlier version of the patch series. See [1]. The intent is to
> prevent
> some later revision to slow_virt_to_phys() from adding a check for
> the
> present bit and b
On Fri, 2024-01-05 at 10:30 -0800, mhkelle...@gmail.com wrote:
> + * It is also used in callbacks for CoCo VM page transitions between
> private
> + * and shared because it works when the PRESENT bit is not set in
> the leaf
> + * PTE. In such cases, the state of the PTEs, including the PFN, is
> o
On Fri, 2024-01-05 at 10:30 -0800, mhkelle...@gmail.com wrote:
> From: Michael Kelley
>
> set_memory_p() is currently static. It has parameters that don't
> match set_memory_p() under arch/powerpc and that aren't congruent
> with the other set_memory_* functions. There's no good reason for
> the
On Fri, 2024-01-05 at 10:30 -0800, mhkelle...@gmail.com wrote:
> * hv_vtom_set_host_visibility - Set specified memory visible to
> host.
> *
> @@ -521,7 +547,7 @@ static bool hv_vtom_set_host_visibility(unsigned
> long kbuffer, int pagecount, bo
>
> pfn_array = kmalloc(HV_HYP_PAGE_SIZ
On Tue, 2023-11-28 at 18:08 +, Michael Kelley wrote:
> >
> > Sort of separately, if those vmalloc objections can't be worked
> > through, did you consider doing something like text_poke() does
> > (create
> > the temporary mapping in a temporary MM) for pvalidate purposes? I
> > don't know eno
On Tue, 2023-11-21 at 13:20 -0800, mhkelle...@gmail.com wrote:
> --- a/arch/x86/mm/pat/set_memory.c
> +++ b/arch/x86/mm/pat/set_memory.c
> @@ -1636,7 +1636,10 @@ static int __change_page_attr(struct cpa_data
> *cpa, int primary)
> */
> if (pte_val(old_pte) != pte_va
On Tue, 2023-11-21 at 13:20 -0800, mhkelle...@gmail.com wrote:
> +static int pvalidate_pfn(unsigned long vaddr, unsigned int size,
> + unsigned long pfn, bool validate, int *rc2)
> +{
> + int rc;
> + struct page *page = pfn_to_page(pfn);
> +
> + *rc2 = vmap_
16 matches
Mail list logo
