[ kvm-Bugs-2458020 ] 32e Guest crash after Live Migration
Bugs item #2458020, was opened at 2008-12-22 01:30
Message generated for change (Comment added) made by jiajun
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=893831aid=2458020group_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: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jiajun Xu (jiajun)
Assigned to: Nobody/Anonymous (nobody)
Summary: 32e Guest crash after Live Migration
Initial Comment:
With Kernel Commit:c7735e1385a8cf109d6ea3eb2d5d2bbd760f19e7
Userspace Commit:bdf56d67c1f04e3229ead4eb8baed4bb768221ad
Host Kernel Version: 2.6.28-rc6
Live Migration 32e guest will cause guest crash.
Host dmesg shows:
kvm: 25636: cpu0 unhandled rdmsr: 0xc0010117
kvm: 25656: cpu0 unhandled wrmsr: 0xc0010117 data 0
And in guest it shows:
##
double fault: [1] SMP
last sysfs file: /block/hda/removable
CPU 0
Modules linked in: ipv6 autofs4 hidp rfcomm l2cap bluetooth sunrpc iscsi_tcp
ib_iser libiscsi scsi_transport_iscsi rdma_ucm ib_ucm ib_srp ib_sdp rdma_cm
ib_cm iw_cm ib_addr ib_local_sa ib_ipoib ib_sa ib_uverbs ib_umad ib_mad ib_core
dm_mirror dm_multipath dm_mod video sbs backlight i2c_ec i2c_core button
battery asus_acpi acpi_memhotplug ac lp floppy pcspkr serio_raw parport_pc
ide_cd parport 8139cp 8139too mii cdrom ata_piix libata sd_mod scsi_mod ext3
jbd ehci_hcd ohci_hcd uhci_hcd
Pid: 2141, comm: avahi-daemon Not tainted 2.6.18-53.el5 #1
RIP: 0010:[800645c9] [800645c9] do_page_fault+0x17/0x81d
RSP: 0018:761ba028 EFLAGS: 00010016
RAX: 800645b2 RBX: 0001 RCX: 2bc32fa7
RDX: 761bc85c RSI: RDI: 761ba118
RBP: 8005b67c R08: 761bc8f8 R09: 761bc8ff
R10: 494f3cd7 R11: 0246 R12: 761bc900
R13: 761ba118 R14: R15: 761bc8fc
FS: 2c0d7370() GS:80396000() knlGS:
CS: 0010 DS: ES: CR0: 8005003b
CR2: 761b9ff8 CR3: 0836c000 CR4: 06e0
Process avahi-daemon (pid: 2141, threadinfo 81000836e000, task
81000daff080)
Stack:
Call Trace:
[8005bde9] error_exit+0x0/0x84
[800645b2] do_page_fault+0x0/0x81d
[800645c9] do_page_fault+0x17/0x81d
[8005bde9] error_exit+0x0/0x84
[800645b2] do_page_fault+0x0/0x81d
[800645c9] do_page_fault+0x17/0x81d
[8005bde9] error_exit+0x0/0x84
[800645b2] do_page_fault+0x0/0x81d
[800645c9] do_page_fault+0x17/0x81d
[8005bde9] error_exit+0x0/0x84
[800645b2] do_page_fault+0x0/0x81d
[800645c9] do_page_fault+0x17/0x81d
[8005bde9] error_exit+0x0/0x84
[800645b2] do_page_fault+0x0/0x81d
[800645c9] do_page_fault+0x17/0x81d
[8005bde9] error_exit+0x0/0x84
[800645b2] do_page_fault+0x0/0x81d
[800645c9] do_page_fault+0x17/0x81d
[8005bde9] error_exit+0x0/0x84
[800645b2] do_page_fault+0x0/0x81d
[800645c9] do_page_fault+0x17/0x81d
[8005bde9] error_exit+0x0/0x84
[800645b2] do_page_fault+0x0/0x81d
[800645c9] do_page_fault+0x17/0x81d
[8005bde9] error_exit+0x0/0x84
[800645b2] do_page_fault+0x0/0x81d
[800645c9] do_page_fault+0x17/0x81d
[8005bde9] error_exit+0x0/0x84
[800645b2] do_page_fault+0x0/0x81d
[800645c9] do_page_fault+0x17/0x81d
[8005bde9] error_exit+0x0/0x84
[800645b2] do_page_fault+0x0/0x81d
[800645c9] do_page_fault+0x17/0x81d
[8005bde9] error_exit+0x0/0x84
[800645b2] do_page_fault+0x0/0x81d
[800645c9] do_page_fault+0x17/0x81d
[8005bde9] error_exit+0x0/0x84
[800645b2] do_page_fault+0x0/0x81d
[800645c9] do_page_fault+0x17/0x81d
[8005bde9] error_exit+0x0/0x84
[800645b2] do_page_fault+0x0/0x81d
[800645c9] do_page_fault+0x17/0x81d
[8005bde9] error_exit+0x0/0x84
[800645b2] do_page_fault+0x0/0x81d
[800645c9] do_page_fault+0x17/0x81d
[8005bde9] error_exit+0x0/0x84
[800645b2] do_page_fault+0x0/0x81d
[800645c9] do_page_fault+0x17/0x81d
[8005bde9] error_exit+0x0/0x84
[800645b2] do_page_fault+0x0/0x81d
[800645c9] do_page_fault+0x17/0x81d
[8005bde9] error_exit+0x0/0x84
[800645b2] do_page_fault+0x0/0x81d
[800645c9] do_page_fault+0x17/0x81d
[8005bde9] error_exit+0x0/0x84
[800645b2] do_page_fault+0x0/0x81d
[800645c9] do_page_fault+0x17/0x81d
[ kvm-Bugs-2458020 ] 32e Guest crash after Live Migration
Bugs item #2458020, was opened at 2008-12-22 01:30
Message generated for change (Settings changed) made by jiajun
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=893831aid=2458020group_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: None
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Jiajun Xu (jiajun)
Assigned to: Nobody/Anonymous (nobody)
Summary: 32e Guest crash after Live Migration
Initial Comment:
With Kernel Commit:c7735e1385a8cf109d6ea3eb2d5d2bbd760f19e7
Userspace Commit:bdf56d67c1f04e3229ead4eb8baed4bb768221ad
Host Kernel Version: 2.6.28-rc6
Live Migration 32e guest will cause guest crash.
Host dmesg shows:
kvm: 25636: cpu0 unhandled rdmsr: 0xc0010117
kvm: 25656: cpu0 unhandled wrmsr: 0xc0010117 data 0
And in guest it shows:
##
double fault: [1] SMP
last sysfs file: /block/hda/removable
CPU 0
Modules linked in: ipv6 autofs4 hidp rfcomm l2cap bluetooth sunrpc iscsi_tcp
ib_iser libiscsi scsi_transport_iscsi rdma_ucm ib_ucm ib_srp ib_sdp rdma_cm
ib_cm iw_cm ib_addr ib_local_sa ib_ipoib ib_sa ib_uverbs ib_umad ib_mad ib_core
dm_mirror dm_multipath dm_mod video sbs backlight i2c_ec i2c_core button
battery asus_acpi acpi_memhotplug ac lp floppy pcspkr serio_raw parport_pc
ide_cd parport 8139cp 8139too mii cdrom ata_piix libata sd_mod scsi_mod ext3
jbd ehci_hcd ohci_hcd uhci_hcd
Pid: 2141, comm: avahi-daemon Not tainted 2.6.18-53.el5 #1
RIP: 0010:[800645c9] [800645c9] do_page_fault+0x17/0x81d
RSP: 0018:761ba028 EFLAGS: 00010016
RAX: 800645b2 RBX: 0001 RCX: 2bc32fa7
RDX: 761bc85c RSI: RDI: 761ba118
RBP: 8005b67c R08: 761bc8f8 R09: 761bc8ff
R10: 494f3cd7 R11: 0246 R12: 761bc900
R13: 761ba118 R14: R15: 761bc8fc
FS: 2c0d7370() GS:80396000() knlGS:
CS: 0010 DS: ES: CR0: 8005003b
CR2: 761b9ff8 CR3: 0836c000 CR4: 06e0
Process avahi-daemon (pid: 2141, threadinfo 81000836e000, task
81000daff080)
Stack:
Call Trace:
[8005bde9] error_exit+0x0/0x84
[800645b2] do_page_fault+0x0/0x81d
[800645c9] do_page_fault+0x17/0x81d
[8005bde9] error_exit+0x0/0x84
[800645b2] do_page_fault+0x0/0x81d
[800645c9] do_page_fault+0x17/0x81d
[8005bde9] error_exit+0x0/0x84
[800645b2] do_page_fault+0x0/0x81d
[800645c9] do_page_fault+0x17/0x81d
[8005bde9] error_exit+0x0/0x84
[800645b2] do_page_fault+0x0/0x81d
[800645c9] do_page_fault+0x17/0x81d
[8005bde9] error_exit+0x0/0x84
[800645b2] do_page_fault+0x0/0x81d
[800645c9] do_page_fault+0x17/0x81d
[8005bde9] error_exit+0x0/0x84
[800645b2] do_page_fault+0x0/0x81d
[800645c9] do_page_fault+0x17/0x81d
[8005bde9] error_exit+0x0/0x84
[800645b2] do_page_fault+0x0/0x81d
[800645c9] do_page_fault+0x17/0x81d
[8005bde9] error_exit+0x0/0x84
[800645b2] do_page_fault+0x0/0x81d
[800645c9] do_page_fault+0x17/0x81d
[8005bde9] error_exit+0x0/0x84
[800645b2] do_page_fault+0x0/0x81d
[800645c9] do_page_fault+0x17/0x81d
[8005bde9] error_exit+0x0/0x84
[800645b2] do_page_fault+0x0/0x81d
[800645c9] do_page_fault+0x17/0x81d
[8005bde9] error_exit+0x0/0x84
[800645b2] do_page_fault+0x0/0x81d
[800645c9] do_page_fault+0x17/0x81d
[8005bde9] error_exit+0x0/0x84
[800645b2] do_page_fault+0x0/0x81d
[800645c9] do_page_fault+0x17/0x81d
[8005bde9] error_exit+0x0/0x84
[800645b2] do_page_fault+0x0/0x81d
[800645c9] do_page_fault+0x17/0x81d
[8005bde9] error_exit+0x0/0x84
[800645b2] do_page_fault+0x0/0x81d
[800645c9] do_page_fault+0x17/0x81d
[8005bde9] error_exit+0x0/0x84
[800645b2] do_page_fault+0x0/0x81d
[800645c9] do_page_fault+0x17/0x81d
[8005bde9] error_exit+0x0/0x84
[800645b2] do_page_fault+0x0/0x81d
[800645c9] do_page_fault+0x17/0x81d
[8005bde9] error_exit+0x0/0x84
[800645b2] do_page_fault+0x0/0x81d
[800645c9] do_page_fault+0x17/0x81d
[8005bde9] error_exit+0x0/0x84
[800645b2] do_page_fault+0x0/0x81d
[800645c9] do_page_fault+0x17/0x81d
[8005bde9] error_exit+0x0/0x84
[800645b2] do_page_fault+0x0/0x81d
[800645c9] do_page_fault+0x17/0x81d
Weekly KVM Test report, kernel 247232 ... userspace 7fccb6 ...
Hi All, This is our Weekly KVM Testing Report against lastest kvm.git 247232698a0ad73e01c72a1827b35b3629acf2bd and kvm-userspace.git 7fccb652af7a28e78cd41bd986a96dfd80e9d21f. We did not test VT-d because latest kvm can not be built with 2.6.28 kernel. 32e guest crash with Live Migration issue is fixed. No new issue found in this two weeks. One Fixed issue: 1. 32e Guest crash after Live Migration https://sourceforge.net/tracker/index.php?func=detailaid=2458020group_id=180599atid=893831 Five Old Issues: 1. 32bits Rhel5/FC6 guest may fail to reboot after installation https://sourceforge.net/tracker/?func=detailatid=893831aid=1991647group_id=180599 2. failure to migrate guests with more than 4GB of RAM https://sourceforge.net/tracker/index.php?func=detailaid=1971512group_id=180599atid=893831 3. OpenSuse10.2 can not be installed http://sourceforge.net/tracker/index.php?func=detailaid=2088475group_id=180599atid=893831 4. Fail to Save Restore Guest https://sourceforge.net/tracker/?func=detailatid=893831aid=2175042group_id=180599 5. hotplug inexistent device will kill guest https://sourceforge.net/tracker/index.php?func=detailaid=2432316group_id=180599atid=893831 Test environment Platform A Stoakley/Clovertown CPU 4 Memory size 8G' Report Summary on IA32-pae Summary Test Report of Last Session = Total PassFailNoResult Crash = control_panel 8 6 2 00 gtest 16 16 0 00 = control_panel 8 6 2 00 :KVM_256M_guest_PAE_gPAE 1 1 0 00 :KVM_linux_win_PAE_gPAE1 1 0 00 :KVM_two_winxp_PAE_gPAE1 1 0 00 :KVM_four_sguest_PAE_gPA 1 1 0 00 :KVM_1500M_guest_PAE_gPA 1 1 0 00 :KVM_LM_Continuity_PAE_g 1 1 0 00 :KVM_LM_SMP_PAE_gPAE 1 0 1 00 :KVM_SR_Continuity_PAE_g 1 0 1 00 gtest 16 16 0 00 :ltp_nightly_PAE_gPAE 1 1 0 00 :boot_up_acpi_PAE_gPAE 1 1 0 00 :boot_up_acpi_xp_PAE_gPA 1 1 0 00 :boot_up_vista_PAE_gPAE1 1 0 00 :reboot_xp_PAE_gPAE1 1 0 00 :boot_base_kernel_PAE_gP 1 1 0 00 :boot_up_acpi_win2k3_PAE 1 1 0 00 :boot_smp_acpi_win2k3_PA 1 1 0 00 :boot_smp_acpi_win2k_PAE 1 1 0 00 :boot_up_win2008_PAE_gPA 1 1 0 00 :boot_up_acpi_win2k_PAE_ 1 1 0 00 :boot_smp_acpi_xp_PAE_gP 1 1 0 00 :boot_up_noacpi_win2k_PA 1 1 0 00 :boot_smp_vista_PAE_gPAE 1 1 0 00 :boot_smp_win2008_PAE_gP 1 1 0 00 :kb_nightly_PAE_gPAE 1 1 0 00 = Total 24 22 2 00 Report Summary on IA32e Summary Test Report of Last Session = Total PassFailNoResult Crash = control_panel 17 14 3 00 gtest 23 23 0 00 = control_panel 17 14 3 00 :KVM_4G_guest_64_g32e 1 1 0 00 :KVM_four_sguest_64_gPAE 1 1 0 00 :KVM_LM_SMP_64_g32e1 1 0 00 :KVM_linux_win_64_gPAE 1 1 0 00 :KVM_LM_SMP_64_gPAE1 1 0 00 :KVM_SR_Continuity_64_gP 1 0 1 00 :KVM_four_sguest_64_g32e 1 1 0 00 :KVM_four_dguest_64_gPAE 1 1 0 00 :KVM_SR_SMP_64_gPAE1 0 1 00 :KVM_LM_Continuity_64_g3 1 1 0 00 :KVM_1500M_guest_64_gPAE 1 1 0 00
Re: [PATCH 1/2][RFC] virtio_net: Enable setting MAC, promisc, and allmulti mode
On Thursday 08 January 2009 04:36:02 Alex Williamson wrote:
virtio_net: Enable setting MAC, promisc, and allmulti mode
Hi Alex,
There's nothing wrong with this idea: I assume you have an actual usage
for this rather than it being an abstract improvement?
@@ -41,7 +41,14 @@ struct virtnet_info
struct virtqueue *rvq, *svq;
struct net_device *dev;
struct napi_struct napi;
- unsigned int status;
+ union {
+ u16 raw;
+ struct {
+ u16 link:1;
+ u16 promisc:1;
+ u16 allmulti:1;
+ } bits;
+ } status;
I don't think this works, as it depends on bitfield endian.
@@ -30,7 +32,14 @@ struct virtio_net_config
__u8 mac[6];
/* Status supplied by host; see VIRTIO_NET_F_STATUS and VIRTIO_NET_S_*
* bits above */
- __u16 status;
+ union {
+ __u16 raw;
+ struct {
+ __u16 link:1;
+ __u16 promisc:1;
+ __u16 allmulti:1;
+ } bits;
+ } status;
} __attribute__((packed));
As does this. I think we need to leave the status bitfield as is.
Thanks,
Rusty.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/7] KVM: Add a route layer to convert MSI message to GSI
On Fri, Jan 09, 2009 at 08:06:01PM +0200, Avi Kivity wrote:
Sheng Yang wrote:
+struct kvm_gsi_route_entry_guest {
what does _guest mean here? almost all kvm stuff is _guest related.
Because I can't think of a good name... kvm_gsi_route_entry_guest?
kvm_gsi_kernel_route_entry? What's your favorite? :)
kvm_gsi_route_entry?
Which is used for kernel one now...
Since we replace the entire table every time, how do ioapic/pic gsis work?
Missed this question...
My comments below...
Why not throw everything and set the new table?
Userspace to maintain a big route table? Just for MSI/MSI-X it's easy,
but for others, a global one is needed, and need follow up more
maintain functions. For kernel, a little more effect can archive this,
like this. So I do it in this way.
Sorry, I don't understand the reply.
I didn't see where you respond the new KVM_CAP. It looks like a good
place to return the maximum size of the table.
I just use it as #ifdef in userspace now, for no user other than
MSI/MSI-X now. And if we keep maintaining it in kernel, we would return
free size instead of maximum size..
We need to allow userspace to change pic/ioapic routing for the HPET.
There are two styles of maintaining the table:
1. add/remove ioctls
The advantage is that very little work needs to be done when something
changes, but the code size (and bug count) doubles.
2. replace everything ioctl
Smaller code size, but slower if there are high frequency changes
I don't think we'll see high frequency interrupt routing changes; we'll
probably have one on setup (for HPET), another when switching from ACPI
PIC mode to ACPI APIC mode, and one for every msi initialized.
I come to option 2 mix with option 1 now. What I meant is, MSI part is in
device-assignment part, and HPET and others are in some other place, so a
global table should be maintained for these three across the parts of
userspace. I don't like the global gsi route table, and especially we
already got one in kernel space. We have to do some maintain work in the
kernel space, e.g. looking up a entry, so I think a little add-on can take
the job.
And now I think you original purpose is three different tables for MSI, HPET
and ACPI APIC mode? This also avoid global big table in userspace. But it
seems like a waste, and also too specific...
So how about this? One ioctl to replace everything, another(maybe two,
transfer entry number then table, or one with maximum entries number in
userspace) can export current gsi route table? This can avoid the global
route table, as well as reduce the complexity.
How do you think?
--
regards
Yang, Sheng |Intel Opensource Technology Center
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2][RFC] virtio_net: Add MAC fitler table support
On Thursday 08 January 2009 04:36:03 Alex Williamson wrote: virtio_net: Add MAC fitler table support Ah, I see. You really want multiple mac addresses, not just multicast filtering? Anthony, you think a control channel? We can add a virtqueue, but it seems like a lot of work... Rusty. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix almost infinite loop in APIC
On Fri, Jan 09, 2009 at 01:57:30PM +0100, Alexander Graf wrote:
Sheng Yang wrote:
On Friday 09 January 2009 00:36:06 Alexander Graf wrote:
While booting Linux in VMware ESX, I encountered a strange effect
in the in-kernel lapic implementation: time went backwards!
While this should never occur, because of that the while loop that
is done after the invalid calculations caused my host system to hang.
In order to make debugging easier, let's replace this as suggested
with a modulo function and not run into the danger of looping forever.
To replace the nice hint this bug gave me that the values are broken,
I added a printk message so people encountering this can at least
see that something is fishy.
Of course, the real issue needs to be fixed as well! I'm open to ideas
why now last_update!
(Thanks to Kevin for his help in debugging this)
Signed-off-by: Alexander Graf ag...@suse.de
Signed-off-by: Kevin Wolf kw...@suse.de
---
Hi Alexander
I'm a little suspect here:
if (unlikely(ktime_to_ns(now) =
ktime_to_ns(apic-timer.last_update))) {
/* Wrap around */
passed = ktime_add(( {
(ktime_t) {
.tv64 = KTIME_MAX -
(apic-timer.last_update).tv64}; }
), now);
apic_debug(time elapsed\n);
} else
passed = ktime_sub(now, apic-timer.last_update);
And now apic timer base is hr_timer with CLOCK_MONOTONIC, and get_time() is
really ktime_get() which is almost impossible to wrap around. If it's
overflow, at least we need a warning. I think this piece of code due to
clock
source change.
So I doubt: due to some reason, now = apic-timer.last_update, which cause
a
big wrap around operation.
And the most suspect:
void kvm_apic_timer_intr_post(struct kvm_vcpu *vcpu, int vec)
{
struct kvm_lapic *apic = vcpu-arch.apic;
if (apic apic_lvt_vector(apic, APIC_LVTT) == vec)
apic-timer.last_update = ktime_add_ns(
apic-timer.last_update,
apic-timer.period);
}
Not sure what's happening, have you tried this? (In fact, I am little
willing
to replace all apic-timer.dev.base-get_time() with more explicit
ktime_get()
as in pit.)
Yes, this code is the culprit. Using that patch of yours now is always
last_update. I'd still like to see that while loop go away ;-).
Glad it works. :)
I think it's a little similar to the PIT problem that Marcelo fixed, but I
am not sure about the reason. Anyone got idea?
Anyway, I would like to post a patch later.
--
regards
Yang, Sheng |Intel Opensource Technology Center
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix almost infinite loop in APIC
On Fri, Jan 09, 2009 at 01:57:30PM +0100, Alexander Graf wrote:
Sheng Yang wrote:
On Friday 09 January 2009 00:36:06 Alexander Graf wrote:
While booting Linux in VMware ESX, I encountered a strange effect
in the in-kernel lapic implementation: time went backwards!
While this should never occur, because of that the while loop that
is done after the invalid calculations caused my host system to hang.
In order to make debugging easier, let's replace this as suggested
with a modulo function and not run into the danger of looping forever.
To replace the nice hint this bug gave me that the values are broken,
I added a printk message so people encountering this can at least
see that something is fishy.
Of course, the real issue needs to be fixed as well! I'm open to ideas
why now last_update!
(Thanks to Kevin for his help in debugging this)
Signed-off-by: Alexander Graf ag...@suse.de
Signed-off-by: Kevin Wolf kw...@suse.de
---
Hi Alexander
I'm a little suspect here:
if (unlikely(ktime_to_ns(now) =
ktime_to_ns(apic-timer.last_update))) {
/* Wrap around */
passed = ktime_add(( {
(ktime_t) {
.tv64 = KTIME_MAX -
(apic-timer.last_update).tv64}; }
), now);
apic_debug(time elapsed\n);
} else
passed = ktime_sub(now, apic-timer.last_update);
And now apic timer base is hr_timer with CLOCK_MONOTONIC, and get_time() is
really ktime_get() which is almost impossible to wrap around. If it's
overflow, at least we need a warning. I think this piece of code due to
clock
source change.
So I doubt: due to some reason, now = apic-timer.last_update, which cause
a
big wrap around operation.
And the most suspect:
void kvm_apic_timer_intr_post(struct kvm_vcpu *vcpu, int vec)
{
struct kvm_lapic *apic = vcpu-arch.apic;
if (apic apic_lvt_vector(apic, APIC_LVTT) == vec)
apic-timer.last_update = ktime_add_ns(
apic-timer.last_update,
apic-timer.period);
}
Not sure what's happening, have you tried this? (In fact, I am little
willing
to replace all apic-timer.dev.base-get_time() with more explicit
ktime_get()
as in pit.)
Yes, this code is the culprit. Using that patch of yours now is always
last_update. I'd still like to see that while loop go away ;-).
Oh, for the loop, let's ask Avi. :)
--
regards
Yang, Sheng |Intel Opensource Technology Center
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix almost infinite loop in APIC
On Fri, Jan 09, 2009 at 01:57:30PM +0100, Alexander Graf wrote:
Sheng Yang wrote:
On Friday 09 January 2009 00:36:06 Alexander Graf wrote:
While booting Linux in VMware ESX, I encountered a strange effect
in the in-kernel lapic implementation: time went backwards!
While this should never occur, because of that the while loop that
is done after the invalid calculations caused my host system to hang.
In order to make debugging easier, let's replace this as suggested
with a modulo function and not run into the danger of looping forever.
To replace the nice hint this bug gave me that the values are broken,
I added a printk message so people encountering this can at least
see that something is fishy.
Of course, the real issue needs to be fixed as well! I'm open to ideas
why now last_update!
(Thanks to Kevin for his help in debugging this)
Signed-off-by: Alexander Graf ag...@suse.de
Signed-off-by: Kevin Wolf kw...@suse.de
---
Hi Alexander
I'm a little suspect here:
if (unlikely(ktime_to_ns(now) =
ktime_to_ns(apic-timer.last_update))) {
/* Wrap around */
passed = ktime_add(( {
(ktime_t) {
.tv64 = KTIME_MAX -
(apic-timer.last_update).tv64}; }
), now);
apic_debug(time elapsed\n);
} else
passed = ktime_sub(now, apic-timer.last_update);
And now apic timer base is hr_timer with CLOCK_MONOTONIC, and get_time() is
really ktime_get() which is almost impossible to wrap around. If it's
overflow, at least we need a warning. I think this piece of code due to
clock
source change.
So I doubt: due to some reason, now = apic-timer.last_update, which cause
a
big wrap around operation.
And the most suspect:
void kvm_apic_timer_intr_post(struct kvm_vcpu *vcpu, int vec)
{
struct kvm_lapic *apic = vcpu-arch.apic;
if (apic apic_lvt_vector(apic, APIC_LVTT) == vec)
apic-timer.last_update = ktime_add_ns(
apic-timer.last_update,
apic-timer.period);
}
Not sure what's happening, have you tried this? (In fact, I am little
willing
to replace all apic-timer.dev.base-get_time() with more explicit
ktime_get()
as in pit.)
Yes, this code is the culprit. Using that patch of yours now is always
last_update. I'd still like to see that while loop go away ;-).
(I would say all in one mail, but it always comes a little later... :) )
I think at least part of comment for the while loop should be kept...
--
regards
Yang, Sheng |Intel Opensource Technology Center
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/7] KVM: Add a route layer to convert MSI message to GSI
On Fri, Jan 09, 2009 at 08:06:01PM +0200, Avi Kivity wrote: Sheng Yang wrote: I just use it as #ifdef in userspace now, for no user other than MSI/MSI-X now. And if we keep maintaining it in kernel, we would return free size instead of maximum size.. We need to allow userspace to change pic/ioapic routing for the HPET. There are two styles of maintaining the table: 1. add/remove ioctls The advantage is that very little work needs to be done when something changes, but the code size (and bug count) doubles. 2. replace everything ioctl Smaller code size, but slower if there are high frequency changes I don't think we'll see high frequency interrupt routing changes; we'll probably have one on setup (for HPET), another when switching from ACPI PIC mode to ACPI APIC mode, and one for every msi initialized. Hi, Avi After reconsidering, I must say I prefer add/remove ioctls. About the code size, I don't think it would increase much. I've rewritten the code twice, I think I know the difference is little. For the option 2 route table ioctl, we got a array from userspace, and would convert it to linked list and keep it in kernel. That's a kind of must(I don't think you would prefer use a array in kernel), and it's very direct. So, we have to insert/delete route entry for both. What's the real difference we do it one by one or do it all at once. I don't think it is much different on the code size. And it's indeed very clear and direct. Beside this, option 2 seems strange. Why should we handle this table in this way when it won't result in significant code reduce. Insert/delete entry it there, look up entry is also there, not many things changed. And it's not that direct as option 1, which also can be a source of bugs. How do you think? -- regards Yang, Sheng |Intel Opensource Technology Center -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2487340 ] Possible memory corruption when file RAM
Bugs item #2487340, was opened at 2009-01-05 13:39 Message generated for change (Settings changed) made by amitshah You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2487340group_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: None Group: None Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Jake Muss (jaketmuss) Assigned to: Nobody/Anonymous (nobody) Summary: Possible memory corruption when file RAM Initial Comment: Host: Debian Lenny AMD64, Intel Q6600 , kvm-82 Guest, Debian Lenny AMD64 I've been having issues with file corruption and I've simplified the issue down to the following: create a 1G file: dd if=/dev/urandom of=1G bs=1G count=1 md5sum the file twice and the results will be different. I've tested this on ext2, ext3, backing device lvm,qcow2,raw If I change the RAM to 2G, I can then correctly md5sum the original file, however if I create a new file that's 2G the issue reappears. The only time the test has not failed was for the first few tests after the odd reboot. -- Comment By: Amit Shah (amitshah) Date: 2009-01-10 18:17 Message: I can't reproduce this on a Lenny guest on an F10 host. Both are 64-bit. Can you try reproducing this with -no-kvm and report the results? -- Comment By: Jake Muss (jaketmuss) Date: 2009-01-09 17:48 Message: Guest RAM. I have also now tried using Fedora 10 as a guest and using Debian Lenny i386 (32 bit) as a guest, still have the same issue. I ram memcheck for one pass in fedora and that didnlt come up with anything, and also one pass on the host. I'm not able to take the host down for long periods. Lastly, I seem to be able to get the same md5 sum if nothing else is causing a big change the page cache, however the md5sum is still wrong and won't be repeated later on. So I guess it's either getting into the cache incorrectly, or something to do with the way is accessed. I did some other tests with a binary diff and in a 1 gig file I had about 8 bits different. -- Comment By: Amit Shah (amitshah) Date: 2009-01-09 17:26 Message: Which RAM do you mean? Host RAM or guest RAM? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2487340group_id=180599 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2487340 ] Possible memory corruption when file RAM
Bugs item #2487340, was opened at 2009-01-05 21:09 Message generated for change (Comment added) made by jaketmuss You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2487340group_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: None Group: None Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Jake Muss (jaketmuss) Assigned to: Nobody/Anonymous (nobody) Summary: Possible memory corruption when file RAM Initial Comment: Host: Debian Lenny AMD64, Intel Q6600 , kvm-82 Guest, Debian Lenny AMD64 I've been having issues with file corruption and I've simplified the issue down to the following: create a 1G file: dd if=/dev/urandom of=1G bs=1G count=1 md5sum the file twice and the results will be different. I've tested this on ext2, ext3, backing device lvm,qcow2,raw If I change the RAM to 2G, I can then correctly md5sum the original file, however if I create a new file that's 2G the issue reappears. The only time the test has not failed was for the first few tests after the odd reboot. -- Comment By: Jake Muss (jaketmuss) Date: 2009-01-11 02:02 Message: I've tested with -no-kvm-irqchip, -no-kvm-pit switch and -no-kvm, all have the same result. -- Comment By: Amit Shah (amitshah) Date: 2009-01-11 01:47 Message: I can't reproduce this on a Lenny guest on an F10 host. Both are 64-bit. Can you try reproducing this with -no-kvm and report the results? -- Comment By: Jake Muss (jaketmuss) Date: 2009-01-10 01:18 Message: Guest RAM. I have also now tried using Fedora 10 as a guest and using Debian Lenny i386 (32 bit) as a guest, still have the same issue. I ram memcheck for one pass in fedora and that didnlt come up with anything, and also one pass on the host. I'm not able to take the host down for long periods. Lastly, I seem to be able to get the same md5 sum if nothing else is causing a big change the page cache, however the md5sum is still wrong and won't be repeated later on. So I guess it's either getting into the cache incorrectly, or something to do with the way is accessed. I did some other tests with a binary diff and in a 1 gig file I had about 8 bits different. -- Comment By: Amit Shah (amitshah) Date: 2009-01-10 00:56 Message: Which RAM do you mean? Host RAM or guest RAM? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2487340group_id=180599 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2][RFC] virtio_net: Add MAC fitler table support
On Sat, 2009-01-10 at 21:48 +1030, Rusty Russell wrote: On Thursday 08 January 2009 04:36:03 Alex Williamson wrote: virtio_net: Add MAC fitler table support Ah, I see. You really want multiple mac addresses, not just multicast filtering? Anthony, you think a control channel? We can add a virtqueue, but it seems like a lot of work... Right, a MAC filter table followed by a VLAN filter table. I've got a virtqueue control channel mostly coded up, I should have something to send out early next week for comments. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2][RFC] virtio_net: Add MAC fitler table support
Rusty Russell wrote: On Thursday 08 January 2009 04:36:03 Alex Williamson wrote: virtio_net: Add MAC fitler table support Ah, I see. You really want multiple mac addresses, not just multicast filtering? Anthony, you think a control channel? We can add a virtqueue, but it seems like a lot of work... I think it's the only way to solve the problem in a virtio friendly way. Another option would be extending the config space by a very large size. We would have to make some changes to virtio-pci to switch to MMIO but that's easy enough. From a high level perspective, I don't like the idea of having the config space be extremely large and used as a communication mechanism between guests. It really should be for device configuration data that's relatively static. I think we abuse the config space in the virtio-balloon driver. Ideally, you'd have an area of guest memory sized by the guest (so there was no intrinsic limit on table size) that was given to the host to use as the filter tables. The only way this works with virtio is if you send this over a virtqueue in the form of messages. You could write a pfn to the config space but then you lose all the mapping/unmapping abstraction that virtqueue gives you (even though we don't do anything useful with that abstraction today :-)). So yeah, I think a control queue is the way to go. Regards, Anthony Liguori Rusty. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2][RFC] virtio_net: Add MAC fitler table support
On Sat, 2009-01-10 at 12:18 -0600, Anthony Liguori wrote: Ideally, you'd have an area of guest memory sized by the guest (so there was no intrinsic limit on table size) that was given to the host to use as the filter tables. The only way this works with virtio is if you send this over a virtqueue in the form of messages. You could write a pfn to the config space but then you lose all the mapping/unmapping abstraction that virtqueue gives you (even though we don't do anything useful with that abstraction today :-)). Hmm, that's not quite how I was implementing it. The uc_list and mc_list are stored up in the netdev level, so there's not much point in duplicating it in the guest virtio-net driver. The interface I was working on has two commands. The first tells the host to allocate the MAC filter table for a guest provided number of entries (perhaps a module parameter, with reasonable default). The other is a set command with an sg entry providing a buffer of all the MAC entries for the table. If sg entries are no more than a page, this limits us to ~680 MAC table entries, which I think is far more than any piece of real hardware (and large enough that you'd probably want to turn on promiscuous already). The VLAN equivalent is a bit easier since by definition there are 4k possible VLANs. There I think a set bit/clear bit message interface is appropriate (and maybe a clear all for a reset condition). Let me know if that sounds reasonable. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2][RFC] virtio_net: Add MAC fitler table support
Alex Williamson wrote: Hmm, that's not quite how I was implementing it. The uc_list and mc_list are stored up in the netdev level, so there's not much point in duplicating it in the guest virtio-net driver. The interface I was working on has two commands. The first tells the host to allocate the MAC filter table for a guest provided number of entries (perhaps a module parameter, with reasonable default). The other is a set command with an sg entry providing a buffer of all the MAC entries for the table. If sg entries are no more than a page, this limits us to ~680 MAC table entries, which I think is far more than any piece of real hardware (and large enough that you'd probably want to turn on promiscuous already). Yeah, this is what I would have done although maybe it's worth allowing a partial update of the filter table. Once you're using a command interface, a protocol like you describe makes sense. I was simply going the through the logic that led me to suggest a command interface in the first place. The VLAN equivalent is a bit easier since by definition there are 4k possible VLANs. There I think a set bit/clear bit message interface is appropriate (and maybe a clear all for a reset condition). Let me know if that sounds reasonable. Thanks, Yeah, sounds reasonable to me. Regards, Anthony Liguori Alex -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
subscribe kvm -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
PCI pass-through: guest can't map memory
Hi! (please CC me, as I'm not subscribed) I try to give the guest (Windows XP) direct access to one of the graphics adaptors. However, the driver in the guest always complains: Unable to map required address ranges for graphics card. Any idea what the problem could be? Attached is a kvm log with DEVICE_ASSIGNMENT_DEBUG = 1. This is kvm-82 on AMD64 with kernel 2.6.28. lspci of the graphics adaptor: 02:00.0 VGA compatible controller: ATI Technologies Inc Radeon HD 3870 (prog-if 00 [VGA controller]) Subsystem: PC Partner Limited Device e620 Flags: bus master, fast devsel, latency 0, IRQ 1278 Memory at c000 (64-bit, prefetchable) [size=256M] Memory at fdfe (64-bit, non-prefetchable) [size=64K] I/O ports at ee00 [size=256] Expansion ROM at fdf0 [disabled] [size=128K] Capabilities: [50] Power Management version 3 Capabilities: [58] Express Legacy Endpoint, MSI 00 Capabilities: [a0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable+ Capabilities: [100] Vendor Specific Information ? syslog: Jan 11 00:48:33 schmafu kernel: [ 8195.816067] kvm: guest NX capability removed Jan 11 00:48:33 schmafu kernel: [ 8195.881523] pci :02:00.0: PCI INT A - GSI 18 (level, low) - IRQ 18 Jan 11 00:48:33 schmafu kernel: [ 8195.885445] kvm: guest NX capability removed Jan 11 00:48:33 schmafu kernel: [ 8196.119376] pci :02:00.0: irq 1278 for MSI/MSI-X Resources as seen in the guest: Memory Address: 0xE000-0xFEBF Memory Address: 0xF201-0xF201 I/O Port: 0xC300-0xC3FF IRQ:10 Cheers, harry init_assigned_device: Registering real physical device 02:00.0 (bus=2 dev=0 func=0) get_real_device: region 0 size 268435456 start 0xc000 type 4608 resource_fd 15 get_real_device: region 2 size 65536 start 0xfdfe type 512 resource_fd 16 get_real_device: region 4 size 256 start 0xee00 type 256 resource_fd 0 assigned_dev_pci_read_config: (5.0): address= val=0x1002 len=2 assigned_dev_pci_read_config: (5.0): address=0002 val=0x9501 len=2 assigned_dev_pci_read_config: (5.0): address= val=0x1002 len=2 assigned_dev_pci_read_config: (5.0): address=0002 val=0x9501 len=2 assigned_dev_pci_read_config: (5.0): address= val=0x1002 len=2 assigned_dev_pci_read_config: (5.0): address=0002 val=0x9501 len=2 assigned_dev_pci_read_config: (5.0): address=000a val=0x0300 len=2 assigned_dev_pci_read_config: (5.0): address= val=0x1002 len=2 assigned_dev_pci_read_config: (5.0): address=0002 val=0x9501 len=2 assigned_dev_pci_write_config: (5.0): address=0010 val=0x len=4 assigned_dev_pci_read_config: (5.0): address=0010 val=0xf008 len=4 assigned_dev_pci_read_config: (5.0): address=0010 val=0xf008 len=4 assigned_dev_pci_write_config: (5.0): address=0010 val=0x9000 len=4 assigned_dev_iomem_map: e_phys=9000 r_virt=0x65b83000 type=8 len=1000 region_num=0 assigned_dev_pci_read_config: (5.0): address=0004 val=0x0403 len=2 assigned_dev_pci_write_config: (5.0): address=0004 val=0x0403 len=2 assigned_dev_pci_write_config: NON BAR (5.0): address=0004 val=0x0403 len=2 assigned_dev_pci_write_config: (5.0): address=0014 val=0x len=4 assigned_dev_pci_read_config: (5.0): address=0014 val=0x len=4 assigned_dev_pci_write_config: (5.0): address=0018 val=0x len=4 assigned_dev_pci_read_config: (5.0): address=0018 val=0x len=4 assigned_dev_pci_read_config: (5.0): address=0018 val=0x len=4 assigned_dev_pci_write_config: (5.0): address=0018 val=0xf201 len=4 assigned_dev_iomem_map: e_phys=f201 r_virt=0x65b73000 type=0 len=0001 region_num=2 assigned_dev_pci_read_config: (5.0): address=0004 val=0x0403 len=2 assigned_dev_pci_write_config: (5.0): address=0004 val=0x0403 len=2 assigned_dev_pci_write_config: NON BAR (5.0): address=0004 val=0x0403 len=2 assigned_dev_pci_write_config: (5.0): address=001c val=0x len=4 assigned_dev_pci_read_config: (5.0): address=001c val=0x len=4 assigned_dev_pci_write_config: (5.0): address=0020 val=0x len=4 assigned_dev_pci_read_config: (5.0): address=0020 val=0xff01 len=4 assigned_dev_pci_read_config: (5.0): address=0020 val=0xff01 len=4 assigned_dev_pci_write_config: (5.0): address=0020 val=0xc300 len=4 assigned_dev_ioport_map: e_phys=0xc300 r_baseport=ee00 type=0x1 len=256 region_num=4 assigned_dev_pci_read_config: (5.0): address=0004 val=0x0403 len=2 assigned_dev_pci_write_config: (5.0): address=0004 val=0x0403 len=2 assigned_dev_pci_write_config: NON BAR (5.0): address=0004 val=0x0403 len=2 assigned_dev_pci_write_config: (5.0): address=0024 val=0x len=4 assigned_dev_pci_read_config: (5.0): address=0024 val=0x len=4 assigned_dev_pci_write_config: (5.0): address=0030 val=0x len=4 assigned_dev_pci_write_config: NON BAR (5.0): address=0030 val=0x len=4
[PATCH 0/1] pci hole remaping
kind of simple, i would send one to qemu later (need to check something first Spice need this, it allow more memory cache (badly needed when runing with multiple screens) -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] kvm-userspace: set pci mem to start at 0xc100000 and vesa to 0xc000000
This patch make the pci mem region larger (1 giga now).
this is needed for pci devices that require large amount of memory
such as video cards.
for pea guests this patch is not an issue beacuse the guest OS will map
the rest of the ram after 0x1...,
for 32bits that arent pea, it mean the maximum memory that would be
avaible now is 3giga.
Signed-off-by: Izik Eidus iei...@redhat.com
---
bios/acpi-dsdt.dsl |2 +-
bios/rombios.c |2 +-
bios/rombios32.c| 10 +-
qemu/hw/pc.c|6 +++---
qemu/hw/vga_int.h |2 +-
qemu/hw/vmware_vga.c|4 ++--
qemu/kvm-tpr-opt.c |2 +-
qemu/qemu-kvm.c |2 +-
vgabios/vbe.h |2 +-
vgabios/vbe_display_api.txt |2 +-
10 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/bios/acpi-dsdt.dsl b/bios/acpi-dsdt.dsl
index d67616d..78061ab 100755
--- a/bios/acpi-dsdt.dsl
+++ b/bios/acpi-dsdt.dsl
@@ -226,7 +226,7 @@ DefinitionBlock (
,, , AddressRangeMemory, TypeStatic)
DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed,
NonCacheable, ReadWrite,
0x, // Address Space Granularity
-0xE000, // Address Range Minimum
+0xC000, // Address Range Minimum
0xFEBF, // Address Range Maximum
0x, // Address Translation Offset
0x1EC0, // Address Length
diff --git a/bios/rombios.c b/bios/rombios.c
index c4f6ccd..146dd52 100644
--- a/bios/rombios.c
+++ b/bios/rombios.c
@@ -9829,7 +9829,7 @@ pcibios_init_sel_reg:
pcibios_init_iomem_bases:
push bp
mov bp, sp
- mov eax, #0xe000 ;; base for memory init
+ mov eax, #0xc000 ;; base for memory init
push eax
mov ax, #0xc000 ;; base for i/o init
push ax
diff --git a/bios/rombios32.c b/bios/rombios32.c
index ab37e13..dceaff6 100755
--- a/bios/rombios32.c
+++ b/bios/rombios32.c
@@ -565,8 +565,8 @@ void setup_mtrr(void)
wrmsr_smp(MSR_MTRRfix4K_E8000, 0);
wrmsr_smp(MSR_MTRRfix4K_F, 0);
wrmsr_smp(MSR_MTRRfix4K_F8000, 0);
-/* Mark 3.5-4GB as UC, anything not specified defaults to WB */
-wrmsr_smp(MTRRphysBase_MSR(0), 0xe000ull | 0);
+/* Mark 3-4GB as UC, anything not specified defaults to WB */
+wrmsr_smp(MTRRphysBase_MSR(0), 0xc000ull | 0);
wrmsr_smp(MTRRphysMask_MSR(0), ~(0x2000ull - 1) | 0x800);
wrmsr_smp(MSR_MTRRdefType, 0xc06);
}
@@ -924,8 +924,8 @@ static void pci_bios_init_device(PCIDevice *d)
case 0x0300: /* Display controller - VGA compatible controller */
if (vendor_id != 0x1234)
goto default_map;
-/* VGA: map frame buffer to default Bochs VBE address */
-pci_set_io_region_addr(d, 0, 0xE000);
+/* VGA: map frame buffer */
+pci_set_io_region_addr(d, 0, 0xC000);
break;
case 0x0800: /* Generic system peripheral - PIC */
if (vendor_id == PCI_VENDOR_ID_IBM) {
@@ -1016,7 +1016,7 @@ void pci_for_each_device(void (*init_func)(PCIDevice *d))
void pci_bios_init(void)
{
pci_bios_io_addr = 0xc000;
-pci_bios_mem_addr = 0xf000;
+pci_bios_mem_addr = 0xc000 + 0x100;
pci_bios_bigmem_addr = ram_size;
if (pci_bios_bigmem_addr 0x9000)
pci_bios_bigmem_addr = 0x9000;
diff --git a/qemu/hw/pc.c b/qemu/hw/pc.c
index c470646..c04d9b6 100644
--- a/qemu/hw/pc.c
+++ b/qemu/hw/pc.c
@@ -821,9 +821,9 @@ static void pc_init1(ram_addr_t ram_size, int vga_ram_size,
BlockDriverState *hd[MAX_IDE_BUS * MAX_IDE_DEVS];
BlockDriverState *fd[MAX_FD];
-if (ram_size = 0xe000 ) {
-above_4g_mem_size = ram_size - 0xe000;
-below_4g_mem_size = 0xe000;
+if (ram_size = 0xc000 ) {
+above_4g_mem_size = ram_size - 0xc000;
+below_4g_mem_size = 0xc000;
} else {
below_4g_mem_size = ram_size;
}
diff --git a/qemu/hw/vga_int.h b/qemu/hw/vga_int.h
index 65ac68a..64f594a 100644
--- a/qemu/hw/vga_int.h
+++ b/qemu/hw/vga_int.h
@@ -59,7 +59,7 @@
#define VBE_DISPI_LFB_ENABLED 0x40
#define VBE_DISPI_NOCLEARMEM0x80
-#define VBE_DISPI_LFB_PHYSICAL_ADDRESS 0xE000
+#define VBE_DISPI_LFB_PHYSICAL_ADDRESS 0xC000
#ifdef CONFIG_BOCHS_VBE
diff --git a/qemu/hw/vmware_vga.c b/qemu/hw/vmware_vga.c
index e30d03f..028bf81 100644
--- a/qemu/hw/vmware_vga.c
+++ b/qemu/hw/vmware_vga.c
@@ -119,14 +119,14 @@ struct pci_vmsvga_state_s {
# define SVGA_IO_BASE SVGA_LEGACY_BASE_PORT
# define SVGA_IO_MUL 1
# define SVGA_FIFO_SIZE0x1
-# define SVGA_MEM_BASE 0xe000
+# define SVGA_MEM_BASE 0xc000
# define SVGA_PCI_DEVICE_IDPCI_DEVICE_ID_VMWARE_SVGA2
#else
# define SVGA_ID SVGA_ID_1
# define
kvm-82 doesn't boot 64bit (?) [cpu0 unhandled wrmsr]
ciao, I have a problem to run a 64 bit intel guest inside a 64 bit intel host. It doesn' boot. host: Intel(R) Core(TM)2 CPU 6420 @ 2.13GHz OS: ubuntu 8.10 64 bit ($ file /bin/ls/bin/ls: ELF 64-bit LSB xecutable, x86-64,...) kvm-82 $ modinfo kvm filename: /lib/modules/2.6.27-9-server/extra/kvm.ko license:GPL author: Qumranet version:kvm-82 srcversion: 26E72577C6F752FF6FCE2AE depends: vermagic: 2.6.27-9-server SMP mod_unload modversions parm: oos_shadow:bool parm: msi2intx:bool $ modinfo kvm_intel filename: /lib/modules/2.6.27-9-server/extra/kvm-intel.ko license:GPL author: Qumranet version:kvm-82 srcversion: 6F53E897CA902DDC25AC326 depends:kvm vermagic: 2.6.27-9-server SMP mod_unload modversions parm: bypass_guest_pf:bool parm: enable_vpid:bool parm: flexpriority_enabled:bool parm: enable_ept:bool parm: emulate_invalid_guest_state:bool trying to boot the guest: /usr/local/bin/qemu-system-x86_64 -cpu core2duo -hda ./ubuntu-server-8.10_64bit.root -cdrom /home/vm/iso/ubuntu/ubuntu-8.10-server-i386.iso -k it -usbdevice tablet -boot d as soon as I run this command, in syslog appear: cpu0: unhandled wrmsr: 0xc0010117 data 0 (always the same address) and in the guest window, the latest 3 lines: Initializing cgroup subsys ns Initializing cgroup subsys cpuacct Initializing cgroup subsys memory (screendump in attachment) the same with -cpu: coreduo no problem (but still appear unhandled wrmsr error) with all the other cpu questions: 1) with -cpu qemu64 I obtain in the guest: cat /proc/cpuinfo vendor_id: GenuineIntel but it doesn't seem a 64 bit cpu (?) 2) can I do some deeper debug to provide more useful info? (or suggest me a different command-line) 3) what does logfile command (should) do? CTRL-ALT-2 logfile /tmp/logfile but there is no /tmp/logfile on host thank you. -- /* Paolo Pedaletti, * pa...@pedaletti.it www.pedaletti.it */ inline: screendump.gif
Re: Linux in VirtualPC in KVM fails
Anthony Liguori wrote: Apparently it isn't. I know of one other fullvirt product that does not jit kernel code. Or maybe they wanted to preserve consistency between kernel cpuid and host cpuid. How can you get away with not jitting kernel code? http://bellard.org/qemu/kqemu-tech.html#SEC12 -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux in VirtualPC in KVM fails
Anthony Liguori wrote: Alexander Graf wrote: Isn't one of the great things about virtualization the fact that you can do things you can on real hardware in the virtual machine? While I'm not exactly a fan of VirtualPC, I would still like it to work in KVM, as that's what real hardware is capable of. Paravirtualization support is advertised in userspace, just add a flag to QEMU to disable KVM paravirt support. That's helpful. But I would like (in addition) a fix that does not require administrative involvement. The host admin should not need to know anything about what the guest runs. That's not achievable in practice, but where it is, we want it. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Messy headers
Anthony Liguori wrote: kvm-userspace installs: /usr/local/include/linux/kvm.h /usr/local/include/linux/kvm_para.h This relies on asm/kvm.h Which is not installed. libkvm.h depends on an up-to-date version of kvm.h to function properly. Perhaps we should just stop installing all headers since libkvm is probably not going to be a supported library? Done. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
