On Thu, Nov 24, 2016 at 04:10:23PM +, Alex Bennée wrote:
> While tests can be pegged to tcg it is useful to override this from time
> to time, especially when testing correctness on real systems.
> ---
> run_tests.sh | 8 ++--
> scripts/runtime.bash | 4
> 2 files changed, 10
On Thu, Nov 24, 2016 at 04:10:24PM +, Alex Bennée wrote:
> Certainly during development of the tests and MTTCG there are times when
> the timeout just gets in the way.
>
> Signed-off-by: Alex Bennée
> ---
> run_tests.sh | 8 ++--
> scripts/runtime.bash | 4
> 2 files changed
On Thu, Nov 24, 2016 at 04:10:25PM +, Alex Bennée wrote:
> This introduces a the option -o for passing of options directly to QEMU
> which is useful. In my case I'm using it to toggle MTTCG on an off:
>
> ./run_tests.sh -t -o "-tcg mttcg=on"
>
> Signed-off-by: Alex Bennée
> ---
> run_test
On Thu, Nov 24, 2016 at 04:10:26PM +, Alex Bennée wrote:
> So we can have portable formatting of uint32_t types.
>
> Signed-off-by: Alex Bennée
> ---
> lib/libcflat.h | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/lib/libcflat.h b/lib/libcflat.h
> index bdcc561..6dab5be 10064
On Thu, Nov 24, 2016 at 04:10:28PM +, Alex Bennée wrote:
> As distro compilers move towards defaults for build hardening for things
> like ASLR we need to force -fno-pic. Failure to do can lead to weird
> relocation problems when we build our "lat" binaries.
>
> Signed-off-by: Alex Bennée
> -
On Thu, Nov 24, 2016 at 04:10:29PM +, Alex Bennée wrote:
> This adds a fairly brain dead torture test for TLB flushes intended for
> stressing the MTTCG QEMU build. It takes the usual -smp option for
> multiple CPUs.
>
> By default it CPU0 will do a TLBIALL flush after each cycle. You can
> pa
On Thu, Nov 24, 2016 at 04:10:30PM +, Alex Bennée wrote:
> This test is the cousin of the tlbflush-code test. Instead of flushing
> running code it re-maps virtual addresses while a buffer is being filled
> up. It then audits the results checking for writes that have ended up in
> the wrong pla
On Thu, Nov 24, 2016 at 04:10:31PM +, Alex Bennée wrote:
> This test has been written mainly to stress multi-threaded TCG behaviour
> but will demonstrate failure by default on real hardware. The test takes
> the following parameters:
>
> - "lock" use GCC's locking semantics
> - "atomic" u
On Thu, Nov 24, 2016 at 04:10:22PM +, Alex Bennée wrote:
> Hi,
>
> Looking at my records it seems as though it has been a while since I
> last posted these tests. As I'm hoping to get the final bits of MTTCG
> merged upstream on the next QEMU development cycle I've been re-basing
> these and g
On Thu, Nov 24, 2016 at 04:10:22PM +, Alex Bennée wrote:
> Hi,
>
> Looking at my records it seems as though it has been a while since I
> last posted these tests. As I'm hoping to get the final bits of MTTCG
> merged upstream on the next QEMU development cycle I've been re-basing
> these and g
Andrew Jones writes:
> On Thu, Nov 24, 2016 at 04:10:22PM +, Alex Bennée wrote:
>> Hi,
>>
>> Looking at my records it seems as though it has been a while since I
>> last posted these tests. As I'm hoping to get the final bits of MTTCG
>> merged upstream on the next QEMU development cycle I'v
On 28 November 2016 at 11:12, Alex Bennée wrote:
>
> Andrew Jones writes:
>> I've skimmed over everything looking at it from a framwork/sytle
>> perspective. I didn't dig in trying to understand the tests though.
>> One general comment, I see many tests introduce MAX_CPUS 8. Why do
>> that? Why n
Andrew Jones writes:
> On Thu, Nov 24, 2016 at 04:10:25PM +, Alex Bennée wrote:
>> This introduces a the option -o for passing of options directly to QEMU
>> which is useful. In my case I'm using it to toggle MTTCG on an off:
>>
>> ./run_tests.sh -t -o "-tcg mttcg=on"
>>
>> Signed-off-by:
On Mon, Nov 28, 2016 at 11:14:48AM +, Peter Maydell wrote:
> On 28 November 2016 at 11:12, Alex Bennée wrote:
> >
> > Andrew Jones writes:
> >> I've skimmed over everything looking at it from a framwork/sytle
> >> perspective. I didn't dig in trying to understand the tests though.
> >> One ge
On Wed, Nov 23, 2016 at 06:31:48PM +0530, vijay.kil...@gmail.com wrote:
> From: Vijaya Kumar K
>
> Read and write of some registers like ISPENDR and ICPENDR
> from userspace requires special handling when compared to
> guest access for these registers.
>
> Refer to Documentation/virtual/kvm/devi
On Wed, Nov 23, 2016 at 06:31:49PM +0530, vijay.kil...@gmail.com wrote:
> From: Vijaya Kumar K
>
> VGICv3 Distributor and Redistributor registers are accessed using
> KVM_DEV_ARM_VGIC_GRP_DIST_REGS and KVM_DEV_ARM_VGIC_GRP_REDIST_REGS
> with KVM_SET_DEVICE_ATTR and KVM_GET_DEVICE_ATTR ioctls.
> T
On 28 November 2016 at 11:58, Andrew Jones wrote:
> On Mon, Nov 28, 2016 at 11:14:48AM +, Peter Maydell wrote:
>> On 28 November 2016 at 11:12, Alex Bennée wrote:
>> >
>> > Andrew Jones writes:
>> >> I've skimmed over everything looking at it from a framwork/sytle
>> >> perspective. I didn't
On Mon, Nov 28, 2016 at 01:30:54PM +, Peter Maydell wrote:
> On 28 November 2016 at 11:58, Andrew Jones wrote:
> > On Mon, Nov 28, 2016 at 11:14:48AM +, Peter Maydell wrote:
> >> On 28 November 2016 at 11:12, Alex Bennée wrote:
> >> >
> >> > Andrew Jones writes:
> >> >> I've skimmed over
On Mon, Nov 28, 2016 at 03:04:45PM +0100, Andrew Jones wrote:
> On Mon, Nov 28, 2016 at 01:30:54PM +, Peter Maydell wrote:
> > On 28 November 2016 at 11:58, Andrew Jones wrote:
> > > On Mon, Nov 28, 2016 at 11:14:48AM +, Peter Maydell wrote:
> > >> On 28 November 2016 at 11:12, Alex Bennée
On 28 November 2016 at 14:07, Andrew Jones wrote:
> Er... actually mach-virt is 123, as we only allocate 123 redistributors.
Oh yes, I'd forgotten about that limit. We'd need to add
a KVM API for allocating redistributors in non-contiguous
bits of memory if we wanted to raise that.
thanks
-- PMM
On Wed, Nov 23, 2016 at 06:31:52PM +0530, vijay.kil...@gmail.com wrote:
> From: Vijaya Kumar K
>
> ICC_VMCR_EL2 supports virtual access to ICC_IGRPEN1_EL1.Enable
> and ICC_IGRPEN0_EL1.Enable fields. Add grpen0 and grpen1 member
> variables to struct vmcr to support read and write of these fields.
From: Jintack
Bit positions of CNTHCTL_EL2 are changing depending on HCR_EL2.E2H bit.
EL1PCEN and EL1PCTEN are 1st and 0th bits when E2H is not set, but they
are 11th and 10th bits respectively when E2H is set. Current code is
unintentionally setting wrong bits to CNTHCTL_EL2 with E2H set.
In f
Bit positions of CNTHCTL_EL2 are changing depending on HCR_EL2.E2H bit.
EL1PCEN and EL1PCTEN are 1st and 0th bits when E2H is not set, but they
are 11th and 10th bits respectively when E2H is set. Current code is
unintentionally setting wrong bits to CNTHCTL_EL2 with E2H set, which
may allow guest
From: Jintack
Bit positions of CNTHCTL_EL2 are changing depending on HCR_EL2.E2H bit.
EL1PCEN and EL1PCTEN are 1st and 0th bits when E2H is not set, but they
are 11th and 10th bits respectively when E2H is set. Current code is
unintentionally setting wrong bits to CNTHCTL_EL2 with E2H set.
In f
On 28/11/16 16:43, Jintack Lim wrote:
> From: Jintack
>
> Bit positions of CNTHCTL_EL2 are changing depending on HCR_EL2.E2H bit.
> EL1PCEN and EL1PCTEN are 1st and 0th bits when E2H is not set, but they
> are 11th and 10th bits respectively when E2H is set. Current code is
> unintentionally set
Hi Jintack,
On 28/11/16 16:46, Jintack Lim wrote:
> Bit positions of CNTHCTL_EL2 are changing depending on HCR_EL2.E2H bit.
> EL1PCEN and EL1PCTEN are 1st and 0th bits when E2H is not set, but they
> are 11th and 10th bits respectively when E2H is set. Current code is
> unintentionally setting wr
Hello James,
Thank you for your feedback!
On 11/25/2016 11:19 AM, James Morse wrote:
Hi Tyler,
On 21/11/16 22:35, Tyler Baicar wrote:
A RAS (Reliability, Availability, Serviceability) controller
may be a separate processor running in parallel with OS
execution, and may generate error records
On 28/11/16 17:43, Marc Zyngier wrote:
> Hi Jintack,
>
> On 28/11/16 16:46, Jintack Lim wrote:
>> Bit positions of CNTHCTL_EL2 are changing depending on HCR_EL2.E2H bit.
>> EL1PCEN and EL1PCTEN are 1st and 0th bits when E2H is not set, but they
>> are 11th and 10th bits respectively when E2H is se
Hello James,
On 11/25/2016 11:20 AM, James Morse wrote:
Hi Tyler,
On 21/11/16 22:35, Tyler Baicar wrote:
Currently when a RAS error is reported it is not timestamped.
The ACPI 6.1 spec adds the timestamp field to the generic error
data entry v3 structure. The timestamp of when the firmware
gen
On Wed, Nov 23, 2016 at 06:31:53PM +0530, vijay.kil...@gmail.com wrote:
> From: Vijaya Kumar K
>
> VGICv3 CPU interface registers are accessed using
> KVM_DEV_ARM_VGIC_CPU_SYSREGS ioctl. These registers are accessed
> as 64-bit. The cpu MPIDR value is passed along with register id.
> is used to i
On Mon, Nov 28, 2016 at 06:39:04PM +, Marc Zyngier wrote:
> On 28/11/16 17:43, Marc Zyngier wrote:
> > Hi Jintack,
> >
> > On 28/11/16 16:46, Jintack Lim wrote:
> >> Bit positions of CNTHCTL_EL2 are changing depending on HCR_EL2.E2H bit.
> >> EL1PCEN and EL1PCTEN are 1st and 0th bits when E2H
On Wed, Nov 23, 2016 at 06:31:54PM +0530, vijay.kil...@gmail.com wrote:
> From: Vijaya Kumar K
>
> Userspace requires to store and restore of line_level for
> level triggered interrupts using ioctl KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO.
>
> Signed-off-by: Vijaya Kumar K
> ---
> arch/arm/include/uapi
Hi Vijaya,
On Wed, Nov 23, 2016 at 06:31:47PM +0530, vijay.kil...@gmail.com wrote:
> From: Vijaya Kumar K
>
> This patchset adds API for saving and restoring
> of VGICv3 registers to support live migration with new vgic feature.
> This API definition is as per version of VGICv3 specification
> D
On Mon, Nov 28, 2016 at 11:56 AM, Marc Zyngier wrote:
> On 28/11/16 16:43, Jintack Lim wrote:
>> From: Jintack
>>
>> Bit positions of CNTHCTL_EL2 are changing depending on HCR_EL2.E2H bit.
>> EL1PCEN and EL1PCTEN are 1st and 0th bits when E2H is not set, but they
>> are 11th and 10th bits respect
From: Jintack
Bit positions of CNTHCTL_EL2 are changing depending on HCR_EL2.E2H bit.
EL1PCEN and EL1PCTEN are 1st and 0th bits when E2H is not set, but they
are 11th and 10th bits respectively when E2H is set. Current code is
unintentionally setting wrong bits to CNTHCTL_EL2 with E2H set.
In f
On Mon, Nov 28, 2016 at 1:39 PM, Marc Zyngier wrote:
> On 28/11/16 17:43, Marc Zyngier wrote:
>> Hi Jintack,
Hi Marc,
>>
>> On 28/11/16 16:46, Jintack Lim wrote:
>>> Bit positions of CNTHCTL_EL2 are changing depending on HCR_EL2.E2H bit.
>>> EL1PCEN and EL1PCTEN are 1st and 0th bits when E2H is
On Tue, Nov 29, 2016 at 1:09 AM, Christoffer Dall
wrote:
> On Wed, Nov 23, 2016 at 06:31:53PM +0530, vijay.kil...@gmail.com wrote:
>> From: Vijaya Kumar K
>>
>> VGICv3 CPU interface registers are accessed using
>> KVM_DEV_ARM_VGIC_CPU_SYSREGS ioctl. These registers are accessed
>> as 64-bit. The
37 matches
Mail list logo
