All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oliver Upton <oliver.upton@linux.dev>
To: Marc Zyngier <maz@kernel.org>
Cc: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>,
	"kvmarm@lists.linux.dev" <kvmarm@lists.linux.dev>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"will@kernel.org" <will@kernel.org>,
	"mark.rutland@arm.com" <mark.rutland@arm.com>,
	"cohuck@redhat.com" <cohuck@redhat.com>,
	"eric.auger@redhat.com" <eric.auger@redhat.com>,
	yuzenghui <yuzenghui@huawei.com>,
	"Wangzhou (B)" <wangzhou1@hisilicon.com>,
	jiangkunkun <jiangkunkun@huawei.com>,
	Jonathan Cameron <jonathan.cameron@huawei.com>,
	Anthony Jebson <anthony.jebson@huawei.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Linuxarm <linuxarm@huawei.com>
Subject: Re: [RFC PATCH 0/6] KVM: arm64: Errata management for VM Live migration
Date: Fri, 11 Oct 2024 08:11:09 -0700	[thread overview]
Message-ID: <ZwlADbp-HjkijElX@linux.dev> (raw)
In-Reply-To: <86ikty6f1b.wl-maz@kernel.org>

On Fri, Oct 11, 2024 at 12:43:28PM +0100, Marc Zyngier wrote:
> On Fri, 11 Oct 2024 11:57:10 +0100, Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com> wrote:
> > > >
> > > > Please take a look and let me know your thoughts.
> > > 
> > > Having eyeballed this very superficially, I think we can do something
> > > simpler, and maybe more future-proof:
> > 
> > Thanks Marc for taking a look and the quick feedback.
> 
> No worries, that's the least I could do given that you put the effort
> implementing my silly ideas! ;-)
> 
> > > - I don't think KVM should be concerned about the description of the
> > >   target CPUs. The hypercall you defined is the right thing to do,
> > >   but the VMM should completely handle it. That's an implementation
> > >   detail, but it would make things much simpler.
> > 
> > Ok. So does that mean the hypercall will use some sort of shared memory
> > to retrieve the list of target CPUs from VMM?
> 
> Two possibilities:
> 
> - either shared memory, in which case the hypercall would require the
>   guest to give an IPA and size for the VMM to write its stuff into
>   the guest memory,
> 
> - or more simply return the data as an MIDR/REVIDR pair in registers,
>   the guest requesting an index, and getting an error when out of
>   range, leaving it with the freedom to organise the storage.
> 
> The second option is a bit slower, but way simpler, and it only
> happens once per guest boot, so it would probably be my preferred
> option unless this is proved to be impractical.

Also worth noting there's existing UAPI [*] for allowing userspace to
register range(s) of hypercalls that it services directly. It's a bit
weird that we'd allow userspace to do stuff in KVM's own hypercall
range, but I don't think it really matters at this point since this is
all prototyping.

[*]: https://docs.kernel.org/virt/kvm/devices/vm.html#attribute-kvm-arm-vm-smccc-filter-w-o

-- 
Thanks,
Oliver

  reply	other threads:[~2024-10-11 15:11 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-11  7:50 [RFC PATCH 0/6] KVM: arm64: Errata management for VM Live migration Shameer Kolothum
2024-10-11  7:50 ` [RFC PATCH 1/6] arm64: Modify callback matches() fn to take a target info Shameer Kolothum
2024-10-11  7:50 ` [RFC PATCH 2/6] KVM: arm64: Add support for VMM to set migration target Shameer Kolothum
2024-10-11  7:50 ` [RFC PATCH 3/6] KVM: arm64: Introduce a helper to retrieve errata Shameer Kolothum
2024-10-11  7:50 ` [RFC PATCH 4/6] KVM: arm64: Add hypercall support for retrieving migration errata bitmap Shameer Kolothum
2024-10-11  7:50 ` [RFC PATCH 5/6] arm64: Use hypercall to check for any migration related errata Shameer Kolothum
2024-10-11  7:50 ` [RFC PATCH 6/6] arm64: errata: Set migration_safe_cap for MIDR based errata Shameer Kolothum
2024-10-11 10:37 ` [RFC PATCH 0/6] KVM: arm64: Errata management for VM Live migration Marc Zyngier
2024-10-11 10:57   ` Shameerali Kolothum Thodi
2024-10-11 11:43     ` Marc Zyngier
2024-10-11 15:11       ` Oliver Upton [this message]
2024-10-11 15:51         ` Shameerali Kolothum Thodi
2024-10-17 15:49           ` Cornelia Huck
2024-10-17 17:16             ` Eric Auger
2024-10-18  8:33               ` Shameerali Kolothum Thodi
2024-10-18 12:28                 ` Cornelia Huck
2024-10-18 13:17               ` Marc Zyngier
2024-10-18 18:52                 ` Oliver Upton
2024-10-22 10:58                   ` Cornelia Huck
2024-10-22 12:52                     ` Marc Zyngier
2024-10-11 13:17 ` Cornelia Huck
2024-10-11 13:24   ` Shameerali Kolothum Thodi
2024-10-11 14:14     ` Cornelia Huck
2024-10-11 17:07 ` Oliver Upton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZwlADbp-HjkijElX@linux.dev \
    --to=oliver.upton@linux.dev \
    --cc=anthony.jebson@huawei.com \
    --cc=catalin.marinas@arm.com \
    --cc=cohuck@redhat.com \
    --cc=eric.auger@redhat.com \
    --cc=jiangkunkun@huawei.com \
    --cc=jonathan.cameron@huawei.com \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linuxarm@huawei.com \
    --cc=mark.rutland@arm.com \
    --cc=maz@kernel.org \
    --cc=shameerali.kolothum.thodi@huawei.com \
    --cc=wangzhou1@hisilicon.com \
    --cc=will@kernel.org \
    --cc=yuzenghui@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.