Re: [PATCH v10 21/45] x86/mm: Add support to validate memory when changing C-bit

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Feb 21, 2022 at 08:41:21PM +0300, Kirill A. Shutemov wrote:
> On Wed, Feb 16, 2022 at 10:04:57AM -0600, Brijesh Singh wrote:
> > @@ -287,6 +301,7 @@ struct x86_platform_ops {
> >  	struct x86_legacy_features legacy;
> >  	void (*set_legacy_features)(void);
> >  	struct x86_hyper_runtime hyper;
> > +	struct x86_guest guest;
> >  };
> 
> I used 'cc' instead of 'guest'. 'guest' looks too generic.

But guest is what is needed there. Not all cases where the kernel runs
as a guest are confidential ones.

Later, that hyperv thing should be merged into the guest one too as the
hyperv should be a guest too. AFAICT.

> Also, I'm not sure why not to use pointer to ops struct instead of stroing
> them directly in x86_platform. Yes, it is consistent with 'hyper', but I
> don't see it as a strong argument.

There should be no big difference but we're doing it with direct struct
member assignment so far so we should keep doing the same and not start
doing pointers now, all of a sudden.

> This doesn't cover difference in flushing requirements. Can we get it too?

What are the requirements you have for TDX on this path?

This is the main reason why I'm asking you to review this - I'd like to
have one version which works for both and then I'll queue it on a common
branch.

This is also why I'd like for you and SEV folks to agree on all the
common code so that I can apply it and you can both base your patchsets
ontop.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux