[PATCH v12 00/20] KVM: xen: update shared_info and vcpu_info handling

Paul Durrant posted 20 patches 1 year, 11 months ago
There is a newer version of this series
Documentation/virt/kvm/api.rst                |  53 ++-
arch/x86/kvm/x86.c                            |   7 +-
arch/x86/kvm/xen.c                            | 356 +++++++++++-------
include/linux/kvm_host.h                      |  40 +-
include/linux/kvm_types.h                     |   8 -
include/uapi/linux/kvm.h                      |   9 +-
.../selftests/kvm/x86_64/xen_shinfo_test.c    |  59 ++-
virt/kvm/pfncache.c                           | 340 +++++++++--------
8 files changed, 535 insertions(+), 337 deletions(-)
[PATCH v12 00/20] KVM: xen: update shared_info and vcpu_info handling
Posted by Paul Durrant 1 year, 11 months ago
From: Paul Durrant <pdurrant@amazon.com>

This series has one small fix to what was in v11 [1]:

* KVM: xen: re-initialize shared_info if guest (32/64-bit) mode is set

The v11 patch failed to set the return code of the ioctl if the mode
was not actually changed, leading to a spurious failure.

This version of the series also contains a new bug-fix to the pfncache
code from David Woodhouse.

[1] https://lore.kernel.org/kvm/20231219161109.1318-1-paul@xen.org/

David Woodhouse (1):
  KVM: pfncache: rework __kvm_gpc_refresh() to fix locking issues

Paul Durrant (19):
  KVM: pfncache: Add a map helper function
  KVM: pfncache: remove unnecessary exports
  KVM: xen: mark guest pages dirty with the pfncache lock held
  KVM: pfncache: add a mark-dirty helper
  KVM: pfncache: remove KVM_GUEST_USES_PFN usage
  KVM: pfncache: stop open-coding offset_in_page()
  KVM: pfncache: include page offset in uhva and use it consistently
  KVM: pfncache: allow a cache to be activated with a fixed (userspace)
    HVA
  KVM: xen: separate initialization of shared_info cache and content
  KVM: xen: re-initialize shared_info if guest (32/64-bit) mode is set
  KVM: xen: allow shared_info to be mapped by fixed HVA
  KVM: xen: allow vcpu_info to be mapped by fixed HVA
  KVM: selftests / xen: map shared_info using HVA rather than GFN
  KVM: selftests / xen: re-map vcpu_info using HVA rather than GPA
  KVM: xen: advertize the KVM_XEN_HVM_CONFIG_SHARED_INFO_HVA capability
  KVM: xen: split up kvm_xen_set_evtchn_fast()
  KVM: xen: don't block on pfncache locks in kvm_xen_set_evtchn_fast()
  KVM: pfncache: check the need for invalidation under read lock first
  KVM: xen: allow vcpu_info content to be 'safely' copied

 Documentation/virt/kvm/api.rst                |  53 ++-
 arch/x86/kvm/x86.c                            |   7 +-
 arch/x86/kvm/xen.c                            | 356 +++++++++++-------
 include/linux/kvm_host.h                      |  40 +-
 include/linux/kvm_types.h                     |   8 -
 include/uapi/linux/kvm.h                      |   9 +-
 .../selftests/kvm/x86_64/xen_shinfo_test.c    |  59 ++-
 virt/kvm/pfncache.c                           | 340 +++++++++--------
 8 files changed, 535 insertions(+), 337 deletions(-)


base-commit: 1c6d984f523f67ecfad1083bb04c55d91977bb15
-- 
2.39.2
Re: [PATCH v12 00/20] KVM: xen: update shared_info and vcpu_info handling
Posted by Paul Durrant 1 year, 11 months ago
On 15/01/2024 12:56, Paul Durrant wrote:
> From: Paul Durrant <pdurrant@amazon.com>
> 
> This series has one small fix to what was in v11 [1]:
> 
> * KVM: xen: re-initialize shared_info if guest (32/64-bit) mode is set
> 
> The v11 patch failed to set the return code of the ioctl if the mode
> was not actually changed, leading to a spurious failure.
> 
> This version of the series also contains a new bug-fix to the pfncache
> code from David Woodhouse.
> 
> [1] https://lore.kernel.org/kvm/20231219161109.1318-1-paul@xen.org/
> 

Ping?
Re: [PATCH v12 00/20] KVM: xen: update shared_info and vcpu_info handling
Posted by Sean Christopherson 1 year, 11 months ago
On Thu, Jan 25, 2024, Paul Durrant wrote:
> On 15/01/2024 12:56, Paul Durrant wrote:
> > From: Paul Durrant <pdurrant@amazon.com>
> > 
> > This series has one small fix to what was in v11 [1]:
> > 
> > * KVM: xen: re-initialize shared_info if guest (32/64-bit) mode is set
> > 
> > The v11 patch failed to set the return code of the ioctl if the mode
> > was not actually changed, leading to a spurious failure.
> > 
> > This version of the series also contains a new bug-fix to the pfncache
> > code from David Woodhouse.
> > 
> > [1] https://lore.kernel.org/kvm/20231219161109.1318-1-paul@xen.org/
> > 
> 
> Ping?

Sorry, I have done basically zero upstream reviews over the last few weeks, for
a variety of reasons.  Unless yet another thing pops up, I expect to dive into
upstream reviews tomorrow and spend a good long while there.
Re: [PATCH v12 00/20] KVM: xen: update shared_info and vcpu_info handling
Posted by Paul Durrant 1 year, 10 months ago
On 26/01/2024 01:19, Sean Christopherson wrote:
> On Thu, Jan 25, 2024, Paul Durrant wrote:
>> On 15/01/2024 12:56, Paul Durrant wrote:
>>> From: Paul Durrant <pdurrant@amazon.com>
>>>
>>> This series has one small fix to what was in v11 [1]:
>>>
>>> * KVM: xen: re-initialize shared_info if guest (32/64-bit) mode is set
>>>
>>> The v11 patch failed to set the return code of the ioctl if the mode
>>> was not actually changed, leading to a spurious failure.
>>>
>>> This version of the series also contains a new bug-fix to the pfncache
>>> code from David Woodhouse.
>>>
>>> [1] https://lore.kernel.org/kvm/20231219161109.1318-1-paul@xen.org/
>>>
>>
>> Ping?
> 
> Sorry, I have done basically zero upstream reviews over the last few weeks, for
> a variety of reasons.  Unless yet another thing pops up, I expect to dive into
> upstream reviews tomorrow and spend a good long while there.

Hi Sean,

   Have you had any time to take a look at this?

   Paul
Re: [PATCH v12 00/20] KVM: xen: update shared_info and vcpu_info handling
Posted by Sean Christopherson 1 year, 10 months ago
On Fri, Feb 02, 2024, Paul Durrant wrote:
> On 26/01/2024 01:19, Sean Christopherson wrote:
> > On Thu, Jan 25, 2024, Paul Durrant wrote:
> > > On 15/01/2024 12:56, Paul Durrant wrote:
> > > > From: Paul Durrant <pdurrant@amazon.com>
> > > > 
> > > > This series has one small fix to what was in v11 [1]:
> > > > 
> > > > * KVM: xen: re-initialize shared_info if guest (32/64-bit) mode is set
> > > > 
> > > > The v11 patch failed to set the return code of the ioctl if the mode
> > > > was not actually changed, leading to a spurious failure.
> > > > 
> > > > This version of the series also contains a new bug-fix to the pfncache
> > > > code from David Woodhouse.
> > > > 
> > > > [1] https://lore.kernel.org/kvm/20231219161109.1318-1-paul@xen.org/
> > > > 
> > > 
> > > Ping?
> > 
> > Sorry, I have done basically zero upstream reviews over the last few weeks, for
> > a variety of reasons.  Unless yet another thing pops up, I expect to dive into
> > upstream reviews tomorrow and spend a good long while there.
> 
> Hi Sean,
> 
>   Have you had any time to take a look at this?

No, I was hoping to get to it today, but that isn't happening.  It's next in my
queue after David Steven's "KVM: allow mapping non-refcounted pages" serie", so
hopefully Monday or Tuesday will be the day.
Re: [PATCH v12 00/20] KVM: xen: update shared_info and vcpu_info handling
Posted by David Woodhouse 1 year, 11 months ago
On Thu, 2024-01-25 at 15:03 +0000, Paul Durrant wrote:
> On 15/01/2024 12:56, Paul Durrant wrote:
> > From: Paul Durrant <pdurrant@amazon.com>
> > 
> > This series has one small fix to what was in v11 [1]:
> > 
> > * KVM: xen: re-initialize shared_info if guest (32/64-bit) mode is set
> > 
> > The v11 patch failed to set the return code of the ioctl if the mode
> > was not actually changed, leading to a spurious failure.
> > 
> > This version of the series also contains a new bug-fix to the pfncache
> > code from David Woodhouse.
> > 
> > [1] https://lore.kernel.org/kvm/20231219161109.1318-1-paul@xen.org/
> > 
> 
> Ping?
> 

I think it's only the final patch which is controversial, isn't it? We
can drop that for now and I can submit it under separate cover. 

It'll be basically the same patch, just won't claim to be a bug fix:
https://lore.kernel.org/kvm/6dc0e9d1f5db41a053b734b29403ad48c288dea3.camel@infradead.org/

Although I'll eat my hat if that "should never happen" bug actually
does keep happening after the locking is less baroque.