On Mon, Aug 17, 2020 at 09:32:07AM -0700, Sean Christopherson wrote:
> On Fri, Aug 14, 2020 at 10:30:14AM -0400, Michael S. Tsirkin wrote:
> > On Thu, Aug 13, 2020 at 07:31:39PM -0700, Sean Christopherson wrote:
> > > > @@ -2318,6 +2338,11 @@ static int __kvm_read_guest_page(struct kvm_memory_slot *slot, gfn_t gfn,
> > > > int r;
> > > > unsigned long addr;
> > > >
> > > > + if (unlikely(slot && (slot->flags & KVM_MEM_PCI_HOLE))) {
> > > > + memset(data, 0xff, len);
> > > > + return 0;
> > > > + }
> > >
> > > This feels wrong, shouldn't we be treating PCI_HOLE as MMIO? Given that
> > > this is performance oriented, I would think we'd want to leverage the
> > > GPA from the VMCS instead of doing a full translation.
> > >
> > > That brings up a potential alternative to adding a memslot flag. What if
> > > we instead add a KVM_MMIO_BUS device similar to coalesced MMIO? I think
> > > it'd be about the same amount of KVM code, and it would provide userspace
> > > with more flexibility, e.g. I assume it would allow handling even writes
> > > wholly within the kernel for certain ranges and/or use cases, and it'd
> > > allow stuffing a value other than 0xff (though I have no idea if there is
> > > a use case for this).
> >
> > I still think down the road the way to go is to map
> > valid RO page full of 0xff to avoid exit on read.
> > I don't think a KVM_MMIO_BUS device will allow this, will it?
>
> No, it would not, but adding KVM_MEM_PCI_HOLE doesn't get us any closer to
> solving that problem either.
I'm not sure why. Care to elaborate?
> What if we add a flag to allow routing all GFNs in a memslot to a single
> HVA?
An issue here would be this breaks attempts to use a hugepage for this.
> At a glance, it doesn't seem to heinous. It would have several of the
> same touchpoints as this series, e.g. __kvm_set_memory_region() and
> kvm_alloc_memslot_metadata().
>
> The functional changes (for x86) would be a few lines in
> __gfn_to_hva_memslot() and some new logic in kvm_handle_hva_range(). The
> biggest concern is probably the fragility of such an implementation, as KVM
> has a habit of open coding operations on memslots.
>
> The new flags could then be paired with KVM_MEM_READONLY to yield the desired
> behavior of reading out 0xff for an arbitrary range without requiring copious
> memslots and/or host pages.
>
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index 852fc8274bdd..875243a0ab36 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -1103,6 +1103,9 @@ __gfn_to_memslot(struct kvm_memslots *slots, gfn_t gfn)
> static inline unsigned long
> __gfn_to_hva_memslot(struct kvm_memory_slot *slot, gfn_t gfn)
> {
> + if (unlikely(slot->flags & KVM_MEM_SINGLE_HVA))
> + return slot->userspace_addr;
> +
> return slot->userspace_addr + (gfn - slot->base_gfn) * PAGE_SIZE;
> }
