[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200902020124.GB272502@thinks.paulus.ozlabs.org>
Date: Wed, 2 Sep 2020 12:01:24 +1000
From: Paul Mackerras <paulus@...abs.org>
To: Ravi Bangoria <ravi.bangoria@...ux.ibm.com>
Cc: mpe@...erman.id.au, mikey@...ling.org, npiggin@...il.com,
pbonzini@...hat.com, christophe.leroy@....fr, jniethe5@...il.com,
pedromfc@...ibm.com, rogealve@...ibm.com, kvm@...r.kernel.org,
kvm-ppc@...r.kernel.org, linux-kernel@...r.kernel.org,
linuxppc-dev@...ts.ozlabs.org, linux-kselftest@...r.kernel.org
Subject: Re: [PATCH 2/7] powerpc/watchpoint/kvm: Add infrastructure to
support 2nd DAWR
On Thu, Jul 23, 2020 at 03:50:53PM +0530, Ravi Bangoria wrote:
> kvm code assumes single DAWR everywhere. Add code to support 2nd DAWR.
> DAWR is a hypervisor resource and thus H_SET_MODE hcall is used to set/
> unset it. Introduce new case H_SET_MODE_RESOURCE_SET_DAWR1 for 2nd DAWR.
Is this the same interface as will be defined in PAPR and available
under PowerVM, or is it a new/different interface for KVM?
> Also, kvm will support 2nd DAWR only if CPU_FTR_DAWR1 is set.
In general QEMU wants to be able to control all aspects of the virtual
machine presented to the guest, meaning that just because a host has a
particular hardware capability does not mean we should automatically
present that capability to the guest.
In this case, QEMU will want a way to control whether the guest sees
the availability of the second DAWR/X registers or not, i.e. whether a
H_SET_MODE to set DAWR[X]1 will succeed or fail.
Paul.
Powered by blists - more mailing lists