Hi Jean-Philippe,
On Thu, Apr 04, 2019 at 12:06:51PM +0100, Jean-Philippe Brucker wrote:
> On 26/03/2019 07:41, Leo Yan wrote:
> > Since PCI forbids enabling INTx, MSI or MSIX at the same time, it's by
> > default to disable INTx mode when enable MSI/MSIX mode; but this logic is
> > easily broken
On Fri, Mar 29, 2019 at 01:00:31PM +, Dave Martin wrote:
> The roles of sve_init_vq_map(), sve_update_vq_map() and
> sve_verify_vq_map() are highly non-obvious to anyone who has not dug
> through cpufeatures.c in detail.
>
> Since the way these functions interact with each other is more
>
On Fri, Mar 29, 2019 at 01:00:32PM +, Dave Martin wrote:
> Due to the way the effective SVE vector length is controlled and
> trapped at different exception levels, certain mismatches in the
> sets of vector lengths supported by different physical CPUs in the
> system may prevent
On Fri, Mar 29, 2019 at 01:00:34PM +, Dave Martin wrote:
> Since SVE will be enabled or disabled on a per-vcpu basis, a flag
> is needed in order to track which vcpus have it enabled.
>
> This patch adds a suitable flag and a helper for checking it.
>
> Signed-off-by: Dave Martin
>
On Fri, Mar 29, 2019 at 01:00:35PM +, Dave Martin wrote:
> Architecture features that are conditionally visible to the guest
> will require run-time checks in the ID register accessor functions.
> In particular, read_id_reg() will need to perform checks in order
> to generate the correct
On Fri, Mar 29, 2019 at 01:00:39PM +, Dave Martin wrote:
> The Arm SVE architecture defines registers that are up to 2048 bits
> in size (with some possibility of further future expansion).
>
> In order to avoid the need for an excessively large number of
> ioctls when saving and restoring a
On Fri, Mar 29, 2019 at 01:00:52PM +, Dave Martin wrote:
> This patch adds sections to the KVM API documentation describing
> the extensions for supporting the Scalable Vector Extension (SVE)
> in guests.
>
> Signed-off-by: Dave Martin
>
> ---
>
> Changes since v5:
>
> * Document
On Fri, Mar 29, 2019 at 01:00:50PM +, Dave Martin wrote:
> To provide a uniform way to check for KVM SVE support amongst other
> features, this patch adds a suitable capability KVM_CAP_ARM_SVE,
> and reports it as present when SVE is available.
>
> Signed-off-by: Dave Martin
> Reviewed-by:
On Fri, Mar 29, 2019 at 01:00:49PM +, Dave Martin wrote:
> Now that all the pieces are in place, this patch offers a new flag
> KVM_ARM_VCPU_SVE that userspace can pass to KVM_ARM_VCPU_INIT to
> turn on SVE for the guest, on a per-vcpu basis.
>
> As part of this, support for initialisation
On Fri, Mar 29, 2019 at 01:00:48PM +, Dave Martin wrote:
> This patch adds a new pseudo-register KVM_REG_ARM64_SVE_VLS to
> allow userspace to set and query the set of vector lengths visible
> to the guest.
>
> In the future, multiple register slices per SVE register may be
> visible through
On Fri, Mar 29, 2019 at 01:00:48PM +, Dave Martin wrote:
> This patch adds a new pseudo-register KVM_REG_ARM64_SVE_VLS to
> allow userspace to set and query the set of vector lengths visible
> to the guest.
>
> In the future, multiple register slices per SVE register may be
> visible through
On Thu, Apr 04, 2019 at 05:34:00PM +0100, Will Deacon wrote:
> On Thu, Mar 28, 2019 at 10:37:27AM +, Andrew Murray wrote:
> > Add support for the :G and :H attributes in perf by handling the
> > exclude_host/exclude_guest event attributes.
> >
> > We notify KVM of counters that we wish to be
On Thu, Apr 04, 2019 at 05:14:16PM +0100, Will Deacon wrote:
> On Thu, Apr 04, 2019 at 05:09:58PM +0100, Will Deacon wrote:
> > On Thu, Mar 28, 2019 at 10:37:25AM +, Andrew Murray wrote:
> > > The virt/arm core allocates a kvm_cpu_context_t percpu, at present this is
> > > a typedef to
On Thu, Apr 04, 2019 at 05:21:28PM +0100, Will Deacon wrote:
> On Thu, Mar 28, 2019 at 10:37:31AM +, Andrew Murray wrote:
> > The interaction between the exclude_{host,guest} flags,
> > exclude_{user,kernel,hv} flags and presence of VHE can result in
> > different exception levels being
On 02/04/2019 03:27, Amit Daniel Kachhap wrote:
> From: Mark Rutland
>
> When pointer authentication is supported, a guest may wish to use it.
> This patch adds the necessary KVM infrastructure for this to work, with
> a semi-lazy context switch of the pointer auth state.
[...]
> diff --git
A failed KVM_ARM_VCPU_INIT, should not set the vcpu target,
as the vcpu target is used by kvm_vcpu_initialized() to
determine if other vcpu ioctls may proceed. We need to set
the target before calling kvm_reset_vcpu(), but if that call
fails, we should then unset it.
Signed-off-by: Andrew Jones
On Thu, Apr 04, 2019 at 06:25:39PM +0200, Andrew Jones wrote:
> On Thu, Apr 04, 2019 at 03:50:56PM +0100, Dave Martin wrote:
> > On Thu, Apr 04, 2019 at 03:57:06PM +0200, Andrew Jones wrote:
> > > On Fri, Mar 29, 2019 at 01:00:43PM +, Dave Martin wrote:
> > > > This patch adds the following
On Thu, Apr 04, 2019 at 05:07:09PM +0200, Andrew Jones wrote:
> On Fri, Mar 29, 2019 at 01:00:47PM +, Dave Martin wrote:
> > Some aspects of vcpu configuration may be too complex to be
> > completed inside KVM_ARM_VCPU_INIT. Thus, there may be a
> > requirement for userspace to do some
Hi Andre,
Thanks for looking into this.
On Thu, Apr 4, 2019 at 9:17 PM Andre Przywara wrote:
>
> On Thu, 4 Apr 2019 12:30:15 +
> Zenghui Yu wrote:
>
> Hi,
>
> > Commit ad275b8bb1e6 ("KVM: arm/arm64: vgic-new: vgic_init: implement
> > vgic_init") had set irq->targets in
On Thu, Mar 28, 2019 at 10:37:27AM +, Andrew Murray wrote:
> Add support for the :G and :H attributes in perf by handling the
> exclude_host/exclude_guest event attributes.
>
> We notify KVM of counters that we wish to be enabled or disabled on
> guest entry/exit and thus defer from starting
On Thu, Apr 04, 2019 at 03:53:55PM +0100, Dave Martin wrote:
> On Thu, Apr 04, 2019 at 04:25:28PM +0200, Andrew Jones wrote:
> > On Fri, Mar 29, 2019 at 01:00:46PM +, Dave Martin wrote:
> > > This patch adds a kvm_arm_init_arch_resources() hook to perform
> > > subarch-specific initialisation
On Thu, Apr 04, 2019 at 03:50:56PM +0100, Dave Martin wrote:
> On Thu, Apr 04, 2019 at 03:57:06PM +0200, Andrew Jones wrote:
> > On Fri, Mar 29, 2019 at 01:00:43PM +, Dave Martin wrote:
> > > This patch adds the following registers for access via the
> > > KVM_{GET,SET}_ONE_REG interface:
> >
On Thu, Mar 28, 2019 at 10:37:31AM +, Andrew Murray wrote:
> The interaction between the exclude_{host,guest} flags,
> exclude_{user,kernel,hv} flags and presence of VHE can result in
> different exception levels being filtered by the ARMv8 PMU. As this
> can be confusing let's document how
On Thu, Apr 04, 2019 at 05:09:58PM +0100, Will Deacon wrote:
> On Thu, Mar 28, 2019 at 10:37:25AM +, Andrew Murray wrote:
> > The virt/arm core allocates a kvm_cpu_context_t percpu, at present this is
> > a typedef to kvm_cpu_context and is used to store host cpu context. The
> >
On Thu, Mar 28, 2019 at 10:37:25AM +, Andrew Murray wrote:
> The virt/arm core allocates a kvm_cpu_context_t percpu, at present this is
> a typedef to kvm_cpu_context and is used to store host cpu context. The
> kvm_cpu_context structure is also used elsewhere to hold vcpu context.
> In order
On Fri, Mar 29, 2019 at 01:00:47PM +, Dave Martin wrote:
> Some aspects of vcpu configuration may be too complex to be
> completed inside KVM_ARM_VCPU_INIT. Thus, there may be a
> requirement for userspace to do some additional configuration
> before various other ioctls will work in a
On Thu, Apr 04, 2019 at 04:25:28PM +0200, Andrew Jones wrote:
> On Fri, Mar 29, 2019 at 01:00:46PM +, Dave Martin wrote:
> > This patch adds a kvm_arm_init_arch_resources() hook to perform
> > subarch-specific initialisation when starting up KVM.
> >
> > This will be used in a subsequent
On Thu, Apr 04, 2019 at 03:57:06PM +0200, Andrew Jones wrote:
> On Fri, Mar 29, 2019 at 01:00:43PM +, Dave Martin wrote:
> > This patch adds the following registers for access via the
> > KVM_{GET,SET}_ONE_REG interface:
> >
> > * KVM_REG_ARM64_SVE_ZREG(n, i) (n = 0..31) (in 2048-bit slices)
On Fri, Mar 29, 2019 at 01:00:46PM +, Dave Martin wrote:
> This patch adds a kvm_arm_init_arch_resources() hook to perform
> subarch-specific initialisation when starting up KVM.
>
> This will be used in a subsequent patch for global SVE-related
> setup on arm64.
>
> No functional change.
>
On Fri, Mar 29, 2019 at 01:00:45PM +, Dave Martin wrote:
> KVM will need to interrogate the set of SVE vector lengths
> available on the system.
>
> This patch exposes the relevant bits to the kernel, along with a
> sve_vq_available() helper to check whether a particular vector
> length is
On Fri, Mar 29, 2019 at 01:00:44PM +, Dave Martin wrote:
> This patch includes the SVE register IDs in the list returned by
> KVM_GET_REG_LIST, as appropriate.
>
> On a non-SVE-enabled vcpu, no new IDs are added.
>
> On an SVE-enabled vcpu, IDs for the FPSIMD V-registers are removed
> from
On Fri, Mar 29, 2019 at 01:00:43PM +, Dave Martin wrote:
> This patch adds the following registers for access via the
> KVM_{GET,SET}_ONE_REG interface:
>
> * KVM_REG_ARM64_SVE_ZREG(n, i) (n = 0..31) (in 2048-bit slices)
> * KVM_REG_ARM64_SVE_PREG(n, i) (n = 0..15) (in 256-bit slices)
> *
On Thu, 7 Mar 2019 08:36:07 +
Julien Thierry wrote:
> The PCI Local Bus Specification, Rev. 3.0,
> Section 6.2.5.1. "Address Maps" states:
> "Devices that map control functions into I/O Space must not consume more
> than 256 bytes per I/O Base Address register."
>
> Yet all the PCI devices
On Thu, 7 Mar 2019 08:36:06 +
Julien Thierry wrote:
Hi,
> The dynamic ioport allocation with IOPORT_EMPTY is currently only used
> by PCI devices. Other devices use fixed ports for which they request
> registration to the ioport API.
>
> PCI ports need to be in the PCI IO space and there
On Thu, 7 Mar 2019 08:36:05 +
Julien Thierry wrote:
Hi,
> From: Sami Mujawar
>
> According to the 'PCI Local Bus Specification, Revision 3.0,
> February 3, 2004, Section 6.2.5.1, Implementation Notes, page 227'
>
> "Software saves the original value of the Base Address register,
>
On Thu, 7 Mar 2019 08:36:04 +
Julien Thierry wrote:
> Build breaks when using KVM_BRLOCK_DEBUG because the header was seamingly
> conceived to be included in a single .c file...
>
> Fix this by moving the definition of the read/write lock into the kvm
> struct.
>
> Signed-off-by: Julien
On Thu, 7 Mar 2019 08:36:03 +
Julien Thierry wrote:
> The kvm argument is not passed to br_read_lock/unlock, this works for
> the barrier implementation because the argument is not used. This ever
> breaks if another lock implementation is used.
>
> Signed-off-by: Julien Thierry
On Thu, 7 Mar 2019 08:36:02 +
Julien Thierry wrote:
> The vesa framebuffer is only used by architectures that explicitly
> require it (i.e. x86). Compile it out for architectures not using it, as
> its current implementation might not work for them.
>
> Signed-off-by: Julien Thierry
On Thu, 4 Apr 2019 12:30:15 +
Zenghui Yu wrote:
Hi,
> Commit ad275b8bb1e6 ("KVM: arm/arm64: vgic-new: vgic_init: implement
> vgic_init") had set irq->targets in kvm_vgic_vcpu_init(), regardless of
> the GIC architecture (v2 or v3). When the number of vcpu reaches 32
> (in v3), UBSAN will
Commit ad275b8bb1e6 ("KVM: arm/arm64: vgic-new: vgic_init: implement
vgic_init") had set irq->targets in kvm_vgic_vcpu_init(), regardless of
the GIC architecture (v2 or v3). When the number of vcpu reaches 32
(in v3), UBSAN will complain about it.
On 26/03/2019 07:41, Leo Yan wrote:
> To support INTx enabling for multiple times, we need firstly to extract
> one-time initialisation and move the related code into a new function
> vfio_pci_init_intx(); if later disable and re-enable the INTx, we can
> skip these one-time operations.
>
> This
On 26/03/2019 07:41, Leo Yan wrote:
> Since PCI forbids enabling INTx, MSI or MSIX at the same time, it's by
> default to disable INTx mode when enable MSI/MSIX mode; but this logic is
> easily broken if the guest PCI driver detects the MSI/MSIX cannot work as
> expected and tries to rollback to
On Thu, 04 Apr 2019 11:07:59 +0100,
"Tangnianyao (ICT)" wrote:
>
>
>
> On 2019/3/30 17:43, Marc Zyngier wrote:
>
> Hi, Marc
>
> > On Sat, 30 Mar 2019 08:42:58 +,
> > "Tangnianyao (ICT)" wrote:
> >>
> >> Hi, Marc
> >>
> >> On 2019/3/21 1:02, Marc Zyngier Wrote:
> >>> On Tue, 19 Mar 2019
On 2019/3/30 17:43, Marc Zyngier wrote:
Hi, Marc
> On Sat, 30 Mar 2019 08:42:58 +,
> "Tangnianyao (ICT)" wrote:
>>
>> Hi, Marc
>>
>> On 2019/3/21 1:02, Marc Zyngier Wrote:
>>> On Tue, 19 Mar 2019 21:25:47 +0800
>>> "Tangnianyao (ICT)" wrote:
>>>
Hi, all
Using gicv4, when
On Thu, Apr 04, 2019 at 09:38:49AM +, Dave P Martin wrote:
> On Thu, Apr 04, 2019 at 10:34:15AM +0100, Andrew Jones wrote:
> > On Thu, Apr 04, 2019 at 09:35:26AM +0100, Dave Martin wrote:
> > > On Wed, Apr 03, 2019 at 10:27:46PM +0200, Andrew Jones wrote:
> > > > On Fri, Mar 29, 2019 at
On Thu, Apr 04, 2019 at 10:34:15AM +0100, Andrew Jones wrote:
> On Thu, Apr 04, 2019 at 09:35:26AM +0100, Dave Martin wrote:
> > On Wed, Apr 03, 2019 at 10:27:46PM +0200, Andrew Jones wrote:
> > > On Fri, Mar 29, 2019 at 01:00:51PM +, Dave Martin wrote:
> > > > KVM_GET_ONE_REG and
On Thu, Apr 04, 2019 at 09:35:26AM +0100, Dave Martin wrote:
> On Wed, Apr 03, 2019 at 10:27:46PM +0200, Andrew Jones wrote:
> > On Fri, Mar 29, 2019 at 01:00:51PM +, Dave Martin wrote:
> > > KVM_GET_ONE_REG and KVM_SET_ONE_REG return some error codes that
> > > are not documented (but
On Fri, Mar 29, 2019 at 01:00:37PM +, Dave Martin wrote:
> This patch adds the necessary support for context switching ZCR_EL1
> for each vcpu.
>
> ZCR_EL1 is trapped alongside the FPSIMD/SVE registers, so it makes
> sense for it to be handled as part of the guest FPSIMD/SVE context
> for
On Thu, Apr 04, 2019 at 10:32:18AM +0200, Andrew Jones wrote:
> On Thu, Apr 04, 2019 at 09:06:58AM +0100, Dave Martin wrote:
> > On Wed, Apr 03, 2019 at 09:39:43PM +0200, Andrew Jones wrote:
> > > On Fri, Mar 29, 2019 at 01:00:37PM +, Dave Martin wrote:
[...]
> > > > +static int
On Thu, Apr 04, 2019 at 10:35:02AM +0200, Andrew Jones wrote:
> On Thu, Apr 04, 2019 at 09:10:08AM +0100, Dave Martin wrote:
> > On Wed, Apr 03, 2019 at 10:01:45PM +0200, Andrew Jones wrote:
> > > On Fri, Mar 29, 2019 at 01:00:38PM +, Dave Martin wrote:
> > > > In order to give each vcpu its
On Thu, Apr 04, 2019 at 09:10:08AM +0100, Dave Martin wrote:
> On Wed, Apr 03, 2019 at 10:01:45PM +0200, Andrew Jones wrote:
> > On Fri, Mar 29, 2019 at 01:00:38PM +, Dave Martin wrote:
> > > In order to give each vcpu its own view of the SVE registers, this
> > > patch adds context storage
On Thu, Apr 04, 2019 at 09:06:58AM +0100, Dave Martin wrote:
> On Wed, Apr 03, 2019 at 09:39:43PM +0200, Andrew Jones wrote:
> > On Fri, Mar 29, 2019 at 01:00:37PM +, Dave Martin wrote:
> > > This patch adds the necessary support for context switching ZCR_EL1
> > > for each vcpu.
> > >
> > >
On Wed, Apr 03, 2019 at 10:01:45PM +0200, Andrew Jones wrote:
> On Fri, Mar 29, 2019 at 01:00:38PM +, Dave Martin wrote:
> > In order to give each vcpu its own view of the SVE registers, this
> > patch adds context storage via a new sve_state pointer in struct
> > vcpu_arch. An additional
On Wed, Apr 03, 2019 at 09:39:43PM +0200, Andrew Jones wrote:
> On Fri, Mar 29, 2019 at 01:00:37PM +, Dave Martin wrote:
> > This patch adds the necessary support for context switching ZCR_EL1
> > for each vcpu.
> >
> > ZCR_EL1 is trapped alongside the FPSIMD/SVE registers, so it makes
> >
On Thu, Apr 04, 2019 at 04:17:24AM +0100, Marc Zyngier wrote:
> On Wed, 03 Apr 2019 20:14:13 +0100,
> Andrew Jones wrote:
> >
> > On Fri, Mar 29, 2019 at 01:00:34PM +, Dave Martin wrote:
> > > Since SVE will be enabled or disabled on a per-vcpu basis, a flag
> > > is needed in order to track
Hi Marc, Robin, Alex,
On 4/3/19 7:38 PM, Alex Williamson wrote:
> On Wed, 3 Apr 2019 16:30:15 +0200
> Auger Eric wrote:
>
>> Hi Alex,
>>
>> On 3/22/19 11:09 PM, Alex Williamson wrote:
>>> On Fri, 22 Mar 2019 10:30:02 +0100
>>> Auger Eric wrote:
>>>
Hi Alex,
On 3/22/19 12:01 AM,
56 matches
Mail list logo
