On Wed, 2013-12-11 at 12:16 +, Carlos Rodrigues wrote:
I send in attachment the screen image of blue screen.
About other question, with fresh installation with version 0.52 of
drivers, and block device as ide, the reboot works properly.
Regards,
CC'ing Mike
Mike do we have any
Support format flags for field padding, such as %08x, allowing
register dumps to be easier on the eyes.
Signed-off-by: Andrew Jones drjo...@redhat.com
---
lib/printf.c | 84 ++--
1 file changed, 70 insertions(+), 14 deletions(-)
diff --git
This series adds exception handling support to kvm-unit-tests/arm, and
is based on v2 of the arm initial drop series. A vector support patch
was also posted with the v1 of the arm initial drop series, but not
with the v2. This series is its v2.
v2:
- use pt_regs as the kernel does [Christoffer
Add support for tests to use exception handlers.
Signed-off-by: Andrew Jones drjo...@redhat.com
---
arm/boot.c| 128 --
arm/cstart.S | 168 --
arm/flat.lds | 7 ++-
VFIO currently allocates it's own dynamic chardev range, reserving the
first minor for the control part of the interface (/dev/vfio/vfio) and
the remainder for VFIO groups (/dev/vfio/$GROUP). This works, but it
doesn't support auto loading. For instance when libvirt checks for
VFIO support
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 asm-offsets to this framework. Even though
lib/arm/asm-offsets.h is a generated file, we still commit it,
as it's unlikely to change. Also adapt
For migration to work we need to save (and later restore) the state of
each core's virtual generic timer.
Since this is per VCPU, we can use the [gs]et_one_reg ioctl and export
the three needed registers (control, counter, compare value).
Though they live in cp15 space, we don't use the existing
Another test that i made was, if i have 1 vCPU the problem is
reproducible, but if i increase to 2 vCPU, the Windows Server reboot
without any problem.
Regards,
--
Carlos Rodrigues
Engenheiro de Software Sénior
Eurotux Informática, S.A. | www.eurotux.com
(t) +351 253 680 300 (m) +351 911
On 2013-12-12 22:59, Paolo Bonzini wrote:
Il 12/12/2013 22:27, Gabriel L. Somlo ha scritto:
I tried copying and/or cut'n'pasting from additional source files in
the current kvm git tree, but haven't totally figured out how the magic
of make sync works yet :) Do you have any notes or any other
Il 13/12/2013 16:04, Jan Kiszka ha scritto:
Yes, kvm-kmod is starting to bitrot. I just noticed I messed up the last
stable release back in August, and no one seems to have noticed it.
There were no complains about the missing releases for 3.11 and 3.12, so
it the relevance must have dropped
On 2013-12-13 16:12, Paolo Bonzini wrote:
Il 13/12/2013 16:04, Jan Kiszka ha scritto:
Yes, kvm-kmod is starting to bitrot. I just noticed I messed up the last
stable release back in August, and no one seems to have noticed it.
There were no complains about the missing releases for 3.11 and
2013-12-12 21:36+0100, Paolo Bonzini:
From: Gleb Natapov g...@redhat.com
A guest can cause a BUG_ON() leading to a host kernel crash.
When the guest writes to the ICR to request an IPI, while in x2apic
mode the following things happen, the destination is read from
ICR2, which is a register
On Fri, Dec 13, 2013 at 04:36:07PM +0100, Jan Kiszka wrote:
On 2013-12-13 16:12, Paolo Bonzini wrote:
I think the relevance of releases is ~zero. kvm-kmod still remains
extremely useful IMHO as a hacking tool.
Exactly.
I agree. No idea how Real KVM Hackers (tm) do it, but this wannabe
Il 13/12/2013 17:19, Gabriel L. Somlo ha scritto:
So I tried to mimic the existing sed functionality of the sync
script, and was was left deciding between excising the call to
smp_mb__after_srcu_read_unlock() from line 6009 of x86.c (since it's
defined as a no-op in the header), or
On 2013-12-13 17:19, Gabriel L. Somlo wrote:
On Fri, Dec 13, 2013 at 04:36:07PM +0100, Jan Kiszka wrote:
On 2013-12-13 16:12, Paolo Bonzini wrote:
I think the relevance of releases is ~zero. kvm-kmod still remains
extremely useful IMHO as a hacking tool.
Exactly.
I agree. No idea how
Whoops, I forgot to mark these as v4... Sorry about that!
-Christoffer
On Thu, Dec 12, 2013 at 11:55:39AM -0800, Christoffer Dall wrote:
Implement save/restore of the VGIC state using the newer KVM Device
Control API. This requries some number of changes to existing code in
addition to
Il 13/12/2013 17:07, Radim Krčmář ha scritto:
This bug can only be hit when the destination cpu is 256, so the
request itself is buggy -- we don't support that many in kvm and it
would crash when initializing the vcpus if we did.
= It looks like we should just ignore the ipi,
2013-12-13 18:25+0100, Paolo Bonzini:
Il 13/12/2013 17:07, Radim Krčmář ha scritto:
This bug can only be hit when the destination cpu is 256, so the
request itself is buggy -- we don't support that many in kvm and it
would crash when initializing the vcpus if we did.
= It
On Fri, Dec 13, 2013 at 02:23:26PM +0100, Andre Przywara wrote:
For migration to work we need to save (and later restore) the state of
each core's virtual generic timer.
Since this is per VCPU, we can use the [gs]et_one_reg ioctl and export
the three needed registers (control, counter, compare
On 12/13/2013 09:10 PM, Christoffer Dall wrote:
On Fri, Dec 13, 2013 at 02:23:26PM +0100, Andre Przywara wrote:
For migration to work we need to save (and later restore) the state of
each core's virtual generic timer.
Since this is per VCPU, we can use the [gs]et_one_reg ioctl and export
the
On Fri, 2013-12-13 at 14:02 +1100, Alexey Kardashevskiy wrote:
On 12/13/2013 10:35 AM, Scott Wood wrote:
On Tue, May 21, 2013 at 01:33:09PM +1000, Alexey Kardashevskiy wrote:
+static int iommu_add_device(struct device *dev)
+{
+ struct iommu_table *tbl;
+ int ret = 0;
+
+ if
On Fri, Dec 13, 2013 at 09:35:49PM +0100, Andre Przywara wrote:
On 12/13/2013 09:10 PM, Christoffer Dall wrote:
On Fri, Dec 13, 2013 at 02:23:26PM +0100, Andre Przywara wrote:
For migration to work we need to save (and later restore) the state of
each core's virtual generic timer.
Since this
On Fri, 2013-12-13 at 14:35 +, Carlos Rodrigues wrote:
Another test that i made was, if i have 1 vCPU the problem is
reproducible, but if i increase to 2 vCPU, the Windows Server reboot
without any problem.
Regards,
Can you try 1 vCPU without virtio-serial?
Thanks,
Vadim.
--
To
-Original Message-
From: Wood Scott-B07421
Sent: Saturday, December 14, 2013 2:33 AM
To: Alexey Kardashevskiy
Cc: linuxppc-...@lists.ozlabs.org; kvm@vger.kernel.org; linux-
ker...@vger.kernel.org; Alex Williamson; Paul Mackerras; David Gibson; Sethi
Varun-B16395; Bhushan
24 matches
Mail list logo
