SPRG3 is guest accessible and SPRG3 can be clobbered by host
or another guest, So this need to be restored when loading
guest state.
Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com
---
arch/powerpc/kvm/booke_interrupts.S | 2 ++
1 file changed, 2 insertions(+)
diff --git
On Tue, Jul 15, 2014 at 07:48:06PM -0700, Andy Lutomirski wrote:
virtio-rng is both too complicated and insufficient for initial rng
seeding. It's far too complicated to use for KASLR or any other
early boot random number needs. It also provides /dev/random-style
bits, which means that
On 07/16/2014 08:41 AM, Gleb Natapov wrote:
On Tue, Jul 15, 2014 at 07:48:06PM -0700, Andy Lutomirski wrote:
virtio-rng is both too complicated and insufficient for initial rng
seeding. It's far too complicated to use for KASLR or any other
early boot random number needs. It also provides
On Wed, Jul 16, 2014 at 09:10:27AM +0200, Daniel Borkmann wrote:
On 07/16/2014 08:41 AM, Gleb Natapov wrote:
On Tue, Jul 15, 2014 at 07:48:06PM -0700, Andy Lutomirski wrote:
virtio-rng is both too complicated and insufficient for initial rng
seeding. It's far too complicated to use for KASLR
Il 16/07/2014 09:10, Daniel Borkmann ha scritto:
On 07/16/2014 08:41 AM, Gleb Natapov wrote:
On Tue, Jul 15, 2014 at 07:48:06PM -0700, Andy Lutomirski wrote:
virtio-rng is both too complicated and insufficient for initial rng
seeding. It's far too complicated to use for KASLR or any other
https://bugzilla.kernel.org/show_bug.cgi?id=73331
Zhou, Chao chao.z...@intel.com changed:
What|Removed |Added
CC||chao.z...@intel.com
---
https://bugzilla.kernel.org/show_bug.cgi?id=73331
Paolo Bonzini bonz...@gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://bugzilla.kernel.org/show_bug.cgi?id=73331
robert...@intel.com changed:
What|Removed |Added
Status|RESOLVED|VERIFIED
--
You are receiving this
Hi All,
This is KVM upstream test result against kvm.git next branch and qemu.git
master branch.
kvm.git next branch: 9f6226a762c7ae02f6a23a3d4fc552dafa57ea23 based on
kernel 3.16.0-rc1
qemu.git master branch: 0e16297461264b3ea8f7282d1195cf53aa8a707c
We found no new bug and
This is v7 of a series that introduces arm to kvm-unit-tests. Three
of the v6 patches were already merged, so this is the remainder.
No new patches have been added, but some of the summaries have
changed.
This series first adds support for device trees (libfdt), and for
chr-testdev (virtio).
Signed-off-by: Andrew Jones drjo...@redhat.com
---
lib/asm-generic/io.h | 13 +
lib/asm-generic/page.h | 28
2 files changed, 41 insertions(+)
create mode 100644 lib/asm-generic/page.h
diff --git a/lib/asm-generic/io.h b/lib/asm-generic/io.h
index
Architecture neutral code may need to call low-level io accessors,
or use spinlocks. Create a generic io.h to ensure those accessors
are defined, and a generic spinlock.h that complains when included,
as we can't write a generic spinlock. These files can be overridden
or extended by architecture
Add support for tests to use exception handlers using
install_exception_handler(). This patch also adds start_usr(),
which can be used to start a function in USR mode, using a given
stack pointer. start_usr() is used by a new selftest test that
checks the new vector support.
Signed-off-by: Andrew
Currently only supports sending (outbufs), doesn't have any
bells or whistles. Code adapted from the Linux Kernel.
Signed-off-by: Andrew Jones drjo...@redhat.com
---
v7:
- {alloc,alloc_aligned} - {calloc,memalign}
- changes now split between virtio.* and virtio-mmio.* files
---
From: Christoffer Dall christoffer.d...@linaro.org
Add IO accessor functions to the arm library functions to avoid
register-writeback IO accessors that are not yet supported by the
kernel.
Signed-off-by: Christoffer Dall christoffer.d...@linaro.org
Signed-off-by: Andrew Jones drjo...@redhat.com
We're going to need PSR bit defines and pt_regs. We'll also need
pt_regs offsets in assembly code. This patch adapts the Linux
kernel's ptrace.h and generated/asm-offsets.h to this framework.
It also adapts cp15.h from the kernel, since we'll need bit defines
from there too.
Signed-off-by: Andrew
These are pretty much the same as the asm-generic version,
but use phys_addr_t.
Signed-off-by: Andrew Jones drjo...@redhat.com
---
lib/arm/asm/io.h | 13 +
lib/arm/asm/page.h | 34 +-
2 files changed, 46 insertions(+), 1 deletion(-)
diff --git
Support the bare minimum of virtio to enable access to the virtio-mmio
config space of a device. Currently this implementation must use a
device tree to find the device.
Signed-off-by: Andrew Jones drjo...@redhat.com
Reviewed-by: Christoffer Dall christoffer.d...@linaro.org
---
v7:
-
alloc supplies three ingredients to the test framework that are all
related to the support of dynamic memory allocation.
The first is a set of alloc function wrappers for malloc and its
friends. Using wrappers allows test code and common code to use the
same interface for memory allocation at all
Build libfdt and add some device tree functions built on it to the
arch-neutral lib code in order to facilitate the extraction of boot
info and device base addresses. These functions should work on device
trees conforming to section III of the kernel doc
chr-testdev is a qemu backend that can be used by test code to send qemu
commands. It communicates with qemu through a virtio-console device. The
only command currently implemented is quit, which allows the test code
to exit with a given status code, i.e. chr_testdev_exit(code).
Signed-off-by:
From: Christoffer Dall christoffer.d...@linaro.org
Add simple busy-wait spinlock implementation for ARM.
Signed-off-by: Christoffer Dall christoffer.d...@linaro.org
Signed-off-by: Andrew Jones drjo...@redhat.com
---
config/config-arm.mak | 3 ++-
lib/arm/asm/spinlock.h | 9 ++---
This is the initial drop of the arm test framework and a first test
that just checks that setup completed (a selftest). kvm isn't needed
to run this test unless testing with smp 1.
Try it out with
yum install gcc-arm-linux-gnu
export QEMU=[qemu with mach-virt and chr-testdev]
./configure
diff --git a/arm/unittests.cfg b/arm/unittests.cfg
new file mode 100644
index 0..da9dfd7b1f118
--- /dev/null
+++ b/arm/unittests.cfg
@@ -0,0 +1,18 @@
+# Define your new unittest following the convention:
+# [unittest_name]
+# file = foo.flat # Name of the flat file to be used
+# smp
- Original Message -
[...]
+void chr_testdev_exit(int code)
+{
+ char buf[8];
+ int len;
+
+ snprintf(buf, sizeof(buf), %dq, code);
+ len = strlen(buf);
AFAIK, snprintf returns the number of characters written, so
these two statements can be merged into one.
On Wed, Jul 16, 2014 at 11:22:18AM +0200, Paolo Bonzini wrote:
diff --git a/arm/unittests.cfg b/arm/unittests.cfg
new file mode 100644
index 0..da9dfd7b1f118
--- /dev/null
+++ b/arm/unittests.cfg
@@ -0,0 +1,18 @@
+# Define your new unittest following the convention:
+#
There are buggy hosts in the wild that advertise invariant
TSC and as result host uses TSC as clocksource, but TSC on
such host sometimes sporadically jumps backwards.
This causes kvmclock to go backwards if host advertises
PVCLOCK_TSC_STABLE_BIT, which turns off aggregated clock
accumulator and
Il 16/07/2014 11:52, Igor Mammedov ha scritto:
There are buggy hosts in the wild that advertise invariant
TSC and as result host uses TSC as clocksource, but TSC on
such host sometimes sporadically jumps backwards.
This causes kvmclock to go backwards if host advertises
PVCLOCK_TSC_STABLE_BIT,
Il 16/07/2014 11:39, Andrew Jones ha scritto:
PHYS_OFFSET is consistent with the kernel naming, so I'd like to keep
that. I invented PHYS_END, as it can serve a nice utility
(mem_size = PHYS_END - PHYS_OFFSET), and I wouldn't want to leave it
as the odd one out by not granting it the privilege
On Wed, Jul 16, 2014 at 12:18:37PM +0200, Paolo Bonzini wrote:
Il 16/07/2014 11:52, Igor Mammedov ha scritto:
There are buggy hosts in the wild that advertise invariant
TSC and as result host uses TSC as clocksource, but TSC on
such host sometimes sporadically jumps backwards.
This causes
On Wed, 16 Jul 2014 08:41:00 -0300
Marcelo Tosatti mtosa...@redhat.com wrote:
On Wed, Jul 16, 2014 at 12:18:37PM +0200, Paolo Bonzini wrote:
Il 16/07/2014 11:52, Igor Mammedov ha scritto:
There are buggy hosts in the wild that advertise invariant
TSC and as result host uses TSC as
On Wed, Jul 16, 2014 at 12:36 AM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 16/07/2014 09:10, Daniel Borkmann ha scritto:
On 07/16/2014 08:41 AM, Gleb Natapov wrote:
On Tue, Jul 15, 2014 at 07:48:06PM -0700, Andy Lutomirski wrote:
virtio-rng is both too complicated and insufficient for
Il 16/07/2014 15:55, Igor Mammedov ha scritto:
On Wed, 16 Jul 2014 08:41:00 -0300
Marcelo Tosatti mtosa...@redhat.com wrote:
On Wed, Jul 16, 2014 at 12:18:37PM +0200, Paolo Bonzini wrote:
Il 16/07/2014 11:52, Igor Mammedov ha scritto:
There are buggy hosts in the wild that advertise
Il 16/07/2014 16:07, Andy Lutomirski ha scritto:
This patch has nothing whatsoever to do with how much I trust the CPU
vs the hypervisor. It's for the enormous installed base of machines
without RDRAND.
Ok. I think an MSR is fine, though I don't think it's useful for the
guest to use it if
On Wed, 16 Jul 2014 16:16:17 +0200
Paolo Bonzini pbonz...@redhat.com wrote:
Il 16/07/2014 15:55, Igor Mammedov ha scritto:
On Wed, 16 Jul 2014 08:41:00 -0300
Marcelo Tosatti mtosa...@redhat.com wrote:
On Wed, Jul 16, 2014 at 12:18:37PM +0200, Paolo Bonzini wrote:
Il 16/07/2014 11:52,
On Wed, Jul 16, 2014 at 04:32:19PM +0200, Paolo Bonzini wrote:
Il 16/07/2014 16:07, Andy Lutomirski ha scritto:
This patch has nothing whatsoever to do with how much I trust the CPU
vs the hypervisor. It's for the enormous installed base of machines
without RDRAND.
Ok. I think an MSR is
Il 16/07/2014 16:51, Igor Mammedov ha scritto:
I'm not sure that a per-CPU value is enough; your patch can make
the problem much less frequent of course, but I'm not sure neither
detection nor correction are 100% reliable. Your addition is
basically a faster but less reliable version of the
On Wed, 16 Jul 2014 16:55:37 +0200
Paolo Bonzini pbonz...@redhat.com wrote:
Il 16/07/2014 16:51, Igor Mammedov ha scritto:
I'm not sure that a per-CPU value is enough; your patch can make
the problem much less frequent of course, but I'm not sure
neither detection nor correction are 100%
This updates x86's kvm_para.h for the feature bit definition and
target-i386/cpu.c for the feature name and default.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
linux-headers/asm-x86/kvm_para.h | 2 ++
target-i386/cpu.c| 5 +++--
2 files changed, 5 insertions(+), 2
On Wed, Jul 16, 2014 at 7:32 AM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 16/07/2014 16:07, Andy Lutomirski ha scritto:
This patch has nothing whatsoever to do with how much I trust the CPU
vs the hypervisor. It's for the enormous installed base of machines
without RDRAND.
Ok. I think
On 07/16/2014 07:07 AM, Andy Lutomirski wrote:
This patch has nothing whatsoever to do with how much I trust the CPU
vs the hypervisor. It's for the enormous installed base of machines
without RDRAND.
hpa suggested emulating RDRAND awhile ago, but I think that'll
unusably slow -- the
Il 16/07/2014 18:03, H. Peter Anvin ha scritto:
I suggested emulating RDRAND *but not set the CPUID bit*. We already
developed a protocol in KVM/Qemu to enumerate emulated features (created
for MOVBE as I recall), specifically to service the semantic feature X
will work but will be
On 07/16/2014 09:08 AM, Paolo Bonzini wrote:
Il 16/07/2014 18:03, H. Peter Anvin ha scritto:
I suggested emulating RDRAND *but not set the CPUID bit*. We already
developed a protocol in KVM/Qemu to enumerate emulated features (created
for MOVBE as I recall), specifically to service the
Il 16/07/2014 17:52, Andy Lutomirski ha scritto:
This updates x86's kvm_para.h for the feature bit definition and
target-i386/cpu.c for the feature name and default.
Signed-off-by: Andy Lutomirski l...@amacapital.net
Thanks, looks good---assuming the kernel side will make it into 3.17,
I'll
On Wed, Jul 16, 2014 at 09:13:23AM -0700, H. Peter Anvin wrote:
On 07/16/2014 09:08 AM, Paolo Bonzini wrote:
Il 16/07/2014 18:03, H. Peter Anvin ha scritto:
I suggested emulating RDRAND *but not set the CPUID bit*. We already
developed a protocol in KVM/Qemu to enumerate emulated features
This adds a simple interface to allow a guest to request 64 bits of
host nonblocking entropy. This is independent of virtio-rng for a
couple of reasons:
- It's intended to be usable during early boot, when a trivial
synchronous interface is needed.
- virtio-rng gives blocking entropy, and
It's considerably better than any of the alternatives on KVM.
Rather than reinventing all of the cpu feature query code, this fixes
native_cpuid to work in PIC objects.
I haven't combined it with boot/cpuflags.c's cpuid implementation:
including asm/processor.h from boot/cpuflags.c results in a
This is useful for making sure that init_std_data is working
correctly and for allaying fear when this happens:
random: xyz urandom read with SMALL_NUMBER bits of entropy available
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
drivers/char/random.c | 14 +++---
1 file
arch_get_slow_rng_u64 tries to get 64 bits of RNG seed data. Unlike
arch_get_random_{bytes,seed}, etc., it makes no claims about entropy
content. It's also likely to be much slower and should not be used
frequently. That being said, it should be fast enough to call
several times during boot
This should help solve the problem of guests starting out with
predictable RNG state.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
drivers/char/random.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 0a7ac0a..e2c3d02
virtio-rng is both too complicated and insufficient for initial rng
seeding. It's far too complicated to use for KASLR or any other
early boot random number needs. It also provides /dev/random-style
bits, which means that making guest boot wait for virtio-rng is
unacceptably slow, and doing it
Andy Lutomirski l...@amacapital.net writes:
virtio-rng is both too complicated and insufficient for initial rng
seeding. It's far too complicated to use for KASLR or any other
early boot random number needs. It also provides /dev/random-style
bits, which means that making guest boot wait
On Wed, Jul 16, 2014 at 11:02 AM, Bandan Das b...@redhat.com wrote:
Andy Lutomirski l...@amacapital.net writes:
virtio-rng is both too complicated and insufficient for initial rng
seeding. It's far too complicated to use for KASLR or any other
early boot random number needs. It also
Our current open/release path looks like this:
vfio_pci_open
vfio_pci_enable
pci_enable_device
pci_save_state
pci_store_saved_state
vfio_pci_release
vfio_pci_disable
pci_disable_device
pci_restore_state
pci_enable_device() doesn't modify PCI_COMMAND_MASTER, so if a
Each time a device is released, mark whether a local reset was
successful or whether a bus/slot reset is needed. If a reset is
needed and all of the affected devices are bound to vfio-pci and
unused, allow the reset. This is most useful when the userspace
driver is killed and releases all the
This series is intended to improve the state of devices returned back
to the host from vfio-pci or re-used by another user. First we make
sure that busmaster is disabled in the saved state, so the device
cannot continue to do DMA, then we add some serialization, move our
reference counting under
Serializing open/release allows us to fix a refcnt error if we fail
to enable the device and lets us prevent devices from being unbound
or opened, giving us an opportunity to do bus resets on release. No
restriction added to serialize binding devices to vfio-pci while the
mutex is held though.
On 07/16/2014 09:21 AM, Gleb Natapov wrote:
On Wed, Jul 16, 2014 at 09:13:23AM -0700, H. Peter Anvin wrote:
On 07/16/2014 09:08 AM, Paolo Bonzini wrote:
Il 16/07/2014 18:03, H. Peter Anvin ha scritto:
I suggested emulating RDRAND *but not set the CPUID bit*. We already
developed a protocol
Use the new nanoseconds based interface and get rid of the timespec
conversion dance.
Signed-off-by: Thomas Gleixner t...@linutronix.de
Cc: Gleb Natapov g...@kernel.org
Cc: kvm@vger.kernel.org
---
arch/x86/kvm/x86.c |6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
Index:
Convert the relevant base data right away to nanoseconds instead of
doing the conversion on every readout. Reduces text size by 160 bytes.
Signed-off-by: Thomas Gleixner t...@linutronix.de
Cc: Gleb Natapov g...@kernel.org
Cc: kvm@vger.kernel.org
---
arch/x86/kvm/x86.c | 44
On Wed, Jul 16, 2014 at 1:20 PM, H. Peter Anvin h...@zytor.com wrote:
On 07/16/2014 09:21 AM, Gleb Natapov wrote:
On Wed, Jul 16, 2014 at 09:13:23AM -0700, H. Peter Anvin wrote:
On 07/16/2014 09:08 AM, Paolo Bonzini wrote:
Il 16/07/2014 18:03, H. Peter Anvin ha scritto:
I suggested emulating
On 07/16/2014 02:32 PM, Andy Lutomirski wrote:
On the theory that I see no legitimate reason to expose this to guest
user space, I think we shouldn't expose it. If we wanted to add a
get_random_bytes syscall, that would be an entirely different story,
though.
Should I send v3 as one
This introduces and uses a very simple synchronous mechanism to get
/dev/urandom-style bits appropriate for initial KVM PV guest RNG
seeding.
virtio-rng is not suitable for this purpose. It's too difficult to
enumerate for use in early boot (e.g. KASLR, which runs before we
even have an IDT).
This should help solve the problem of guests starting out with
predictable RNG state.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
drivers/char/random.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 0a7ac0a..17ad33d
arch_get_slow_rng_u64 tries to get 64 bits of RNG seed data. Unlike
arch_get_random_{bytes,seed}, etc., it makes no claims about entropy
content. It's also likely to be much slower and should not be used
frequently. That being said, it should be fast enough to call
several times during boot
It's considerably better than any of the alternatives on KVM.
Rather than reinventing all of the cpu feature query code, this fixes
native_cpuid to work in PIC objects.
I haven't combined it with boot/cpuflags.c's cpuid implementation:
including asm/processor.h from boot/cpuflags.c results in a
This is useful for making sure that init_std_data is working
correctly and for allaying fear when this happens:
random: xyz urandom read with SMALL_NUMBER bits of entropy available
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
drivers/char/random.c | 15 ---
1 file
This adds a simple interface to allow a guest to request 64 bits of
host nonblocking entropy. This is independent of virtio-rng for a
couple of reasons:
- It's intended to be usable during early boot, when a trivial
synchronous interface is needed.
- virtio-rng gives blocking entropy, and
On 07/16/2014 02:45 PM, Andy Lutomirski wrote:
diff --git a/arch/x86/include/asm/archslowrng.h
b/arch/x86/include/asm/archslowrng.h
new file mode 100644
index 000..c8e8d0d
--- /dev/null
+++ b/arch/x86/include/asm/archslowrng.h
@@ -0,0 +1,30 @@
+/*
+ * This file is part of the Linux
On Wed, Jul 16, 2014 at 2:59 PM, H. Peter Anvin h...@zytor.com wrote:
On 07/16/2014 02:45 PM, Andy Lutomirski wrote:
diff --git a/arch/x86/include/asm/archslowrng.h
b/arch/x86/include/asm/archslowrng.h
new file mode 100644
index 000..c8e8d0d
--- /dev/null
+++
If the RFLAGS.RF is set, then no #DB should occur on instruction breakpoints.
However, the KVM emulator injects #DB regardless to RFLAGS.RF. This patch fixes
this behavior. KVM, however, still appears not to update RFLAGS.RF correctly,
regardless of this patch.
Signed-off-by: Nadav Amit
On Wed, Jul 16, 2014 at 3:13 PM, Andy Lutomirski l...@amacapital.net wrote:
My personal preference is to defer this until some user shows up. I
think that even this would be too complicated for KASLR, which is the
only extremely early-boot user that I found.
Hmm. Does the prandom stuff want
On 07/16/2014 03:40 PM, Andy Lutomirski wrote:
On Wed, Jul 16, 2014 at 3:13 PM, Andy Lutomirski l...@amacapital.net wrote:
My personal preference is to defer this until some user shows up. I
think that even this would be too complicated for KASLR, which is the
only extremely early-boot user
On Jul 16, 2014 4:00 PM, H. Peter Anvin h...@zytor.com wrote:
On 07/16/2014 03:40 PM, Andy Lutomirski wrote:
On Wed, Jul 16, 2014 at 3:13 PM, Andy Lutomirski l...@amacapital.net
wrote:
My personal preference is to defer this until some user shows up. I
think that even this would be too
On 07/16/2014 05:03 PM, Andy Lutomirski wrote:
prandom is exactly the opposite; it is designed for when we need
possibly low quality random numbers very quickly. RDRAND is actually
too slow.
I meant that prandom isn't using rdrand for early seeding.
We should probably fix that.
WARNING: CPU: 9 PID: 7251 at arch/x86/kvm/vmx.c:8719
nested_vmx_vmexit+0xa4/0x233 [kvm_intel]()
Modules linked in: tun nfsv3 nfs_acl auth_rpcgss oid_registry nfsv4
dns_resolver nfs fscache lockd
sunrpc pci_stub netconsole kvm_intel kvm bridge stp llc autofs4 8021q ipv6
uinput joydev microcode
This bug can be trigger by L1 goes down directly w/ enable_shadow_vmcs.
[ 6413.158950] kvm: vmptrld (null)/7800 failed
[ 6413.158954] vmwrite error: reg 401e value 4 (err 1)
[ 6413.158957] CPU: 0 PID: 4840 Comm: qemu-system-x86 Tainted: G OE
3.16.0kvm+ #2
[
This patch fix bug reported in
https://bugzilla.kernel.org/show_bug.cgi?id=73331,
after the patch http://www.spinics.net/lists/kvm/msg105230.html applied, there
is
some progress and the L2 can boot up, however, slowly. The original idea of
this
fix vid injection patch is from Zhang, Yang Z
Wanpeng Li wrote on 2014-07-17:
WARNING: CPU: 9 PID: 7251 at arch/x86/kvm/vmx.c:8719
nested_vmx_vmexit+0xa4/0x233 [kvm_intel]() Modules linked in: tun
nfsv3 nfs_acl auth_rpcgss oid_registry nfsv4 dns_resolver nfs fscache
lockd sunrpc pci_stub netconsole kvm_intel kvm bridge stp llc autofs4
SPRG3 is guest accessible and SPRG3 can be clobbered by host
or another guest, So this need to be restored when loading
guest state.
Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com
---
arch/powerpc/kvm/booke_interrupts.S | 2 ++
1 file changed, 2 insertions(+)
diff --git
The POWER8 processor has a Micro Partition Prefetch Engine, which is
a fancy way of saying has way to store and load contents of L2 or
L2+MRU way of L3 cache. We initiate the storing of the log (list of
addresses) using the logmpp instruction and start restore by writing
to a SPR.
The logmpp
81 matches
Mail list logo
