Re: [PATCH v4 2/5] KVM: X86: Expose PKS to guest

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

 



On 05/02/21 12:29, Thomas Gleixner wrote:
On Fri, Feb 05 2021 at 11:10, Paolo Bonzini wrote:
On 05/02/21 10:56, Borislav Petkov wrote:
This would need an ack from the x86 people.  Andy, Boris?

This looks like the PKS baremetal pile needs to be upstream first.

Yes, it does.  I would like to have an ack for including the above two
hunks once PKS is upstream.

I also have CET and bus lock #DB queued and waiting for the bare metal
functionality, however they do not touch anything outside arch/x86/kvm.

What's the exact point of queueing random stuff which lacks bare metal
support?

The code is often completely independent of bare metal support even if it depends of it (CET and bus lock for example only share the #defines; for PKS this is not the case just because Intel decided not to use XSAVES *shrug*).

I prefer to queue early, because it keeps my backlog small and because every resend comes with the risk of random changes sneaking in since the version that I reviewed. An early ack would also mean that I don't have to bug you in the middle of the merge window. But it's not a problem, I'll ask for acks again once PKS is merged into tip.

Thanks,

Paolo

Once PKS, CET or whatever is merged into tip then it's the point for
resending the KVM patches for inclusion and that's the point where it
gets acked and not $N month ahead when everything is still in flux.




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux