Re: [kvm-devel] kvm-65/66 bug with Solaris 10 U4 ?
Ian Kirk wrote: 2.6.24.4-64.fc8PAE noexec=off: Using normal F8 modules qemu-kvm dies in the same way 2. Loading the kernel modules that come with kvm-66 Against 2.6.24.4-64.fc8 it works. 2.6.24.4-64.fc8PAE with kvm-66 module seems to work OK. I guess that solves that little problem? I intend to upgrade my other AMD machine to 4GB (which is at home, as opposed to at work) so I can properly test the various combinations to check it's fixed in kvm-66 (or somewhere after the bundled Fedora 8 one) Ian. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 1/1] Enble a guest to access a device's memory mapped I/O regions directly.
On Fri, Apr 18, 2008 at 06:50:03PM +0300, Avi Kivity wrote:
[EMAIL PROTECTED] wrote:
From: Ben-Ami Yassour [EMAIL PROTECTED]
Signed-off-by: Ben-Ami Yassour [EMAIL PROTECTED]
Signed-off-by: Muli Ben-Yehuda [EMAIL PROTECTED]
---
arch/x86/kvm/mmu.c | 59
+--
arch/x86/kvm/paging_tmpl.h | 19 +
include/linux/kvm_host.h |2 +-
virt/kvm/kvm_main.c| 17 +++-
4 files changed, 69 insertions(+), 28 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 078a7f1..c89029d 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -112,6 +112,8 @@ static int dbg = 1;
#define PT_FIRST_AVAIL_BITS_SHIFT 9
#define PT64_SECOND_AVAIL_BITS_SHIFT 52
+#define PT_SHADOW_IO_MARK (1ULL PT_FIRST_AVAIL_BITS_SHIFT)
+
Please rename this PT_SHADOW_MMIO_MASK.
Sure thing.
#define VALID_PAGE(x) ((x) != INVALID_PAGE)
#define PT64_LEVEL_BITS 9
@@ -237,6 +239,9 @@ static int is_dirty_pte(unsigned long pte)
static int is_rmap_pte(u64 pte)
{
+ if (pte PT_SHADOW_IO_MARK)
+ return false;
+
return is_shadow_present_pte(pte);
}
Why avoid rmap on mmio pages? Sure it's unnecessary work, but
having less cases improves overall reliability.
The rmap functions already have a check to bail out if the pte is not
an rmap pte, so in that sense, we aren't adding a new case for the
code to handle, just adding direct MMIO ptes to the existing list of
non-rmap ptes.
You can use pfn_valid() in gfn_to_pfn() and kvm_release_pfn_*() to
conditionally update the page refcounts.
Since rmap isn't useful for direct MMIO ptes, doesn't it make more
sense to bail out early rather than in the bowls of the rmap code?
Chag Same'ach
Muli
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 1/1] Enble a guest to access a device's memory mapped I/O regions directly.
On Fri, Apr 18, 2008 at 06:56:41PM +0300, Avi Kivity wrote:
[EMAIL PROTECTED] wrote:
From: Ben-Ami Yassour [EMAIL PROTECTED]
Signed-off-by: Ben-Ami Yassour [EMAIL PROTECTED]
Signed-off-by: Muli Ben-Yehuda [EMAIL PROTECTED]
---
libkvm/libkvm.c | 24
qemu/hw/pci-passthrough.c | 89
+++--
qemu/hw/pci-passthrough.h |2 +
3 files changed, 40 insertions(+), 75 deletions(-)
diff --git a/libkvm/libkvm.c b/libkvm/libkvm.c
index de91328..8c02af9 100644
--- a/libkvm/libkvm.c
+++ b/libkvm/libkvm.c
@@ -400,7 +400,7 @@ void *kvm_create_userspace_phys_mem(kvm_context_t kvm,
unsigned long phys_start,
{
int r;
int prot = PROT_READ;
- void *ptr;
+ void *ptr = NULL;
struct kvm_userspace_memory_region memory = {
.memory_size = len,
.guest_phys_addr = phys_start,
@@ -410,16 +410,24 @@ void *kvm_create_userspace_phys_mem(kvm_context_t
kvm, unsigned long phys_start,
if (writable)
prot |= PROT_WRITE;
- ptr = mmap(NULL, len, prot, MAP_ANONYMOUS | MAP_SHARED, -1, 0);
- if (ptr == MAP_FAILED) {
- fprintf(stderr, create_userspace_phys_mem: %s,
strerror(errno));
- return 0;
- }
+ if (len 0) {
+ ptr = mmap(NULL, len, prot, MAP_ANONYMOUS | MAP_SHARED, -1, 0);
+ if (ptr == MAP_FAILED) {
+ fprintf(stderr, create_userspace_phys_mem: %s,
+ strerror(errno));
+ return 0;
+ }
- memset(ptr, 0, len);
+ memset(ptr, 0, len);
+ }
memory.userspace_addr = (unsigned long)ptr;
- memory.slot = get_free_slot(kvm);
+
+ if (len 0)
+ memory.slot = get_free_slot(kvm);
+ else
+ memory.slot = get_slot(phys_start);
+
r = ioctl(kvm-vm_fd, KVM_SET_USER_MEMORY_REGION, memory);
if (r == -1) {
fprintf(stderr, create_userspace_phys_mem: %s,
strerror(errno));
This looks like support for zero-length memory slots? Why is it
needed?
It needs to be in a separate patch.
We need an interface to remove a memslot. When the guest writes to a
direct assigned device's BAR and changes an MMIO region, we need to
remove the old slot and establish a new one. The kernel side treats
0-sized memslot as remove, but the userspace side didn't quite
handle it properly.
Personally I would've preferred a proper remove interface, rather
than shoehorning it into kvm_create_userspace_phys_mem and a 0-sized
slot. If that's acceptable, we'll put together a patch.
diff --git a/qemu/hw/pci-passthrough.c b/qemu/hw/pci-passthrough.c
index 7ffcc7b..a5894d9 100644
--- a/qemu/hw/pci-passthrough.c
+++ b/qemu/hw/pci-passthrough.c
@@ -25,18 +25,6 @@ typedef __u64 resource_size_t;
extern kvm_context_t kvm_context;
extern FILE *logfile;
-CPUReadMemoryFunc *pt_mmio_read_cb[3] = {
- pt_mmio_readb,
- pt_mmio_readw,
- pt_mmio_readl
-};
-
-CPUWriteMemoryFunc *pt_mmio_write_cb[3] = {
- pt_mmio_writeb,
- pt_mmio_writew,
- pt_mmio_writel
-};
-
There's at least one use case for keeping mmio in userspace:
reverse-engineering a device driver. So if it doesn't cause too much
trouble, please keep this an option.
I don't think it's a big deal to support both, although I'm not sure
how useful it would be (especially considering mmiotrace). Did you
have a user-interface for specifying it in mind?
Cheers,
Muli
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] paravirt clock stil causing hangs in kvm-65
On Mon, Apr 07, 2008 at 06:34:57PM -0300, Marcelo Tosatti wrote: On Mon, Apr 07, 2008 at 01:53:36PM +0200, Nikola Ciprich wrote: Hi, I also tried paravirt clock again in latest git with kvm-65 patch applied, and problem with cpu-lockups persists: [10813.654806] BUG: soft lockup - CPU#0 stuck for 61s! [swapper:0] [10813.655789] CPU 0: [10813.656624] Modules linked in: virtio_pci virtio_ring virtio_blk virtio piix dm_snapshot dm_zero dm_mirror dm_mod ide_disk ide_core sd_mod scsi_mod ext3 jbd ehci_hcd ohci_hcd uhci_hcd [10813.658805] Pid: 0, comm: swapper Not tainted 2.6.25-rc7 #5 [10813.658805] RIP: 0010:[80222ab2] [80222ab2] native_safe_halt+0x2/0x10 [10813.658805] RSP: 0018:805adf50 EFLAGS: 0296 [10813.658805] RAX: 00019b08eeb0 RBX: 805f5000 RCX: 00019b08eeb0 [10813.658805] RDX: 0006 RSI: 356832b0 RDI: 805adf38 [10813.658805] RBP: 0da8 R08: R09: [10813.658805] R10: 0001 R11: 0002 R12: 802228ed [10813.658805] R13: 000132a0 R14: 80200bba R15: 81000100a280 [10813.658805] FS: () GS:80576000() knlGS: [10813.658805] CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b [10813.658805] CR2: 7fac0f852000 CR3: 00201000 CR4: 06e0 [10813.658805] DR0: DR1: DR2: [10813.658805] DR3: DR6: 0ff0 DR7: 0400 [10813.658805] [10813.658805] Call Trace: [10813.658805] [8020a55b] ? default_idle+0x3b/0x70 [10813.658805] [8020a520] ? default_idle+0x0/0x70 [10813.658805] [8020a60e] ? cpu_idle+0x7e/0xe0 [10813.658805] [80211630] ? pda_init+0x30/0xb0 Can I somehow help to track this one down?? Hi Nikola, I just reproduced this on a UP guest. Were you seeing the exact same stack trace in the guest with kvm-64 ? I've been able to reproduce the problem. Symptoms are that when using NOHZ vcpu0 LAPIC timer is ticking far less than the others (apparently vcpu0 is the only one ticking correctly): nohz=on with kvmclock [EMAIL PROTECTED] ~]# cat /proc/timer_stats | grep apic 13214, 8590 qemu-system-x86 apic_mmio_write (apic_timer_fn) 13214, 8589 qemu-system-x86 apic_mmio_write (apic_timer_fn) 13211, 8588 qemu-system-x86 apic_mmio_write (apic_timer_fn) 389, 8587 qemu-system-x86 apic_mmio_write (apic_timer_fn) nohz=off 3253, 8672 qemu-system-x86 apic_mmio_write (apic_timer_fn) 2876, 8673 qemu-system-x86 apic_mmio_write (apic_timer_fn) 2543, 8674 qemu-system-x86 apic_mmio_write (apic_timer_fn) 2179, 8675 qemu-system-x86 apic_mmio_write (apic_timer_fn) no-kvmclock 1017, 8808 qemu-system-x86 apic_mmio_write (apic_timer_fn) 1577, 8809 qemu-system-x86 apic_mmio_write (apic_timer_fn) 1708, 8807 qemu-system-x86 apic_mmio_write (apic_timer_fn) 1812, 8806 qemu-system-x86 apic_mmio_write (apic_timer_fn) Glauber will start looking at this next week. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] paravirt clock stil causing hangs in kvm-65
On Sat, Apr 19, 2008 at 12:29 PM, Marcelo Tosatti [EMAIL PROTECTED] wrote: On Mon, Apr 07, 2008 at 06:34:57PM -0300, Marcelo Tosatti wrote: On Mon, Apr 07, 2008 at 01:53:36PM +0200, Nikola Ciprich wrote: Hi, I also tried paravirt clock again in latest git with kvm-65 patch applied, and problem with cpu-lockups persists: [10813.654806] BUG: soft lockup - CPU#0 stuck for 61s! [swapper:0] [10813.655789] CPU 0: [10813.656624] Modules linked in: virtio_pci virtio_ring virtio_blk virtio piix dm_snapshot dm_zero dm_mirror dm_mod ide_disk ide_core sd_mod scsi_mod ext3 jbd ehci_hcd ohci_hcd uhci_hcd [10813.658805] Pid: 0, comm: swapper Not tainted 2.6.25-rc7 #5 [10813.658805] RIP: 0010:[80222ab2] [80222ab2] native_safe_halt+0x2/0x10 [10813.658805] RSP: 0018:805adf50 EFLAGS: 0296 [10813.658805] RAX: 00019b08eeb0 RBX: 805f5000 RCX: 00019b08eeb0 [10813.658805] RDX: 0006 RSI: 356832b0 RDI: 805adf38 [10813.658805] RBP: 0da8 R08: R09: [10813.658805] R10: 0001 R11: 0002 R12: 802228ed [10813.658805] R13: 000132a0 R14: 80200bba R15: 81000100a280 [10813.658805] FS: () GS:80576000() knlGS: [10813.658805] CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b [10813.658805] CR2: 7fac0f852000 CR3: 00201000 CR4: 06e0 [10813.658805] DR0: DR1: DR2: [10813.658805] DR3: DR6: 0ff0 DR7: 0400 [10813.658805] [10813.658805] Call Trace: [10813.658805] [8020a55b] ? default_idle+0x3b/0x70 [10813.658805] [8020a520] ? default_idle+0x0/0x70 [10813.658805] [8020a60e] ? cpu_idle+0x7e/0xe0 [10813.658805] [80211630] ? pda_init+0x30/0xb0 Can I somehow help to track this one down?? Hi Nikola, I just reproduced this on a UP guest. Were you seeing the exact same stack trace in the guest with kvm-64 ? I've been able to reproduce the problem. Symptoms are that when using NOHZ vcpu0 LAPIC timer is ticking far less than the others (apparently vcpu0 is the only one ticking correctly): nohz=on with kvmclock [EMAIL PROTECTED] ~]# cat /proc/timer_stats | grep apic 13214, 8590 qemu-system-x86 apic_mmio_write (apic_timer_fn) 13214, 8589 qemu-system-x86 apic_mmio_write (apic_timer_fn) 13211, 8588 qemu-system-x86 apic_mmio_write (apic_timer_fn) 389, 8587 qemu-system-x86 apic_mmio_write (apic_timer_fn) nohz=off 3253, 8672 qemu-system-x86 apic_mmio_write (apic_timer_fn) 2876, 8673 qemu-system-x86 apic_mmio_write (apic_timer_fn) 2543, 8674 qemu-system-x86 apic_mmio_write (apic_timer_fn) 2179, 8675 qemu-system-x86 apic_mmio_write (apic_timer_fn) no-kvmclock 1017, 8808 qemu-system-x86 apic_mmio_write (apic_timer_fn) 1577, 8809 qemu-system-x86 apic_mmio_write (apic_timer_fn) 1708, 8807 qemu-system-x86 apic_mmio_write (apic_timer_fn) 1812, 8806 qemu-system-x86 apic_mmio_write (apic_timer_fn) Glauber will start looking at this next week. From what me and marcelo discussed, I think there's a possibility that it has marginally something to do with precision of clock calculation. Gerd's patches address that issues. Can somebody test this with those patches (both guest and host), while I'm off ? -- Glauber Costa. Free as in Freedom http://glommer.net The less confident you are, the more serious you have to act. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] paravirt clock stil causing hangs in kvm-65
On Sat, Apr 19, 2008 at 12:29:47PM -0300, Marcelo Tosatti wrote: I just reproduced this on a UP guest. Were you seeing the exact same stack trace in the guest with kvm-64 ? I've been able to reproduce the problem. Symptoms are that when using NOHZ vcpu0 LAPIC timer is ticking far less than the others (apparently vcpu0 is the only one ticking correctly): nohz=on with kvmclock [EMAIL PROTECTED] ~]# cat /proc/timer_stats | grep apic 13214, 8590 qemu-system-x86 apic_mmio_write (apic_timer_fn) 13214, 8589 qemu-system-x86 apic_mmio_write (apic_timer_fn) 13211, 8588 qemu-system-x86 apic_mmio_write (apic_timer_fn) 389, 8587 qemu-system-x86 apic_mmio_write (apic_timer_fn) nohz=off 3253, 8672 qemu-system-x86 apic_mmio_write (apic_timer_fn) 2876, 8673 qemu-system-x86 apic_mmio_write (apic_timer_fn) 2543, 8674 qemu-system-x86 apic_mmio_write (apic_timer_fn) 2179, 8675 qemu-system-x86 apic_mmio_write (apic_timer_fn) no-kvmclock 1017, 8808 qemu-system-x86 apic_mmio_write (apic_timer_fn) 1577, 8809 qemu-system-x86 apic_mmio_write (apic_timer_fn) 1708, 8807 qemu-system-x86 apic_mmio_write (apic_timer_fn) 1812, 8806 qemu-system-x86 apic_mmio_write (apic_timer_fn) Glauber will start looking at this next week. Glauber, that printk you suggested has just triggered, but in a different condition. Guest was working fine (SMP 2-way), then suddenly: [EMAIL PROTECTED] bonnie++-1.03c]# ./bonnie++ You must use the -u switch when running as root. usage: bonnie++ [-d scratch-dir] [-s size(Mb)[:chunk-size(b)]] [-n number-to-stat[:max-size[:min-size][:num-directories]]] [-m machine-name] [-r ram-size-iserial8250: too much work for irq4 n-Mb] [-x number-of-tests] [-u uid-to-use:gid-to-use] [-g gid-to-use] [-q] [-f] [-b] [-p processes | -y] Version: 1.03c [EMAIL PROTECTED] bonnie++-1.03c]# ./bonnie++ dirty_portuguese_word: -361322 And there it hanged. diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c index a3fa587..7785fcc 100644 --- a/kernel/time/timekeeping.c +++ b/kernel/time/timekeeping.c @@ -453,6 +453,8 @@ void update_wall_time(void) #else offset = clock-cycle_interval; #endif +if ((s64) offset 0) +printk(...! %lld\n, (s64)offset); clock-xtime_nsec += (s64)xtime.tv_nsec clock-shift; /* normally this loop will run just once, however in the - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] paravirt clock stil causing hangs in kvm-65
On Sat, Apr 19, 2008 at 01:22:28PM -0300, Glauber Costa wrote: I've been able to reproduce the problem. Symptoms are that when using NOHZ vcpu0 LAPIC timer is ticking far less than the others (apparently vcpu0 is the only one ticking correctly): nohz=on with kvmclock [EMAIL PROTECTED] ~]# cat /proc/timer_stats | grep apic 13214, 8590 qemu-system-x86 apic_mmio_write (apic_timer_fn) 13214, 8589 qemu-system-x86 apic_mmio_write (apic_timer_fn) 13211, 8588 qemu-system-x86 apic_mmio_write (apic_timer_fn) 389, 8587 qemu-system-x86 apic_mmio_write (apic_timer_fn) nohz=off 3253, 8672 qemu-system-x86 apic_mmio_write (apic_timer_fn) 2876, 8673 qemu-system-x86 apic_mmio_write (apic_timer_fn) 2543, 8674 qemu-system-x86 apic_mmio_write (apic_timer_fn) 2179, 8675 qemu-system-x86 apic_mmio_write (apic_timer_fn) no-kvmclock 1017, 8808 qemu-system-x86 apic_mmio_write (apic_timer_fn) 1577, 8809 qemu-system-x86 apic_mmio_write (apic_timer_fn) 1708, 8807 qemu-system-x86 apic_mmio_write (apic_timer_fn) 1812, 8806 qemu-system-x86 apic_mmio_write (apic_timer_fn) Glauber will start looking at this next week. From what me and marcelo discussed, I think there's a possibility that it has marginally something to do with precision of clock calculation. Gerd's patches address that issues. Can somebody test this with those patches (both guest and host), while I'm off ? Haven't seen Gerd's guest patches ? - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] [PATCH 1/5] PCI DMA API (v3)
On 4/17/08, Anthony Liguori [EMAIL PROTECTED] wrote: Yes, the vector version of packet receive is tough. I'll take a look at your patch. Basically, you need to associate a set of RX vectors with each VLANClientState and then when it comes time to deliver a packet to the VLAN, before calling fd_read, see if there is an RX vector available for the client. In the case of tap, I want to optimize further and do the initial readv() to one of the clients RX buffers and then copy that RX buffer to the rest of the clients if necessary. The vector versions should also help SLIRP to add IP and Ethernet headers to the incoming packets. I made an initial version of the vectored AIO SCSI with ESP. It does not work, but I can see that just using the vectors won't give too much extra performance, because at least initially the vector length is 1. Collecting the statuses may be tricky. block_aio_rw_v.diff Description: plain/text - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] [PATCH 1/5] PCI DMA API (v3)
Blue Swirl wrote: On 4/17/08, Anthony Liguori [EMAIL PROTECTED] wrote: Yes, the vector version of packet receive is tough. I'll take a look at your patch. Basically, you need to associate a set of RX vectors with each VLANClientState and then when it comes time to deliver a packet to the VLAN, before calling fd_read, see if there is an RX vector available for the client. In the case of tap, I want to optimize further and do the initial readv() to one of the clients RX buffers and then copy that RX buffer to the rest of the clients if necessary. The vector versions should also help SLIRP to add IP and Ethernet headers to the incoming packets. Yeah, I'm hoping that with my posted linux-aio interface, I can add vector support since linux-aio has a proper asynchronous vector function. Are we happy with the DMA API? If so, we should commit it now so we can start adding proper vector interfaces for net/block. Regards, Anthony Liguori I made an initial version of the vectored AIO SCSI with ESP. It does not work, but I can see that just using the vectors won't give too much extra performance, because at least initially the vector length is 1. Collecting the statuses may be tricky. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm-trace help
DOH. I had the 2 new ones backwards in the formats file. thanks for pointing that out, david Liu, Eric E wrote: I mean the value of PTE_WRITE you write in the formats file ( 0x00020016 )should be same with KVM_TRC_PTE_WRITE you define in kvm.h, but now it is 0x00020015. if not what you get in the text file will be disordered. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] Re: [PATCH 0/3] Qemu crashes with pci passthrough
On Fri, Apr 18, 2008 at 1:27 PM, Avi Kivity [EMAIL PROTECTED] wrote:
Glauber de Oliveira Costa wrote:
Hi,
I've got some qemu crashes while trying to passthrough an ide device
to a kvm guest. After some investigation, it turned out that
register_ioport_{read/write} will abort on errors instead of returning
a meaningful error.
However, even if we do return an error, the asynchronous nature of pci
config space mapping updates makes it a little bit hard to treat.
This series of patches basically treats errors in the mapping functions in
the pci layer. If anything goes wrong, we unregister the pci device,
unmapping
any mappings that happened to be sucessfull already.
After these patches are applied, a lot of warnings appears. And, you know,
everytime there is a warning, god kills a kitten. But I'm not planning on
touching the other pieces of qemu code for this until we set up (or not)
in
this solution
Comments are very welcome, specially from qemu folks (since it is a bit
invasive)
Have you considered, instead of rolling back the changes you already made
before the failure, to have a function which checks if an ioport
registration will be successful? This may simplify the code.
Yes, I did.
Basic problem is that I basically could not find this information
handy until we were deep in the stack, right before calling the update
mapping functions. I turned out preferring this option. I can,
however, take a fresh look at that.
--
Glauber Costa.
Free as in Freedom
http://glommer.net
The less confident you are, the more serious you have to act.
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] (no subject)
各位老总：您们好！ 诚祝：您们在2008年里；有鼠不尽的快乐！鼠不尽的收获！鼠不尽的钞票！ 鼠不尽的幸福！鼠不尽的美满生活！愿： 您们阖家欢乐！幸福安康！ 我公司可以长期提供：出口报关单，核销单，等等一系列手续；代理：出口 报关，商检，境内外运输..等等；还可以代办：出口欧盟许可证，欧盟产地证； 并且还有（广州国际贸易交易会）的摊位可以转让；价格特别优惠；有意者请来邮件 或来电联系。谢谢合作！ 电话：0755-81153047。 传真：0755-81172940。 手机：15817477278。 联系人：钟文辉。 此致： 敬礼！ - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Second KVM process hangs eating 80-100% CPU on host during startup
--- On Fri, 4/18/08, Avi Kivity [EMAIL PROTECTED] wrote: From: Avi Kivity [EMAIL PROTECTED] Subject: Re: [kvm-devel] Second KVM process hangs eating 80-100% CPU on host during startup [snip] I tried booting the guest with 'lpj=10682525' to work around the calibrate_delay issue, but that gave me: [0.004100] ENABLING IO-APIC IRQs [0.004100] ..TIMER: vector=0x31 apic1=0 pin1=0 apic2=-1 pin2=-1 [0.004100] ..MP-BIOS bug: 8254 timer not connected to IO-APIC [0.004100] ...trying to set up timer (IRQ0) through the 8259A ... failed. [0.004100] ...trying to set up timer as Virtual Wire IRQ ... failed. [0.004100] ...trying to set up timer as ExtINT IRQ ... failed :(. [0.004100] Kernel panic - not syncing: IO-APIC + timer doesn't work! Boot with apic=debug and send a report.Then try booting with the 'noapic' option. Booting with 'apic=debug' gives these additional lines: [0.004100] Getting VERSION: 50014 [0.004100] Getting VERSION: 50014 [0.004100] Getting ID: 0 [0.004100] Getting LVT0: 700 [0.004100] Getting LVT1: 1 Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Second KVM process hangs eating 80-100% CPU on host during startup
On Sat, Apr 19, 2008 at 03:47:31PM -0700, Alex Davis wrote:
--- On Fri, 4/18/08, Avi Kivity [EMAIL PROTECTED] wrote:
From: Avi Kivity [EMAIL PROTECTED]
Subject: Re: [kvm-devel] Second KVM process hangs eating 80-100% CPU on
host during startup
[snip]
I tried booting the guest with 'lpj=10682525' to work around the
calibrate_delay issue, but that gave me:
[0.004100] ENABLING IO-APIC IRQs
[0.004100] ..TIMER: vector=0x31 apic1=0 pin1=0 apic2=-1 pin2=-1
[0.004100] ..MP-BIOS bug: 8254 timer not connected to IO-APIC
[0.004100] ...trying to set up timer (IRQ0) through the 8259A ... failed.
[0.004100] ...trying to set up timer as Virtual Wire IRQ ... failed.
[0.004100] ...trying to set up timer as ExtINT IRQ ... failed :(.
[0.004100] Kernel panic - not syncing: IO-APIC + timer doesn't work! Boot
with apic=debug and send a report.Then try booting with the 'noapic' option.
Booting with 'apic=debug' gives these additional lines:
[0.004100] Getting VERSION: 50014
[0.004100] Getting VERSION: 50014
[0.004100] Getting ID: 0
[0.004100] Getting LVT0: 700
[0.004100] Getting LVT1: 1
Hi Alex,
Can you please try the following.
KVM: PIT: make last_injected_time per-guest
Otherwise multiple guests use the same variable and boom.
Also use kvm_vcpu_kick() to make sure that if a timer triggers on
a different CPU the event won't be missed.
Signed-off-by: Marcelo Tosatti [EMAIL PROTECTED]
diff --git a/arch/x86/kvm/i8254.c b/arch/x86/kvm/i8254.c
index 2852dd1..5697ad2 100644
--- a/arch/x86/kvm/i8254.c
+++ b/arch/x86/kvm/i8254.c
@@ -200,10 +200,8 @@ int __pit_timer_fn(struct kvm_kpit_state *ps)
atomic_inc(pt-pending);
smp_mb__after_atomic_inc();
- if (vcpu0 waitqueue_active(vcpu0-wq)) {
- vcpu0-arch.mp_state = KVM_MP_STATE_RUNNABLE;
- wake_up_interruptible(vcpu0-wq);
- }
+ if (vcpu0)
+ kvm_vcpu_kick(vcpu0);
pt-timer.expires = ktime_add_ns(pt-timer.expires, pt-period);
pt-scheduled = ktime_to_ns(pt-timer.expires);
@@ -572,7 +570,6 @@ void kvm_inject_pit_timer_irqs(struct kvm_vcpu *vcpu)
struct kvm_pit *pit = vcpu-kvm-arch.vpit;
struct kvm *kvm = vcpu-kvm;
struct kvm_kpit_state *ps;
- static unsigned long last_injected_time;
if (vcpu pit) {
ps = pit-pit_state;
@@ -582,11 +579,11 @@ void kvm_inject_pit_timer_irqs(struct kvm_vcpu *vcpu)
* 2. Last interrupt was accepted or waited for too long time*/
if (atomic_read(ps-pit_timer.pending)
(ps-inject_pending ||
- (jiffies - last_injected_time
+ (jiffies - ps-last_injected_time
= KVM_MAX_PIT_INTR_INTERVAL))) {
ps-inject_pending = 0;
__inject_pit_timer_intr(kvm);
- last_injected_time = jiffies;
+ ps-last_injected_time = jiffies;
}
}
}
diff --git a/arch/x86/kvm/i8254.h b/arch/x86/kvm/i8254.h
index e63ef38..db25c2a 100644
--- a/arch/x86/kvm/i8254.h
+++ b/arch/x86/kvm/i8254.h
@@ -35,6 +35,7 @@ struct kvm_kpit_state {
struct mutex lock;
struct kvm_pit *pit;
bool inject_pending; /* if inject pending interrupts */
+ unsigned long last_injected_time;
};
struct kvm_pit {
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Second KVM process hangs eating 80-100% CPU on host during startup
--- On Sat, 4/19/08, Marcelo Tosatti [EMAIL PROTECTED] wrote:
From: Marcelo Tosatti [EMAIL PROTECTED]
Subject: Re: [kvm-devel] Second KVM process hangs eating 80-100% CPU on host
during startup
To: Alex Davis [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], kvm-devel@lists.sourceforge.net
Date: Saturday, April 19, 2008, 7:11 PM
On Sat, Apr 19, 2008 at 03:47:31PM -0700, Alex Davis wrote:
--- On Fri, 4/18/08, Avi Kivity
[EMAIL PROTECTED] wrote:
From: Avi Kivity [EMAIL PROTECTED]
Subject: Re: [kvm-devel] Second KVM process hangs
eating 80-100% CPU on host during startup
[snip]
I tried booting the guest with 'lpj=10682525'
to work around the
calibrate_delay issue, but that gave me:
[0.004100] ENABLING IO-APIC IRQs
[0.004100] ..TIMER: vector=0x31 apic1=0 pin1=0
apic2=-1 pin2=-1
[0.004100] ..MP-BIOS bug: 8254 timer not connected
to IO-APIC
[0.004100] ...trying to set up timer (IRQ0)
through the 8259A ... failed.
[0.004100] ...trying to set up timer as Virtual
Wire IRQ ... failed.
[0.004100] ...trying to set up timer as ExtINT IRQ
... failed :(.
[0.004100] Kernel panic - not syncing: IO-APIC +
timer doesn't work! Boot
with apic=debug and send a report.Then try booting
with the 'noapic' option.
Booting with 'apic=debug' gives these
additional lines:
[0.004100] Getting VERSION: 50014
[0.004100] Getting VERSION: 50014
[0.004100] Getting ID: 0
[0.004100] Getting LVT0: 700
[0.004100] Getting LVT1: 1
Hi Alex,
Can you please try the following.
KVM: PIT: make last_injected_time per-guest
Otherwise multiple guests use the same variable and boom.
Also use kvm_vcpu_kick() to make sure that if a timer
triggers on
a different CPU the event won't be missed.
Signed-off-by: Marcelo Tosatti [EMAIL PROTECTED]
diff --git a/arch/x86/kvm/i8254.c b/arch/x86/kvm/i8254.c
index 2852dd1..5697ad2 100644
--- a/arch/x86/kvm/i8254.c
+++ b/arch/x86/kvm/i8254.c
@@ -200,10 +200,8 @@ int __pit_timer_fn(struct
kvm_kpit_state *ps)
atomic_inc(pt-pending);
smp_mb__after_atomic_inc();
- if (vcpu0 waitqueue_active(vcpu0-wq))
{
- vcpu0-arch.mp_state = KVM_MP_STATE_RUNNABLE;
- wake_up_interruptible(vcpu0-wq);
- }
+ if (vcpu0)
+ kvm_vcpu_kick(vcpu0);
pt-timer.expires = ktime_add_ns(pt-timer.expires,
pt-period);
pt-scheduled = ktime_to_ns(pt-timer.expires);
@@ -572,7 +570,6 @@ void kvm_inject_pit_timer_irqs(struct
kvm_vcpu *vcpu)
struct kvm_pit *pit = vcpu-kvm-arch.vpit;
struct kvm *kvm = vcpu-kvm;
struct kvm_kpit_state *ps;
- static unsigned long last_injected_time;
if (vcpu pit) {
ps = pit-pit_state;
@@ -582,11 +579,11 @@ void kvm_inject_pit_timer_irqs(struct
kvm_vcpu *vcpu)
* 2. Last interrupt was accepted or waited for too long
time*/
if (atomic_read(ps-pit_timer.pending)
(ps-inject_pending ||
- (jiffies - last_injected_time
+ (jiffies - ps-last_injected_time
= KVM_MAX_PIT_INTR_INTERVAL))) {
ps-inject_pending = 0;
__inject_pit_timer_intr(kvm);
- last_injected_time = jiffies;
+ ps-last_injected_time = jiffies;
}
}
}
diff --git a/arch/x86/kvm/i8254.h b/arch/x86/kvm/i8254.h
index e63ef38..db25c2a 100644
--- a/arch/x86/kvm/i8254.h
+++ b/arch/x86/kvm/i8254.h
@@ -35,6 +35,7 @@ struct kvm_kpit_state {
struct mutex lock;
struct kvm_pit *pit;
bool inject_pending; /* if inject pending interrupts */
+ unsigned long last_injected_time;
};
struct kvm_pit {
Problem(s) solved. Everything is working now. Can now boot both with and
without 'lpj='. The BogoMIPs are also being calculated correctly in secondary
guests without 'lpj='. I'll play with it some more just to make sure, then I'll
close the original bug.
Thanks, Marcelo et al.
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now.
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [kvm-ppc-devel] [PATCH 1/5]Add some trace markers and exposeinterfaces in kernel for tracing
Christian Ehrhardt wrote:
Liu, Eric E wrote:
Hollis Blanchard wrote:
On Wednesday 16 April 2008 01:45:34 Liu, Eric E wrote: [...]
Actually... we could have kvmtrace itself insert the metadata, so
there would be no chance of it being overwritten in the kernel
buffers. The header could be written in tip_open_output(), and
update fs_size accordingly.
Yes, let kvmtrace insert the metadata is more reasonable.
I wanted to note that the kvmtrace tool should, but not need to know
everything about the data format.
I think of e.g. changing kernel implementations that change endianess
or even flags we don't yet know, but we might need in the future.
What about adding another debugfs entry the kernel can use to expose
the kvmtrace-metadata defined by the kernel implementation.
The kvmtrace tool could then use that to build up the record by using
one entry for kernel defined metadata and another to add any metadata
that would be defined by kvmtrace tool itself.
what about that one:
struct metadata {
u32 kmagic; /* stores kernel defined metadata read from
debugfs
entry */ u32 umagic; /* stores userspace tool defined
metadata */
u32 extra; /* it is redundant, only use to fit into
record. */
}
That should give us the flexibility to keep the format if we get more
metadata requirements in the future.
Yes, maybe we need metadata to indicate the changing kernel
implementations in the future, but adding debugfs entry seems not a good
approach. What about defining a similar metadat in kernel rather than in
userland and write it in rchan at the first time we add trace data. Then
we don't need kvmtrace tool to insert the medadata again.
like this:
struct kvm_trace_metadata {
u32 kmagic; /* stores kernel defined metadata */
u64 extra; /* use to fit into record. */
}
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
