[PATCH] kvm: kvmtrace: kvmtrace_format for supporting big_endian
From: Tan, Li [EMAIL PROTECTED] Currently kvmtrace is not portable, and prevent from copying a trace file from big-endian target to little-endian workstation for analysis. In the patch, kvmtrace_format reads and checks the magic number from trace log. if needed, then change bytes order of all fields in records followed. Signed-off-by: Tan Li [EMAIL PROTECTED] Signed-off-by: Avi Kivity [EMAIL PROTECTED] diff --git a/user/kvmtrace_format b/user/kvmtrace_format index 9e7cfd4..e6ec4e8 100755 --- a/user/kvmtrace_format +++ b/user/kvmtrace_format @@ -93,13 +93,14 @@ defs = read_defs(arg[0]) # tsc_in means TSC data exists(1) or not(0). # if tsc_in == 0, TSC(Q) does not exists. # -HDRREC = III -TSCREC = Q -D1REC = I -D2REC = II -D3REC = III -D4REC = -D5REC = I +HDRREC = III +TSCREC = Q +D1REC = I +D2REC = II +D3REC = III +D4REC = +D5REC = I +KMAGIC = I last_tsc = 0 @@ -108,6 +109,30 @@ i=0 while not interrupted: try: i=i+1 + +if i == 1: +line = sys.stdin.read(struct.calcsize(KMAGIC)) +if not line: +break +kmgc = struct.unpack(KMAGIC, line)[0] + +#firstly try to parse data file as little endian +# if kvmtrace-metadata.kmagic != kmagic +# then data file must be big endian +if kmgc != 0x12345678: +if kmgc != 0x78563412: +print sys.stderr, Bad data file: magic number error. +break; +else: +HDRREC = III +TSCREC = Q +D1REC = I +D2REC = II +D3REC = III +D4REC = +D5REC = I +continue + line = sys.stdin.read(struct.calcsize(HDRREC)) if not line: break -- To unsubscribe from this list: send the line unsubscribe kvm-commits in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] KVM: MMU: large page update_pte issue with non-PAE 32-bit guests (resend)
From: Marcelo Tosatti [EMAIL PROTECTED]
kvm_mmu_pte_write() does not handle 32-bit non-PAE large page backed
guests properly. It will instantiate two 2MB sptes pointing to the same
physical 2MB page when a guest large pte update is trapped.
Instead of duplicating code to handle this, disallow directory level
updates to happen through kvm_mmu_pte_write(), so the two 2MB sptes
emulating one guest 4MB pte can be correctly created by the page fault
handling path.
Signed-off-by: Marcelo Tosatti [EMAIL PROTECTED]
Signed-off-by: Avi Kivity [EMAIL PROTECTED]
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index c5def36..6324c42 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -1586,11 +1586,13 @@ static void mmu_pte_write_new_pte(struct kvm_vcpu *vcpu,
u64 *spte,
const void *new)
{
- if ((sp-role.level != PT_PAGE_TABLE_LEVEL)
-!vcpu-arch.update_pte.largepage) {
- ++vcpu-kvm-stat.mmu_pde_zapped;
- return;
- }
+ if (sp-role.level != PT_PAGE_TABLE_LEVEL) {
+ if (!vcpu-arch.update_pte.largepage ||
+ sp-role.glevels == PT32_ROOT_LEVEL) {
+ ++vcpu-kvm-stat.mmu_pde_zapped;
+ return;
+ }
+}
++vcpu-kvm-stat.mmu_pte_updated;
if (sp-role.glevels == PT32_ROOT_LEVEL)
--
To unsubscribe from this list: send the line unsubscribe kvm-commits in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] KVM: Do not calculate linear rip in emulation failure report
From: Glauber Costa [EMAIL PROTECTED] If we're not gonna do anything (case in which failure is already reported), we do not need to even bother with calculating the linear rip. Signed-off-by: Glauber Costa [EMAIL PROTECTED] Signed-off-by: Avi Kivity [EMAIL PROTECTED] diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 4f9..3698922 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -2032,11 +2032,11 @@ void kvm_report_emulation_failure(struct kvm_vcpu *vcpu, const char *context) unsigned long rip = vcpu-arch.rip; unsigned long rip_linear; - rip_linear = rip + get_segment_base(vcpu, VCPU_SREG_CS); - if (reported) return; + rip_linear = rip + get_segment_base(vcpu, VCPU_SREG_CS); + emulator_read_std(rip_linear, (void *)opcodes, 4, vcpu); printk(KERN_ERR emulation failed (%s) rip %lx %02x %02x %02x %02x\n, -- To unsubscribe from this list: send the line unsubscribe kvm-commits in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Revert KVM: VMX: Add mechanism to detect VMentry failure
From: Avi Kivity [EMAIL PROTECTED]
This reverts commit 36742c5470. Breaks guest rebooting.
Signed-off-by: Avi Kivity [EMAIL PROTECTED]
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 7729c2d..6e4278d 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -1294,8 +1294,7 @@ static void enter_pmode(struct kvm_vcpu *vcpu)
fix_pmode_dataseg(VCPU_SREG_GS, vcpu-arch.rmode.gs);
fix_pmode_dataseg(VCPU_SREG_FS, vcpu-arch.rmode.fs);
- if (vcpu-arch.rmode_failed)
- vmcs_write16(GUEST_SS_SELECTOR, 0);
+ vmcs_write16(GUEST_SS_SELECTOR, 0);
vmcs_write32(GUEST_SS_AR_BYTES, 0x93);
vmcs_write16(GUEST_CS_SELECTOR,
@@ -2676,70 +2675,6 @@ static int handle_nmi_window(struct kvm_vcpu *vcpu,
struct kvm_run *kvm_run)
return 1;
}
-static int invalid_guest_state(struct kvm_vcpu *vcpu,
- struct kvm_run *kvm_run, u32 failure_reason)
-{
- u16 ss, cs;
- u8 opcodes[4];
- unsigned long rip = vcpu-arch.rip;
- unsigned long rip_linear;
-
- ss = vmcs_read16(GUEST_SS_SELECTOR);
- cs = vmcs_read16(GUEST_CS_SELECTOR);
-
- if ((ss 0x03) != (cs 0x03)) {
- int err;
- rip_linear = rip + vmx_get_segment_base(vcpu, VCPU_SREG_CS);
- emulator_read_std(rip_linear, (void *)opcodes, 4, vcpu);
- err = emulate_instruction(vcpu, kvm_run, 0, 0, 0);
- switch (err) {
- case EMULATE_DONE:
- return 1;
- case EMULATE_DO_MMIO:
- printk(KERN_INFO mmio?\n);
- return 0;
- default:
- /* HACK: If we can not emulate the instruction
-* we write a sane value on SS to pass sanity
-* checks. The good thing to do is to emulate
the
-* instruction */
- kvm_report_emulation_failure(vcpu, vmentry
failure);
- printk(KERN_INFO= Quit real mode
emulation\n);
- vcpu-arch.rmode_failed = 1;
- vmcs_write16(GUEST_SS_SELECTOR, 0);
- return 1;
- }
- }
-
- kvm_run-exit_reason = KVM_EXIT_UNKNOWN;
- kvm_run-hw.hardware_exit_reason = failure_reason;
- return 0;
-}
-
-static int handle_vmentry_failure(struct kvm_vcpu *vcpu,
- struct kvm_run *kvm_run,
- u32 failure_reason)
-{
- unsigned long exit_qualification = vmcs_readl(EXIT_QUALIFICATION);
- switch (failure_reason) {
- case EXIT_REASON_INVALID_GUEST_STATE:
- return invalid_guest_state(vcpu, kvm_run,
failure_reason);
- case EXIT_REASON_MSR_LOADING:
- printk(VMentry failure caused by MSR entry %ld
loading.\n,
- exit_qualification);
- printk( ... Not handled\n);
- break;
- case EXIT_REASON_MACHINE_CHECK:
- printk(VMentry failure caused by machine check.\n);
- printk( ... Not handled\n);
- break;
- default:
- printk(reason not known yet!\n);
- break;
- }
- return 0;
-}
-
/*
* The exit handlers return 1 if the exit was handled fully and guest execution
* may resume. Otherwise they set the kvm_run parameter to indicate what needs
@@ -2802,12 +2737,6 @@ static int kvm_handle_exit(struct kvm_run *kvm_run,
struct kvm_vcpu *vcpu)
exit_reason != EXIT_REASON_EPT_VIOLATION))
printk(KERN_WARNING %s: unexpected, valid vectoring info and
exit reason is 0x%x\n, __func__, exit_reason);
-
- if ((exit_reason VMX_EXIT_REASONS_FAILED_VMENTRY)) {
- exit_reason = ~VMX_EXIT_REASONS_FAILED_VMENTRY;
- return handle_vmentry_failure(vcpu, kvm_run, exit_reason);
- }
-
if (exit_reason kvm_vmx_max_exit_handlers
kvm_vmx_exit_handlers[exit_reason])
return kvm_vmx_exit_handlers[exit_reason](vcpu, kvm_run);
diff --git a/arch/x86/kvm/vmx.h b/arch/x86/kvm/vmx.h
index 966460e..425a134 100644
--- a/arch/x86/kvm/vmx.h
+++ b/arch/x86/kvm/vmx.h
@@ -239,10 +239,7 @@ enum vmcs_field {
#define EXIT_REASON_IO_INSTRUCTION 30
#define EXIT_REASON_MSR_READ31
#define EXIT_REASON_MSR_WRITE 32
-#define EXIT_REASON_INVALID_GUEST_STATE 33
-#define EXIT_REASON_MSR_LOADING 34
#define EXIT_REASON_MWAIT_INSTRUCTION 36
-#define EXIT_REASON_MACHINE_CHECK 41
#define EXIT_REASON_TPR_BELOW_THRESHOLD 43
#define EXIT_REASON_APIC_ACCESS 44
[PATCH] KVM: Support mixed endian machines
From: Tan, Li [EMAIL PROTECTED]
Currently kvmtrace is not portable. This will prevent from copying a
trace file from big-endian target to little-endian workstation for analysis.
In the patch, kernel outputs metadata containing a magic number to trace
log, and changes 64-bit words to be u64 instead of a pair of u32s.
Signed-off-by: Tan Li [EMAIL PROTECTED]
Acked-by: Jerone Young [EMAIL PROTECTED]
Acked-by: Hollis Blanchard [EMAIL PROTECTED]
Signed-off-by: Avi Kivity [EMAIL PROTECTED]
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index 1c908ac..0ea064c 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -318,14 +318,14 @@ struct kvm_trace_rec {
__u32 vcpu_id;
union {
struct {
- __u32 cycle_lo, cycle_hi;
+ __u64 cycle_u64;
__u32 extra_u32[KVM_TRC_EXTRA_MAX];
} cycle;
struct {
__u32 extra_u32[KVM_TRC_EXTRA_MAX];
} nocycle;
} u;
-};
+} __attribute__((packed));
#define KVMIO 0xAE
diff --git a/virt/kvm/kvm_trace.c b/virt/kvm/kvm_trace.c
index 0e49547..58141f3 100644
--- a/virt/kvm/kvm_trace.c
+++ b/virt/kvm/kvm_trace.c
@@ -72,11 +72,7 @@ static void kvm_add_trace(void *probe_private, void
*call_data,
rec.cycle_in= p-cycle_in;
if (rec.cycle_in) {
- u64 cycle = 0;
-
- cycle = get_cycles();
- rec.u.cycle.cycle_lo = (u32)cycle;
- rec.u.cycle.cycle_hi = (u32)(cycle 32);
+ rec.u.cycle.cycle_u64 = get_cycles();
for (i = 0; i rec.extra_u32; i++)
rec.u.cycle.extra_u32[i] = va_arg(*args, u32);
@@ -114,8 +110,18 @@ static int kvm_subbuf_start_callback(struct rchan_buf
*buf, void *subbuf,
{
struct kvm_trace *kt;
- if (!relay_buf_full(buf))
+ if (!relay_buf_full(buf)) {
+ if (!prev_subbuf) {
+ /*
+* executed only once when the channel is opened
+* save metadata as first record
+*/
+ subbuf_start_reserve(buf, sizeof(u32));
+ *(u32 *)subbuf = 0x12345678;
+ }
+
return 1;
+ }
kt = buf-chan-private_data;
atomic_inc(kt-lost_records);
--
To unsubscribe from this list: send the line unsubscribe kvm-commits in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: qemu-send.c (was Re: Since we're sharing, here's my kvmctl script)
Javier Guerra Giraldez [EMAIL PROTECTED] writes: On Wednesday 11 June 2008, Chris Webb wrote: Hi. I have a small 'qemu-send' utility for talking to a running qemu/kvm process whose monitor console listens on a filesystem socket, which I think might be a useful building block when extending these kinds of script to do things like migratation, pausing, and so on. The source is attached. there's a utility called socat that let's you send text to/from TCP sockets and unix-domain sockets. it can even (temporarily) attach the terminal, or use GNU's readline to regain interactive control of KVM/Qemu Hi. Yes, I'm aware of socat, netcat, tcpclient et al. and even have a similar pair of little unix/tcp/udp/syslogging utilities myself called sk/skd which I initially used for scripting our local kvm management system. However, it's a little bit clumsy to use these tools correctly from a shell script if you want to get back the command output intact. You need to open your connection to the unix server socket, wait for the prompt (skipping the welcome banner), send the command, copy the response out until you get a line '(qemu) ', then disconnect. For the same reason you can't do echo -e GET / HTTP/1.1\n\n /dev/tcp/www.google.com/80 cat /dev/tcp/www.google.com/80 having to write exec 3/dev/tcp/www.google.com/80 echo -e GET / HTTP/1.1\n\n 3 cat 3 instead, you need to avoid disconnecting from the socket in the middle of the command/response exchange. (In fact, with qemu, it nearly works anyway: the new connection gets all the output and the next prompt from the old one before the new banner, so you just have a couple of extra prompts, a command echo and a banner at the top and bottom to filter away. However, I'd be very reluctant to rely on this behaviour, and in particular on it not losing output between connections. The method I implemented in qemu-send.c should be robust again changes in the way qemu handles its monitor sockets.) To get the convenient syntax and behaviour I wanted, it felt easier and cleaner to write the few lines of C needed for a standalone utility rather than introduce a parsing shell script/function plus a dependency on one of sk/socat/netcat/tcpclient. I suspect also that I'm just more comfortable in C than sh; YMMV! Cheers, Chris. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Since we're sharing, here's my kvmctl script
On Wed, Jun 11, 2008 at 09:07:49PM -0500, Javier Guerra Giraldez wrote:
On Wednesday 11 June 2008, Freddie Cash wrote:
The script can be run as a normal user, as it will use sudo where
needed. However, this causes all the VMs to be run as root (this is
developed on Debian where they've added that annoying feature of not
being able to create/use tun/tap devices as non-root users). If
anyone knows how to unbreak Debian to allow non-root users to create
tun/tap devices, I'm all ears.
change the group, owner, and/or privileges of /dev/net/tun, usually maneged
by
udev
This won't help with recent kernels as you need CAP_NET_ADMIN to create
a device. I use tunctl which is part of uml-utilities in Debian to create
the network device and then pass it to qemu with ifname.
e.g
USER=kvm
NAME=test
IFACE=tap${NAME}
IFACE=$(sudo $TUNCTL -b -u $USER -t ${IFACE})
qemu-system-x86_64 ... -net tap,script=/etc/qemu-ifup,ifname=${IFACE}
bill
--
Bill Boughton
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM: only abort guest entry if timer count goes from 0-1
Marcelo Tosatti wrote:
Only abort guest entry if the timer count went from 0-1, since for 1-2
or larger the bit will either be set already or a timer irq will have
been injected.
Using atomic_inc_and_test() for it also introduces an SMP barrier
to the LAPIC version (thought it was unecessary because of timer
migration, but guest can be scheduled to a different pCPU between exit
and kvm_vcpu_block(), so there is the possibility for a race).
Noticed by Avi.
Applied, thanks.
diff --git a/arch/x86/kvm/i8254.c b/arch/x86/kvm/i8254.c
index 9e3391e..c0f7872 100644
--- a/arch/x86/kvm/i8254.c
+++ b/arch/x86/kvm/i8254.c
@@ -198,14 +198,11 @@ static int __pit_timer_fn(struct kvm_kpit_state *ps)
struct kvm_vcpu *vcpu0 = ps-pit-kvm-vcpus[0];
struct kvm_kpit_timer *pt = ps-pit_timer;
- atomic_inc(pt-pending);
- smp_mb__after_atomic_inc();
- if (vcpu0) {
+ if (!atomic_inc_and_test(pt-pending))
set_bit(KVM_REQ_PENDING_TIMER, vcpu0-requests);
- if (waitqueue_active(vcpu0-wq)) {
- vcpu0-arch.mp_state = KVM_MP_STATE_RUNNABLE;
- wake_up_interruptible(vcpu0-wq);
- }
+ if (vcpu0 waitqueue_active(vcpu0-wq)) {
+ vcpu0-arch.mp_state = KVM_MP_STATE_RUNNABLE;
+ wake_up_interruptible(vcpu0-wq);
}
Semi-related: what business does the timer have waking up vcpu0? The
timer pin may be masked, or routed via the ioapic to vcpu13. The code
here needs to touch irq pin 0, not wake up random vcpus.
It can't do that immediately since we're in interrupt context and we
can't take the appropriate locks. So we need to go through a
workqueue. There's some code for this in the pci device assignment
code, so we can just use that when it is merged.
Longer term we need to give the pic and ioapic their own locking, likely
with spin_lock_irq() so we can touch them from interrupt context.
index 180ba73..73f43de 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -945,8 +945,8 @@ static int __apic_timer_fn(struct kvm_lapic *apic)
int result = 0;
wait_queue_head_t *q = apic-vcpu-wq;
- atomic_inc(apic-timer.pending);
- set_bit(KVM_REQ_PENDING_TIMER, apic-vcpu-requests);
+ if(!atomic_inc_and_test(apic-timer.pending))
+ set_bit(KVM_REQ_PENDING_TIMER, apic-vcpu-requests);
if (waitqueue_active(q)) {
apic-vcpu-arch.mp_state = KVM_MP_STATE_RUNNABLE;
wake_up_interruptible(q);
The wakeup is okay since lapic is handled by its vcpu. But do we need
to change the mpstate? The lapic code should do that, if it determines
that an interrupt is actually generated.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] kvm-ia64 irq assignment 1/2 kernel
Alexander Graf wrote: Apparently this is broken on x86 too. I was just trying this patch with Mac OS X as target and magically the in-kernel APIC starts working, so I guess something is going wrong already here. Btw, according to the ACPI tables, all PCI interrupts are currently defined Active-Low. So there's something else wrong. Sorry, ActiveHigh that is. Nevertheless I am having trouble with this since the very first time I used osx inside KVM. Does PCI allow Active Interrupt (, Level, ActiveHigh, Shared) According to the PCI 3.0 Spec, Interrupts on PCI are optional and defined as 'level sensitive,' asserted low (negative true). The pci interrupts are active low, but they are converted to active high by the chipset qemu emulates, so active high is correct. Does OS X boot from the qemu bios or something else? If the latter, it may need adjustment. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC]RE: [PATCH] kvm-ia64 irq assignment 1/2 kernel
Xu, Anthony wrote:
Thanks for comments
Basically we are on the same page, while I didn't find your patch about
irq assignment, can you post it in this thread again, thx?
Below patch makes all PCI devices use level-trigger , active low
interrupt, it worked well when running linux guest, I didn't try windows
guest yet.
(didn't have windows image in hand)
Please comment!
If this is acceptabled, we can figure out how to use IOAPIC in kvm/ia32
based on this. Which will reduce irq sharing dramatically.
Thanks,
Anthony
diff --git a/bios/acpi-dsdt.dsl b/bios/acpi-dsdt.dsl
index 21fc76a..4b5e824 100755
--- a/bios/acpi-dsdt.dsl
+++ b/bios/acpi-dsdt.dsl
@@ -974,7 +974,7 @@ DefinitionBlock (
Name(_HID, EISAID(PNP0C0F)) // PCI interrupt link
Name(_UID, 1)
Name(_PRS, ResourceTemplate(){
-Interrupt (, Level, ActiveHigh, Shared)
+Interrupt (, Level, ActiveLow, Shared)
{ 5, 10, 11 }
I think this will fail for guests which use the PIC, since the PIC is
always active high.
For x86 the interrupts will have to be active high since that's how piix
works.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] kvm: kvmtrace: kvmtrace_format for supporting big_endian
Tan, Li wrote: Avi, Do you have any comments? No, just overloaded. Thanks for the reminder. Subject: [PATCH] [PATCH] kvm: kvmtrace: kvmtrace_format for supporting big_endian Currently kvmtrace is not portable, and prevent from copying a trace file from big-endian target to little-endian workstation for analysis. In the patch, kvmtrace_format reads and checks the magic number from trace log. if needed, then change bytes order of all fields in records followed. Applied, thanks. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: unhandled vm exit and machine locks up
Martin Michlmayr wrote: I was reading email in my kvm instance when suddenly it was terminated and my whole laptop locked-up hard. I saw unhandled vm exit: 0x8021 vcpu_id0 and a bunch of register info that can be found at http://www.cyrius.com/tmp/kvm.jpg Does this give any information why kvm was terminated and my whole machine locked-up? I'm running 2.6.25 on x86_64 with kvm-intel and kvm version 60. The CPU is Intel(R) Core(TM)2 Duo CPU U7600 @ 1.20GHz. The kvm instance is a 32 bit x86 installation. Both running Debian. It looks like host state leaked into the guest state. The register state is consistent with a 64-bit guest, while you're running a 32-bit guest. The guest EFER is still consistent with a 32-bit guest, which is why you got the abort. Presumably some guest state also leaked into the host, which is why the host locked up. Can you post your .config? were you running more than one guest on the machine? were you running a debugger concurrently? anything else out of the ordinary? do you recall the exact phase of the moon? -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] kvm-s390: userspace snapshot
Am Donnerstag, 12. Juni 2008 schrieb Oliver Paukstadt:
On Thu, 2008-06-12 at 00:14 +0200, Christian Borntraeger wrote:
Ok, I got an idea.
Does that patch fix the handle_should_not_happen PANIC?
Patch does not fit, because my code contains
vcpu-arch.sie_block-gmsor = 0x;
so I changed this before I applied the patch.
The console patch you mentioned was applied too.
Now I am able to get the kernel running a little further:
good. I will make this patch proper and send it to Avi.
PID hash table entries: 256 (order: 8, 2048 bytes)
console [hvc0] enabled
sclp vt220 tty driver: could not register vt220 - sclp_register returned
-5
list_del corruption. prev-next should be 003d72a8, but was
Yes, Carsten ran into that as well, when we changed from vt220 to
virtio_console. Looks like the vt220 driver doesnt like it, when there is no
sclp available.
A fix is upstream in Linus git since yesterday:
commit 7b439d25300dc59bba76b53eb344bb9e5a1133f2
Author: Carsten Otte [EMAIL PROTECTED]
Date: Tue Jun 10 10:03:22 2008 +0200
[S390] vt220 console, initialize list head before use
[...]
diff --git a/drivers/s390/char/sclp_vt220.c b/drivers/s390/char/sclp_vt220.c
index 62576af..3e577f6 100644
--- a/drivers/s390/char/sclp_vt220.c
+++ b/drivers/s390/char/sclp_vt220.c
@@ -773,6 +773,7 @@ sclp_vt220_con_init(void)
{
int rc;
+ INIT_LIST_HEAD(sclp_vt220_register.list);
if (!CONSOLE_IS_SCLP)
return 0;
rc = __sclp_vt220_init();
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Since we're sharing, here's my kvmctl script
On Wed, Jun 11, 2008 at 4:04 PM, Freddie Cash [EMAIL PROTECTED] wrote: On Wed, Jun 11, 2008 at 3:52 PM, Freddie Cash [EMAIL PROTECTED] wrote: For everyone's viewing (and critiquing, I guess) pleasure, I present my version of a kvmctl script. [snip] It's released under the BSD License, so do with it as you wish. :) Patches and suggestions are always welcome, of course. http://www.sd73.bc.ca/downloads/kvmctl-2.0.0.tbz Of course, right after sending that, I find a bunch of issues with it. So, grab the new tarball, if you're interested: http://www.sd73.bc.ca/downloads/kvmctl-2.0.1.tbz And one more refresh. http://www.sd73.bc.ca/downloads/kvmctl-2.0.2.tbz -- Freddie Cash [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC]RE: [PATCH] kvm-ia64 irq assignment 1/2 kernel
Alexander Graf wrote:
On Jun 10, 2008, at 12:57 AM, Xu, Anthony wrote:
Thanks for comments
Basically we are on the same page, while I didn't find your patch
about irq assignment, can you post it in this thread again, thx?
I'll attach it to this mail.
This patch is stilling use legacy LNKA~LNKD for ioapic,
As you said irq-pins 15 are not used.
Below patch makes all PCI devices use level-trigger , active low
interrupt, it worked well when running linux guest, I didn't try
windows guest yet.
(didn't have windows image in hand)
Please comment!
If this is acceptabled, we can figure out how to use IOAPIC in kvm/
ia32 based on this. Which will reduce irq sharing dramatically.
Thanks,
Anthony
diff --git a/bios/acpi-dsdt.dsl b/bios/acpi-dsdt.dsl
index 21fc76a..4b5e824 100755
--- a/bios/acpi-dsdt.dsl
+++ b/bios/acpi-dsdt.dsl
@@ -974,7 +974,7 @@ DefinitionBlock (
Name(_HID, EISAID(PNP0C0F)) // PCI interrupt
link Name(_UID, 1)
Name(_PRS, ResourceTemplate(){
-Interrupt (, Level, ActiveHigh, Shared)
+Interrupt (, Level, ActiveLow, Shared)
This looks pretty much correct to me ;-). You might also want to add
the GSI functionality I have in my patch. The only thing we have not
discussed so far is, how do interrupts get routed when _PIC is not set
to 1, aka the boot case?
Here Avi is correct,
PIC only support activehigh level-triggered interrupt. From spec, PCI
device uses activelow level-triggered interrupt.
I guess it is interrupt Link to reverse it.
{ 5, 10, 11 }
})
Method (_STA, 0, NotSerialized)
[...snip...]
diff --git a/qemu/hw/pci.c b/qemu/hw/pci.c
index a23a466..df0ea33 100644
--- a/qemu/hw/pci.c
+++ b/qemu/hw/pci.c
@@ -548,7 +548,7 @@ static void pci_set_irq(void *opaque, int
irq_num, int level) pci_dev = bus-parent_dev;
}
bus-irq_count[irq_num] += change;
-bus-set_irq(bus-irq_opaque, irq_num, bus-irq_count[irq_num]
!= 0); +bus-set_irq(bus-irq_opaque, irq_num, !(bus-
irq_count[irq_num] !=
0));
}
I don't think this is the right place to do it. Probably it would be a
better idea to have either the APIC emulation know that the levels are
reversed or make every device trigger ActiveLow interrupts.
Maybe it not a right place:-)
Making every device trigger activelow interrupt introduce a lot of
modifications, it's last resort.
APIC emulation is inside kernel now, it is not a good idea to introduce
qemu-special piece of code into kernel as Avi mentioned.
Thanks.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0 of 2] Enable other archs to build kvmtrace tool
These patches fix up the build system in the /user dircectory so that other archs (besides x86) can build the kvm-trace tool. Signed-off-by: Jerone Young [EMAIL PROTECTED] 3 files changed, 3 insertions(+), 2 deletions(-) user/Makefile |2 ++ user/config-powerpc.mak|2 +- user/config-x86-common.mak |1 - -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2 of 2] kvmtrace tool build by default for powerpc
1 file changed, 1 insertion(+), 1 deletion(-) user/config-powerpc.mak |2 +- Patch adds kvmtrace to standard build in /user diretory for powerpc. Signed-off-by: Jerone Young [EMAIL PROTECTED] diff --git a/user/config-powerpc.mak b/user/config-powerpc.mak --- a/user/config-powerpc.mak +++ b/user/config-powerpc.mak @@ -18,7 +18,7 @@ testobjs := \ tests := $(addprefix test/powerpc/, $(testobjs)) -all: kvmctl $(tests) +all: kvmtrace kvmctl $(tests) kvmctl_objs = main-ppc.o iotable.o ../libkvm/libkvm.a -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1 of 2] Fix building of kvmtrace tool for all archs
2 files changed, 2 insertions(+), 1 deletion(-) user/Makefile |2 ++ user/config-x86-common.mak |1 - $(kvmtrace_objs) is defined in config-x86-common.mak. This needs to be moved to the common Makefile so everyone can build it. Also it is just one c file as opposed to multiple diffrering c files as with kvmctl. Signed-off-by: Jerone Young [EMAIL PROTECTED] diff --git a/user/Makefile b/user/Makefile --- a/user/Makefile +++ b/user/Makefile @@ -33,6 +33,8 @@ autodepend-flags = -MMD -MF $(dir $*).$( LDFLAGS += -pthread -lrt +kvmtrace_objs= kvmtrace.o + kvmctl: $(kvmctl_objs) $(CC) $(LDFLAGS) $^ -o $@ diff --git a/user/config-x86-common.mak b/user/config-x86-common.mak --- a/user/config-x86-common.mak +++ b/user/config-x86-common.mak @@ -3,7 +3,6 @@ all: kvmctl kvmtrace test_cases all: kvmctl kvmtrace test_cases kvmctl_objs= main.o iotable.o ../libkvm/libkvm.a -kvmtrace_objs= kvmtrace.o balloon_ctl: balloon_ctl.o FLATLIBS = $(TEST_DIR)/libcflat.a $(libgcc) -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC]RE: [PATCH] kvm-ia64 irq assignment 1/2 kernel
Marcelo Tosatti wrote: On Tue, Jun 10, 2008 at 03:57:30PM +0800, Xu, Anthony wrote: diff --git a/qemu/hw/pci.c b/qemu/hw/pci.c index a23a466..df0ea33 100644 --- a/qemu/hw/pci.c +++ b/qemu/hw/pci.c @@ -548,7 +548,7 @@ static void pci_set_irq(void *opaque, int irq_num, int level) pci_dev = bus-parent_dev; } bus-irq_count[irq_num] += change; -bus-set_irq(bus-irq_opaque, irq_num, bus-irq_count[irq_num] != 0); +bus-set_irq(bus-irq_opaque, irq_num, !(bus-irq_count[irq_num] != 0)); } Ideally this should detect if the PCI interrupts are active low or high and act accordingly (so that older BIOSes still work and no assumptions are made). Will probably have to be done anyway for merging into QEMU. As I mentioned before, all PCI devices in Qemu used active high level-triggerred interrupt. While IOAPIC pin with fixed connection to slot uses active low level-triggerred interrupt by default. Seems we need to find a place to reverse it. One way of doing it would be to talk to ACPI via a new SystemIO region, but there must be an easier way. Good point, qemu needs to know whether it is in PIC mode or in APIC mode. We need define the communication mechanism, SystemIO region is one choice. Thanks, Anthony -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC]RE: [PATCH] kvm-ia64 irq assignment 1/2 kernel
Avi Kivity wrote:
Xu, Anthony wrote:
Thanks for comments
Basically we are on the same page, while I didn't find your patch
about irq assignment, can you post it in this thread again, thx?
Below patch makes all PCI devices use level-trigger , active low
interrupt, it worked well when running linux guest, I didn't try
windows guest yet. (didn't have windows image in hand)
Please comment!
If this is acceptabled, we can figure out how to use IOAPIC in
kvm/ia32 based on this. Which will reduce irq sharing dramatically.
Thanks,
Anthony
diff --git a/bios/acpi-dsdt.dsl b/bios/acpi-dsdt.dsl
index 21fc76a..4b5e824 100755
--- a/bios/acpi-dsdt.dsl
+++ b/bios/acpi-dsdt.dsl
@@ -974,7 +974,7 @@ DefinitionBlock (
Name(_HID, EISAID(PNP0C0F)) // PCI interrupt
link Name(_UID, 1)
Name(_PRS, ResourceTemplate(){
-Interrupt (, Level, ActiveHigh, Shared)
+Interrupt (, Level, ActiveLow, Shared)
{ 5, 10, 11 }
I think this will fail for guests which use the PIC, since the PIC is
always active high.
For x86 the interrupts will have to be active high since that's how
piix works.
Understand this concern.
Anthony
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] kvm irq assignment
Hi all,
Thanks for your comments.
I made this new patch based on your comments
1. use bimodal _PRT, to take advantage of IOAPIC pin 16~23
the mapping is simple, slot - (slot7)+16 IOAPIC pin,
someone may provide good mapping ?
2. use ISA-bridge configure space 0x64 byte as a communication
mechansim.
When guest BIOS invokes _PIC, the value is passed to qemu
through byte 0x64.
qemu know whether it is PIC mode and APIC mode by checking
byte 0x64.
3. pci_slot_get_pirq and piix3_set_irq adopt different operation based
on PIC mode/APIC mode
4. All pci devices are still using active high level-triggered
interrupt, while IOAPIC pin 16~23 use active low level-triggered
interrupt.
piix3_set_irq is responsible to reserve the level if it is in APIC
mode.
5. interrupt sharing for PCI devices is still supported
Test by runing guest linux, NIC is using IOAPIC pin 15
0: 980211IO-APIC-edge timer
1:179IO-APIC-edge i8042
8: 0IO-APIC-edge rtc
9: 0 IO-APIC-level acpi
12:289IO-APIC-edge i8042
14: 3266IO-APIC-edge ide0
15: 13489IO-APIC-edge ide1
185:485 IO-APIC-level eth0
Didn't try guest linux only with PIC, I think it works, because the path
for PIC is not changed at all.
Please comment!
Thanks,
Anthony
diff --git a/bios/acpi-dsdt.dsl b/bios/acpi-dsdt.dsl
index 21fc76a..64219f2 100755
--- a/bios/acpi-dsdt.dsl
+++ b/bios/acpi-dsdt.dsl
@@ -201,14 +201,24 @@ DefinitionBlock (
}
}
+Name (PICD, 0)
-/* PCI Bus definition */
+
+/*PCI Bus definition */
Scope(\_SB) {
Device(PCI0) {
Name (_HID, EisaId (PNP0A03))
Name (_ADR, 0x00)
Name (_UID, 1)
-Name(_PRT, Package() {
+
+Method(_PRT,0){
+If(PICD){
+Return(PRTA)
+}
+Return(PRTP)
+}
+
+Name(PRTP, Package() {
/* PCI IRQ routing table, example from ACPI 2.0a
specification,
section 6.2.8.1 */
/* Note: we provide the same info as the PCI routing
@@ -407,6 +417,202 @@ DefinitionBlock (
Package() {0x001f, 3, LNKB, 0},
})
+Name(PRTA, Package() {
+/* IOAPIC use fixed connection */
+
+// PCI Slot 0
+Package() {0x, 0, 0, 16},
+Package() {0x, 1, 0, 16},
+Package() {0x, 2, 0, 16},
+Package() {0x, 3, 0, 16},
+
+// PCI Slot 1
+Package() {0x0001, 0, 0, 17},
+Package() {0x0001, 1, 0, 17},
+Package() {0x0001, 2, 0, 17},
+Package() {0x0001, 3, 0, 17},
+
+// PCI Slot 2
+Package() {0x0002, 0, 0, 18},
+Package() {0x0002, 1, 0, 18},
+Package() {0x0002, 2, 0, 18},
+Package() {0x0002, 3, 0, 18},
+
+// PCI Slot 3
+Package() {0x0003, 0, 0, 19},
+Package() {0x0003, 1, 0, 19},
+Package() {0x0003, 2, 0, 19},
+Package() {0x0003, 3, 0, 19},
+
+// PCI Slot 4
+Package() {0x0004, 0, 0, 20},
+Package() {0x0004, 1, 0, 20},
+Package() {0x0004, 2, 0, 20},
+Package() {0x0004, 3, 0, 20},
+
+// PCI Slot 5
+Package() {0x0005, 0, 0, 21},
+Package() {0x0005, 1, 0, 21},
+Package() {0x0005, 2, 0, 21},
+Package() {0x0005, 3, 0, 21},
+
+// PCI Slot 6
+Package() {0x0006, 0, 0, 22},
+Package() {0x0006, 1, 0, 22},
+Package() {0x0006, 2, 0, 22},
+Package() {0x0006, 3, 0, 22},
+
+// PCI Slot 7
+Package() {0x0007, 0, 0, 23},
+Package() {0x0007, 1, 0, 23},
+Package() {0x0007, 2, 0, 23},
+Package() {0x0007, 3, 0, 23},
+
+// PCI Slot 8
+Package() {0x0008, 0, 0, 16},
+Package() {0x0008, 1, 0, 16},
+Package() {0x0008, 2, 0, 16},
+Package() {0x0008, 3, 0, 16},
+
+// PCI Slot 9
+Package() {0x0009, 0, 0, 17},
+Package() {0x0009, 1, 0, 17},
+Package() {0x0009, 2, 0, 17},
+Package() {0x0009, 3, 0, 17},
+
+// PCI Slot 10
+Package() {0x000a, 0, 0, 18},
+Package() {0x000a, 1, 0, 18},
+Package() {0x000a, 2, 0, 18},
+Package() {0x000a, 3, 0,
[ kvm-Bugs-1935481 ] unhandled vm exit: 0x80000021 vcpu_id 0
Bugs item #1935481, was opened at 2008-04-05 11:37 Message generated for change (Comment added) made by nilaab You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=1935481group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: intel Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Balaji Rao R (balajirrao) Assigned to: Nobody/Anonymous (nobody) Summary: unhandled vm exit: 0x8021 vcpu_id 0 Initial Comment: Win Vista Ultimate 32 bit does not work. It works fine with -no-kvm. No problems during installation. Problem surfaces only on first boot. bash-3.2# qemu-system-x86_64 -m 1536 -hda vista.img unhandled vm exit: 0x8021 vcpu_id 0 rax 0010 rbx 0080 rcx rdx 0080 rsi 0026b238 rdi 0008b238 rsp 0200 rbp 1f20 r8 r9 r10 r11 r12 r13 r14 r15 rip 009b rflags 00023002 cs b000 (002b/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) ds 0020 (0200/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) es 0020 (0200/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) ss 0020 (0200/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) fs 0020 (0200/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) gs 0020 (0200/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) tr (fffbd000/2088 p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) ldt (/ p 1 dpl 0 db 0 s 0 type 2 l 0 g 0 avl 0) gdt 2b/27 idt 0/3ff cr0 10 cr2 0 cr3 0 cr4 0 cr8 0 efer 0 Aborted -- Comment By: Adam Hough (nilaab) Date: 2008-06-12 12:18 Message: Logged In: YES user_id=2116547 Originator: NO Could this bug be similar to what I am seeing in Fedora 9 with a PAE enabled kernel? https://bugzilla.redhat.com/show_bug.cgi?id=451035 -- Comment By: Justin Keogh (jakeogh) Date: 2008-05-05 00:57 Message: Logged In: YES user_id=2079304 Originator: NO I got the same error with kvm-67 on: Linux xeonbox 2.6.25-gentoo-r1 #14 SMP Mon May 5 03:46:09 MST 2008 x86_64 Intel(R) Xeon(R) CPU X5482 @ 3.20GHz GenuineIntel GNU/Linux guest: windows vista ultimate 32bit... crash happens on first boot after install. -no-acapi didnt help. -no-kvm works. -- Comment By: Balaji Rao R (balajirrao) Date: 2008-04-06 09:22 Message: Logged In: YES user_id=1958935 Originator: YES Thats weird. Let me try, I'm working to fix it, or atleast to understand the problem better. -- Comment By: Technologov (technologov) Date: 2008-04-06 09:04 Message: Logged In: YES user_id=1839746 Originator: NO Unreproducible. -Alexey Technologov. -- Comment By: Balaji Rao R (balajirrao) Date: 2008-04-06 08:58 Message: Logged In: YES user_id=1958935 Originator: YES I'm not sure if its a regression. The first time ever I installed and tried booting vista, it wouldn't run. -- Comment By: Avi Kivity (avik) Date: 2008-04-06 08:34 Message: Logged In: YES user_id=539971 Originator: NO Is this a regression? If so, which kvm version worked last? I've successfully installed and booted Vista in the past. -- Comment By: Balaji Rao R (balajirrao) Date: 2008-04-05 14:26 Message: Logged In: YES user_id=1958935 Originator: YES Some critical facts i missed.. Host : Intel I forgot to mention the version too! KVM : kvm-64-210-g78e0016 kvm-userspace : kvm-64-18-gd84f71a -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=1935481group_id=180599 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] kvm irq assignment
Xu, Anthony wrote:
Hi all,
Thanks for your comments.
I made this new patch based on your comments
1. use bimodal _PRT, to take advantage of IOAPIC pin 16~23
the mapping is simple, slot - (slot7)+16 IOAPIC pin,
someone may provide good mapping ?
I think it's fine. If we find a better one later, or if we add another
ioapic, we can easily change it since the bios and qemu are shipped as a
unit.
2. use ISA-bridge configure space 0x64 byte as a communication
mechansim.
When guest BIOS invokes _PIC, the value is passed to qemu
through byte 0x64.
qemu know whether it is PIC mode and APIC mode by checking
byte 0x64.
3. pci_slot_get_pirq and piix3_set_irq adopt different operation based
on PIC mode/APIC mode
I'm not sure how real hardware works, but I _think_ that it routes irqs
unconditionally to both the legacy path and directly to the ioapic. So
for example if slot 5 asserts an interrupt, we map it through the pci
link mapping and generate an active high interrupt to one of {5, 10, 11}
(both pic and ioapic), and simultaneously an active low interrupt to
ioapic pin 21.
The _PIC method should disable the link interrupts if ioapic mode is
disabled.
This removes the need for communication between the bios and qemu.
+/* APIC and PIC flag */
+OperationRegion (P40D, PCI_Config, 0x64, 0x01)
+
This is actually SERIRQC, serial irq control.
+
+#ifdef KVM_CAP_IRQCHIP
This should be unconditional.
+static int pci_slot_get_pirq(PCIDevice *pci_dev, int irq_num)
+{
+int slot_addend;
+if( piix3_dev-config[0x64]) // APIC mode
+return ((pci_dev-devfn 3) 7)+16;
+else { // PIC mode
+slot_addend = (pci_dev-devfn 3) - 1;
+return (irq_num + slot_addend) 3;
+}
+}
What I'm suggesting is to fork the interrupt into two lines, one
legacy path and the ioapic path.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
