Hi Andrew,
On 01/22/2019 10:49 AM, Andrew Murray wrote:
To prevent re-creating perf events everytime the counter registers
are changed, let's instead lazily create the event when the event
is first enabled and destroy it when it changes.
Signed-off-by: Andrew Murray
---
On Fri, Jan 18, 2019 at 05:58:33PM +, Marc Zyngier wrote:
> On 17/01/2019 20:33, 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, Jan 18, 2019 at 05:15:07PM +, Marc Zyngier wrote:
> On 17/01/2019 20:33, 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 member sve_max_vl is
On Fri, Jan 18, 2019 at 04:42:07PM +, Marc Zyngier wrote:
> On 17/01/2019 20:33, 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
On Tue, Jan 22, 2019 at 02:51:11PM +, Marc Zyngier wrote:
> On Tue, 22 Jan 2019 13:56:34 +,
> Dave Martin wrote:
> >
> > On Tue, Jan 22, 2019 at 11:11:09AM +, Marc Zyngier wrote:
> > > On Tue, 22 Jan 2019 10:17:00 +,
> > > Dave Martin wrote:
> > > >
> > > > On Mon, Jan 07, 2019
On Mon, Jan 07, 2019 at 12:05:36PM +, Andre Przywara wrote:
> KVM implements the firmware interface for mitigating cache speculation
> vulnerabilities. Guests may use this interface to ensure mitigation is
> active.
> If we want to migrate such a guest to a host with a different support
>
Hi Andrew
On 22/01/2019 10:49, Andrew Murray wrote:
> Emulate chained PMU counters by creating a single 64 bit event counter
> for a pair of chained KVM counters.
>
> Signed-off-by: Andrew Murray
> ---
> include/kvm/arm_pmu.h | 2 +
> virt/kvm/arm/pmu.c| 308
>
On Tue, 22 Jan 2019 13:56:34 +,
Dave Martin wrote:
>
> On Tue, Jan 22, 2019 at 11:11:09AM +, Marc Zyngier wrote:
> > On Tue, 22 Jan 2019 10:17:00 +,
> > Dave Martin wrote:
> > >
> > > On Mon, Jan 07, 2019 at 12:05:35PM +, Andre Przywara wrote:
> > > > Workarounds for Spectre
On 01/22/2019 10:49 AM, Andrew Murray wrote:
Let's reduce code duplication by extracting common code to its own
function.
Signed-off-by: Andrew Murray
---
Reviewed-by: Suzuki K Poulose
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
Hi Andrew
On 01/22/2019 10:49 AM, Andrew Murray wrote:
The perf event sample_period is currently set based upon the current
counter value, when PMXEVTYPER is written to and the perf event is created.
However the user may choose to write the type before the counter value in
which case
On Tue, Jan 22, 2019 at 11:11:09AM +, Marc Zyngier wrote:
> On Tue, 22 Jan 2019 10:17:00 +,
> Dave Martin wrote:
> >
> > On Mon, Jan 07, 2019 at 12:05:35PM +, Andre Przywara wrote:
> > > Workarounds for Spectre variant 2 or 4 vulnerabilities require some help
> > > from the firmware,
Hi Andrew,
On 22/01/2019 10:49, Andrew Murray wrote:
> To prevent re-creating perf events everytime the counter registers
> are changed, let's instead lazily create the event when the event
> is first enabled and destroy it when it changes.
>
> Signed-off-by: Andrew Murray
> ---
>
On Tue, Jan 22, 2019 at 12:12:51PM +, Julien Thierry wrote:
> Hi Andrew,
>
> On 22/01/2019 10:49, Andrew Murray wrote:
> > The perf event sample_period is currently set based upon the current
> > counter value, when PMXEVTYPER is written to and the perf event is created.
> > However the user
Hi Andrew,
On 22/01/2019 10:49, Andrew Murray wrote:
> The perf event sample_period is currently set based upon the current
> counter value, when PMXEVTYPER is written to and the perf event is created.
> However the user may choose to write the type before the counter value in
> which case
On 22/01/2019 07:07, Will Deacon wrote:
> On Thu, Jan 10, 2019 at 02:12:37PM +, Julien Thierry wrote:
>> This series was developped by Jean-Philippe and is needed for a series
>> I'll be posting shortly after to load firmwares on arm kvmtool.
>>
>> Currently, when a guest tries to reset a
On Tue, 22 Jan 2019 10:17:00 +,
Dave Martin wrote:
>
> On Mon, Jan 07, 2019 at 12:05:35PM +, Andre Przywara wrote:
> > Workarounds for Spectre variant 2 or 4 vulnerabilities require some help
> > from the firmware, so KVM implements an interface to provide that for
> > guests. When such
On Mon, Dec 10, 2018 at 07:15:13PM +, James Morse wrote:
> What happens if we miss MF_ACTION_REQUIRED?
AFAICU, the logic is to force-send a signal to the user process, i.e.,
force_sig_info() which cannot be ignored. IOW, an "enlightened" process
would know how to do recovery action from a
The perf event sample_period is currently set based upon the current
counter value, when PMXEVTYPER is written to and the perf event is created.
However the user may choose to write the type before the counter value in
which case sample_period will be set incorrectly. Let's instead decouple
event
ARMv8 provides support for chained PMU counters, where an event type
of 0x001E is set for odd-numbered counters, the event counter will
increment by one for each overflow of the preceding even-numbered
counter. Let's emulate this in KVM by creating a 64 bit perf counter
when a user chains two
Let's reduce code duplication by extracting common code to its own
function.
Signed-off-by: Andrew Murray
---
virt/kvm/arm/pmu.c | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index 1c5b76c..531d27f 100644
Emulate chained PMU counters by creating a single 64 bit event counter
for a pair of chained KVM counters.
Signed-off-by: Andrew Murray
---
include/kvm/arm_pmu.h | 2 +
virt/kvm/arm/pmu.c| 308 +-
2 files changed, 258 insertions(+), 52
To prevent re-creating perf events everytime the counter registers
are changed, let's instead lazily create the event when the event
is first enabled and destroy it when it changes.
Signed-off-by: Andrew Murray
---
virt/kvm/arm/pmu.c | 114 -
On Tue, 22 Jan 2019 10:17:00 +
Dave Martin wrote:
> On Mon, Jan 07, 2019 at 12:05:35PM +, Andre Przywara wrote:
> > Workarounds for Spectre variant 2 or 4 vulnerabilities require some
> > help from the firmware, so KVM implements an interface to provide
> > that for guests. When such a
On Mon, Jan 07, 2019 at 12:05:35PM +, Andre Przywara wrote:
> Workarounds for Spectre variant 2 or 4 vulnerabilities require some help
> from the firmware, so KVM implements an interface to provide that for
> guests. When such a guest is migrated, we want to make sure we don't
> loose the
Hi Will,
On 22/01/2019 07:10, Will Deacon wrote:
> Hi Julien,
>
> On Thu, Jan 10, 2019 at 02:20:40PM +, Julien Thierry wrote:
>> This series is based on the virtio reset series[1] posted earlier.
>>
>> We would like to be able to load firmwares like UEFI in kvmtool.
>>
>> The series
Hi James,
On Mon, 21 Jan 2019 17:04:01 +
James Morse wrote:
> On systems with VHE the kernel and KVM's world-switch code run at the
> same exception level. Code that is only used on a VHE system does not
> need to be annotated as __hyp_text as it can reside anywhere in the
> kernel text.
>
On Mon, 21 Jan 2019 17:04:02 +
James Morse wrote:
> On systems with VHE the kernel and KVM's world-switch code run at the
> same exception level. Code that is only used on a VHE system does not
> need to be annotated as __hyp_text as it can reside anywhere in the
> kernel text.
>
>
27 matches
Mail list logo
