[ kvm-Bugs-1991647 ] 32bits Rhel5/FC6 guest may fail to reboot after installation

2008-06-12 Thread SourceForge.net 
Bugs item #1991647, was opened at 2008-06-12 15:59
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1991647&group_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: yunfeng (yunfeng)
Assigned to: Nobody/Anonymous (nobody)
Summary: 32bits Rhel5/FC6 guest may fail to reboot after installation

Initial Comment:

Environment:

HOST:ia32pae
Guest:  ia32pae
Commits: 
Kernel 92d9acbf598427c88922344ae129774f1543bc6e
Userspace 3dfbbe4718d7b95b47381dcd4f341178a8ff2195
Hardware: Platform Woodcrest
 CPU4
 Memory size8G'



Bug detailed description:
--
32bits Rhel5/FC6 guests may fail to reboot after installation. I met guest
kernel panic several times at the second reboot after installation, see the
attachments.(first reboot for some config works, second reboot will log in
system)


The issue will happen when both installing over network and from cdrom.
command is:
qemu-system-x86_64 -m 512 -smp 2 -net
nic,macaddr=00:16:3e:27:43:fa,model=rtl8139 -net tap,script=/etc/kvm/qemu-ifup
-hda ./golden-grub.img
using cdrom should add option "-cdrom ./rhel5.iso".

This issue can be reproduced at a rate of 40%.


Reproduce steps:



Current result:



Expected result:



Basic root-causing log:
--


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1991647&group_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

[ kvm-Bugs-1991653 ] vista auto-unattended installation failed on kvm guests

2008-06-12 Thread SourceForge.net 
Bugs item #1991653, was opened at 2008-06-12 16:05
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1991653&group_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: yunfeng (yunfeng)
Assigned to: Nobody/Anonymous (nobody)
Summary: vista auto-unattended installation failed on kvm guests

Initial Comment:
Environment:

Host:ia32pae/ia32e
Guest: Vista RC1 ia32pae/ia32e

Bug detailed description:
-
With vista auto unattended installation ISO, vista installer will stop at
"please wait..." with no response, see the attached picture. 
And met the same problem with --no-kvm.
The same auto install ISO works well on Xen guest.
With vista original ISO (manually installing), guest can install successfully. 

The auto answer file of the iso is attached.


Reproduce steps:



Current result:



Expected result:



Basic root-causing log:
--


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1991653&group_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

[ kvm-Bugs-1991653 ] vista auto-unattended installation failed on kvm guests

2008-06-12 Thread SourceForge.net 
Bugs item #1991653, was opened at 2008-06-12 16:05
Message generated for change (Comment added) made by yunfeng
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1991653&group_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: yunfeng (yunfeng)
Assigned to: Nobody/Anonymous (nobody)
Summary: vista auto-unattended installation failed on kvm guests

Initial Comment:
Environment:

Host:ia32pae/ia32e
Guest: Vista RC1 ia32pae/ia32e

Bug detailed description:
-
With vista auto unattended installation ISO, vista installer will stop at
"please wait..." with no response, see the attached picture. 
And met the same problem with --no-kvm.
The same auto install ISO works well on Xen guest.
With vista original ISO (manually installing), guest can install successfully. 

The auto answer file of the iso is attached.


Reproduce steps:



Current result:



Expected result:



Basic root-causing log:
--


--

>Comment By: yunfeng (yunfeng)
Date: 2008-06-12 16:06

Message:
Logged In: YES 
user_id=1283543
Originator: YES

File Added: failed to auto install vista guest.JPG

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1991653&group_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

KVM Test result, kernel df4245d.., userspace 67a67de.. -- two new issues

2008-06-12 Thread Yunfeng Zhao 

Hi All,

This is today's KVM test result against kvm.git 
df4245dff396bd1671bdaf735b0529371b3b7112 and kvm-userspace.git 
67a67deba877c9a40572451f3b9abae1f98883e7.
Booting four 32e guests sequentially hang host once in auto testing, but 
hadn't reproduced it manully.
And we found two new issues about installation in a testing for guest 
installations.


Two New Issue:

1. 32bits Rhel5/FC6 guest may fail to reboot after installation
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1991647&group_id=180599
2.  vista auto-unattended installation failed on kvm guests
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1991653&group_id=180599

Five Old Issues:

3. Guests crash while rebooting
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1976075&group_id=180599 


4. Fail to save restore and live migrate
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1976075&group_id=180599 


5. netperf  causes linux guest with virtnet kernel panic
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1972449&group_id=180599 


6.  XP crashes while rebooting
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1959452&group_id=180599 


7. failure to migrate guests with more than 4GB of RAM
https://sourceforge.net/tracker/index.php?func=detail&aid=1971512&group_id=180599&atid=893831 



Test environment
 
PlatformWoodcrest

CPU 4
Memory size 8G'

Details

IA32-pae: 
1. boot guest with 256M memory   PASS

2. boot guest with 1500M memory PASS
3. boot 4 same guest in parallel PASS
4. boot two windows xp guestPASS
5. boot linux and windows guest in parallel  PASS
6. save/restore 32-bit HVM guests  FAIL
7. save/restore 32-bit HVM guests with 4 vcpus   FAIL
8. live migration 32-bit HVM guests FAIL
9. live migration 32-bit HVM guests with 4 vcpus  FAIL
10. boot base kernel linux  PASS
11. kernel build on SMP linux guestPASS
12. LTP on linux guest   
PASS

13. boot Windows 2000 without ACPI  PASS
14. boot Windows 2000 with ACPI enabled  PASS
15. boot Windows 2003 with ACPI enabled   PASS
16. boot Windows xp with ACPI enabled  PASS
17. boot Windows vista with ACPI enabled   PASS
18. boot SMP Windows 2000 with ACPI enabled  PASS
19. boot SMP Windows 2003 with ACPI enabled  PASS
20. boot SMP Windows xp with ACPI enabled  PASS
21. boot SMP Windows 2008 with ACPI enabled   PASS


IA32e: 
1. boot 32-bit guest with 256M memory   PASS

2. boot 64-bit guest with 256M memory   PASS
3. boot 32-bit guest with 1500M memory PASS
4. boot 64-bit guest with 1500M memory PASS
5. boot 4G pae 
guest PASS
6. boot 4G 64-bit 
guest  PASS
7. boot four 32-bit guest in 
parallel  PASS
8. boot four 64-bit guest in 
parallel  PASS

9. boot two 32-bit windows xp in parallel  PASS
10. boot 32-bit linux and 32 bit windows guest in parallel   PASS
11. boot four 32-bit different guest in para 
PASS
12. save/restore 32-bit linux guests 
FAIL
13. save/restore 64-bit linux guests 
FAIL

14. save/restore 64-bit linux guests with 4 vcpus   FAIL
15. save/restore 32-bit linux guests with 4 vcpus   FAIL
16. live migration 64bit linux 
guests FAIL
17. live migration 32bit linux 
guests FAIL

18. live migration 64bit linux guests with 4 vcpus   FAIL
19. live migration 32bit linux guests with 4 vcpus   FAIL
20. boot 32-bit 
x-server   PASS 
21. kernel build in 32-bit linux guest OS  PASS

22. kernel build in 64-bit linux guest OS  PASS
23. LTP on 32-bit linux guest OSPASS
24. LTP on 64-bit linux guest OS

Re: qemu-send.c (was Re: Since we're sharing, here's my kvmctl script)

2008-06-12 Thread Chris Webb 
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
  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

2008-06-12 Thread William Boughton 
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 Test result, kernel ff5bdac.., userspace eb2fd67.. -- OneNew Issue

2008-06-12 Thread Yunfeng Zhao 

Marcelo Tosatti wrote:

On Fri, Jun 06, 2008 at 11:11:12AM +0800, Yunfeng Zhao wrote:
  

Hi All,

This is today's KVM test result against kvm.git 
ff5bdac4be0230e0bb33e4208ac0a91343c72929 and kvm-userspace.git 
eb2fd67cbecdb573f908697ed41b81ee312372bd.


One New Issue:

1. Guests crash while rebooting
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1976075&group_id=180599


Five Old Issues:

2. Fail to save restore and live migrate
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1976075&group_id=180599
3. netperf  causes linux guest with virtnet kernel panic
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1972449&group_id=180599
4.  XP crashes while rebooting
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1959452&group_id=180599
5.Cannot boot guests with hugetlbfs
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1941302&group_id=180599



This is a get_user_pages() with hugetlb-vma's bug, not KVM's problem,
fixed by:

commit 5b23dbe8173c212d6a326e35347b038705603d39
Author: Adam Litke <[EMAIL PROTECTED]>
Date:   Wed Nov 14 16:59:33 2007 -0800

hugetlb: follow_hugetlb_page() for write access

When calling get_user_pages(), a write flag is passed in by the caller to

indicate if write access is required on the faulted-in pages.

Currently, follow_hugetlb_page() ignores this flag and always faults pages 
for
read-only access.  This can cause data corruption because a device driver
that calls get_user_pages() with write set will not expect COW faults to
occur on the returned pages.

This patch passes the write flag down to follow_hugetlb_page() and makes

sure hugetlb_fault() is called with the right write_access parameter.

Can you please upgrade your test hosts to 2.6.25 or newer? 
  

I tried to test it against 2.6.25-rc5.
The host hanged while booting a xp guest.

Thanks
Yunfeng

Perhaps kvm-userspace should check for kernel version and disable
hugetlb backed memory. Nasty.

Thanks John for help in tracking this down.

  


--
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

VT enabled in BIOS, still kvm says 'disabled by bios'

2008-06-12 Thread Sukanto Ghosh 

Hi all,

On my system:

Processor: Intel Core 2 Duo 6300  1.86 GHz
Motherboard: Intel DG965RY
OS: Ubuntu 7.10 (Gutsy)
Linux Kernel:  2.6.22-14-generic
BIOS has VT technology 'enable/disable' feature.

'cat /proc/cpuinfo' shows 'vmx' flags.
I checked and enabled the VT support in the BIOS.

'modprobe kvm' runs fine.
But still 'modprobe kvm_intel' gives 'operation not supported' error.

(I issued both of them after 'su')

After looking into the /var/log/syslog, file I found that the message is 
'kvm: disabled by bios'.



I am puzzled, please help me out. What's going wrong ?



Thanks and Regards,

Sukanto Ghosh
--
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: VT enabled in BIOS, still kvm says 'disabled by bios'

2008-06-12 Thread Laurent Vivier 
Hi,

You need to go through a power-down/power-up cycle.
(See the help associated with the flag in the BIOS)

Laurent

Le jeudi 12 juin 2008 à 16:04 +0530, Sukanto Ghosh a écrit :
> Hi all,
> 
> On my system:
> 
> Processor: Intel Core 2 Duo 6300  1.86 GHz
> Motherboard: Intel DG965RY
> OS: Ubuntu 7.10 (Gutsy)
> Linux Kernel:  2.6.22-14-generic
> BIOS has VT technology 'enable/disable' feature.
> 
> 'cat /proc/cpuinfo' shows 'vmx' flags.
> I checked and enabled the VT support in the BIOS.
> 
> 'modprobe kvm' runs fine.
> But still 'modprobe kvm_intel' gives 'operation not supported' error.
> 
> (I issued both of them after 'su')
> 
> After looking into the /var/log/syslog, file I found that the message is 
> 'kvm: disabled by bios'.
> 
> 
> I am puzzled, please help me out. What's going wrong ?
> 
> 
> 
> Thanks and Regards,
> 
> Sukanto Ghosh
> --
> 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
> 
-- 
- [EMAIL PROTECTED] ---
"The best way to predict the future is to invent it."
- Alan Kay

--
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: VT enabled in BIOS, still kvm says 'disabled by bios'

2008-06-12 Thread Sukanto Ghosh 

Thanks Laurent. I was always restarting the system.
I could successfully load kvm-intel module.

Thanks once again.


Laurent Vivier wrote:

Hi,

You need to go through a power-down/power-up cycle.
(See the help associated with the flag in the BIOS)

Laurent

Le jeudi 12 juin 2008 à 16:04 +0530, Sukanto Ghosh a écrit :
  

Hi all,

On my system:

Processor: Intel Core 2 Duo 6300  1.86 GHz
Motherboard: Intel DG965RY
OS: Ubuntu 7.10 (Gutsy)
Linux Kernel:  2.6.22-14-generic
BIOS has VT technology 'enable/disable' feature.

'cat /proc/cpuinfo' shows 'vmx' flags.
I checked and enabled the VT support in the BIOS.

'modprobe kvm' runs fine.
But still 'modprobe kvm_intel' gives 'operation not supported' error.

(I issued both of them after 'su')

After looking into the /var/log/syslog, file I found that the message is 
'kvm: disabled by bios'.



I am puzzled, please help me out. What's going wrong ?



Thanks and Regards,

Sukanto Ghosh
--
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




--
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: MMU: large page update_pte issue with non-PAE 32-bit guests (resend)

2008-06-12 Thread Avi Kivity 

Marcelo Tosatti wrote:

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.

  


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: [PATCH 0/4][VTD] kvm vt-d support kernel changes

2008-06-12 Thread Muli Ben-Yehuda 
On Tue, Jun 10, 2008 at 12:45:30PM -0700, Kay, Allen M wrote:
> Muli,
> 
> The userpsace branch is located at:
> 
> git.kernel.org/pub/scm/linux/kernel/git/amit/kvm-userspace.git vtd
> 
> I forgot to send out the userspace patch last night. :-)

Thanks Allen. I am trying to get the latest rev to work with the irq
injection method rather than irq chip. Amit's latest code overloads
KVM_ASSIGN_PCI_PT_DEV to inform the host kernel of guest IRQ changes,
so we either need something like the attachd patch to not map the
guest multiple times, or we need to introduce
KVM_PCI_PT_DEV_IRQ_CHANGE in additino to KVM_ASSIGN_PCI_PT_DEV.

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 1b50ba3..2d61375 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -305,6 +305,14 @@ static int kvm_vm_ioctl_pci_pt_dev(struct kvm *kvm,
goto out_free;
}
}
+
+   if (kvm_intel_iommu_found()) {
+   r = kvm_iommu_map_guest(kvm, pci_pt_dev);
+   if (r)
+   goto out_free;
+   }
+
write_lock_irqsave(&kvm_pci_pt_lock, flags);
 
INIT_WORK(&match->pt_dev.int_work.work, kvm_pci_pt_work_fn);
@@ -1962,11 +1970,6 @@ long kvm_arch_vm_ioctl(struct file *filp,
r = kvm_vm_ioctl_pci_pt_dev(kvm, &pci_pt_dev);
if (r)
goto out;
-   if (kvm_intel_iommu_found()) {
-   r = kvm_iommu_map_guest(kvm, &pci_pt_dev);
-   if (r)
-   goto out;
-   }
break;
}
case KVM_GET_PIT: {

Cheers,
Muli
--
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

2008-06-12 Thread Avi Kivity 

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

2008-06-12 Thread Avi Kivity 

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: [PATCH] kvm-ia64 irq assignment 1/2 kernel

2008-06-12 Thread Avi Kivity 

Xu, Anthony wrote:

Avi Kivity wrote:
  

I suggest modifying the firmware to report the interrupts as active
high.  Since Xen does not emulate polarity, the change will not affect
it and the firmware can continue to be shared.  I'd also recommend
fixing Xen to emulate the polarity correctly, if possible.



Thanks for your comments
I agree modifying common code is not a good method.

While your suggestion seems be infeasible too.
According to acpi spec, only irq <=15 can be configured, such as trigger
level, polarity.
For irq >15 , means connect to IOAPIC directly, it can't be configured,
it must be level triger, active low.
  


Yes.


I can't find any mechanism in firmware to configure irqs (> 15). Please
enlighten me if you have.

  


Okay. In any case we should emulate hardware as closely as possible to 
reality, so mu suggestion wasn't a good one.



I think below scheme is feasible,
1. all PCI devices in Qemu uses level trigger, active low interrupt.
(not include ide, even though it is a PCI device, it uses legacy
interrupt mechanism)

2. in Guest Firmware, all PCI devices' interrupts are configured as
level trigger, active low 
   for KVM/IA32 Guest firmware, just a little modifications

Name(_PRS, ResourceTemplate(){
Interrupt (, Level, ActiveHigh, Shared)--> Interrupt
(, Level, ActiveLow, Shared)


There are some modifications in Qemu, But I think it's a worthwhile,
it's a thoroghly solution both for KVM/IA32 and KVM/IA64.

  


I agree. Note that the piix chipset used on x86 inverts the pci 
interrupts again so they become active high. But for ioapic mode we may 
be able to use active low interrupts.


--
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

2008-06-12 Thread Avi Kivity 

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 2/11] QEMU/KVM: Cleanup and improve kvm_load/save_registers usage

2008-06-12 Thread Avi Kivity 

Anthony Liguori wrote:

Jan Kiszka wrote:

Remove redundant checkes for kvm_enabled() on register updates between
userspace and kvm kernel driver. Ensure register update across all CPUs
on "info cpus" monitor command.
  


This breaks the build when KVM is disabled.  The explicit guard is 
needed to avoid having #ifdefs.  Please revert.




You mean a link time error?  Well in that case we're relying on gcc 
optimizing away the call.  It will break with -O0.


The correct fix is to define stubs for the case kvm is configured out 
(or just use ifdefs).  But perhaps Glauber's accelerator framework will 
take care of all this in a generic fashion.


--
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

2008-06-12 Thread Avi Kivity 
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: [PATCH] do not use extra env field.

2008-06-12 Thread Avi Kivity 

Xu, Anthony wrote:

Glauber Costa wrote:


There's no need to polute the already poluted CPUState
with "ready_for_interrupt_injection". We can compute it
in the few times we use it, and be fine.
  

Give a simple test
This patch is safe for ia64.
  


Thanks, I applied the patch.

--
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] Do not calculate linear rip in emulation failure report

2008-06-12 Thread Avi Kivity 

Glauber Costa wrote:

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.

This is a nitpick, but I saw it while doing some testing, so here's
the patch.

  


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: kvm causing memory corruption? now 2.6.26-rc4

2008-06-12 Thread Avi Kivity 

Dave Hansen wrote:

On Wed, 2008-06-04 at 16:42 +0300, Avi Kivity wrote:
  

Dave Hansen wrote:


...
  

After collecting all those, I turned on CONFIG_DEBUG_HIGHMEM and the
oopses miraculously stopped.  But, the guest hung (for at least 5
minutes or so) during windows bootup, pegging my host CPU.  Most of the
CPU was going to klogd, so I checked dmesg.

  
Can you check with mem=900 (and CONFIG_HIGHMEM_DEBUG=n)?  That will 
confirm that the problems are highmem related, but not physical address 
truncation related.



Do you mean 800M? ;) Highmem begins at 896MB if I remember correctly.

Anyway, it still oopses on current git with mem=800M

  


Stumped.  Please post .config, will try to reproduce.


I was seeing messages like this

[  428.918108] kvm_handle_exit: unexpected, valid vectoring info and exit 
reason is 0x9

And quite a few of them, like 100,000/sec.  That's why klogd was pegging
the CPU.  Any idea on a next debugging step?

  

That's a task switch.  Newer kvms handle them.



Newer userspace?  I'm running current kvm-git userspace as of a day or
two ago.
  


No, it's kernel code.

--
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: KVM Test result, kernel ff5bdac.., userspace eb2fd67.. -- One New Issue

2008-06-12 Thread Avi Kivity 

Marcelo Tosatti wrote:

Perhaps kvm-userspace should check for kernel version and disable
hugetlb backed memory. Nasty.

  


That means if a distro fixed this bug, then it would still suffer.  I 
don't think we can test for this?  Otherwise I see no choice but a 
version check.


--
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

[ kvm-Bugs-1985977 ] Guests crash while rebooting

2008-06-12 Thread SourceForge.net 
Bugs item #1985977, was opened at 2008-06-06 05:42
Message generated for change (Comment added) made by avik
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1985977&group_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: yunfeng (yunfeng)
Assigned to: Nobody/Anonymous (nobody)
Summary: Guests crash while rebooting 

Initial Comment:
Environment:

Commits:
ff5bdac4be0230e0bb33e4208ac0a91343c72929-eb2fd67cbecdb573f908697ed41b81ee312372bd
Hardware: woodcrest

Bug detailed description:
--
Windows and Linux guests can not reboot on ia32pae and ia32e platform, guests
crashed whilerebooting. 

There's messages on console:
[EMAIL PROTECTED] ~]#qemu-system-x86_64 -m 256 -monitor pty -net
nic,macaddr=00:16:3e:17:b9:e3,model=rtl8139 -net tar/fc6
char device redirected to /dev/pts/4
unhandled vm exit: 0x21 vcpu_id 0
rax 0011 rbx d8d1 rcx 0002c900 rdx
0700
rsi 009d rdi 0500 rsp fffa rbp
8271
r8   r9   r10  r11

r12  r13  r14  r15

rip b167 rflags 00010006
cs f000 (000f/ p 1 dpl 0 db 0 s 1 type b l 0 g 0 avl 0)
ds  (/ p 1 dpl 0 db 0 s 1 type 3 l 0 g 0 avl 0)
es c000 (000c/ p 1 dpl 0 db 0 s 1 type 3 l 0 g 0 avl 0)
ss  (/ p 1 dpl 0 db 0 s 1 type 3 l 0 g 0 avl 0)
fs  (/ p 1 dpl 0 db 0 s 1 type 3 l 0 g 0 avl 0)
gs  (/ p 1 dpl 0 db 0 s 1 type 3 l 0 g 0 avl 0)
tr 0040 (/ p 1 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0)
ldt  (/ p 1 dpl 0 db 0 s 0 type 2 l 0 g 0 avl 0)
gdt fb1f2/30
idt f/0
cr0 11 cr2 0 cr3 0 cr4 0 cr8 0 efer 0
Aborted



--

>Comment By: Avi Kivity (avik)
Date: 2008-06-12 16:26

Message:
Logged In: YES 
user_id=539971
Originator: NO

Okay, I reverted the patch.

--

Comment By: yunfeng (yunfeng)
Date: 2008-06-11 09:42

Message:
Logged In: YES 
user_id=1283543
Originator: YES

This patch can fix this issue.
After reverted pmode transaition rebooting works again.


--

Comment By: Avi Kivity (avik)
Date: 2008-06-09 19:10

Message:
Logged In: YES 
user_id=539971
Originator: NO

Please try the attached patch (apply to kernel tree)
File Added: revert-pmode-transition.patch

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1985977&group_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: [PATCH] kvm: kvmtrace: kvm_trace in kernel for supporting big_endian

2008-06-12 Thread Avi Kivity 

Jerone Young wrote:

This patch is not in yet. Wanted to make sure that it doesn't fall off
the radar. Please include upstream.
Acked-by: Jerone Young <[EMAIL PROTECTED]>

  


Thanks for the reminder.  Patch applied.

--
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: Doubts regarding Shadow Page Table Management in KVM

2008-06-12 Thread Avi Kivity 

Sukanto Ghosh wrote:


But I want to confirm whether a shadowed guest page refers to "the 
guest PT page that has a corresponding shadow PT page. And the 
corresponding shadow PT page is called the shadow of the former.  Am I 
right ?


Yes.

--
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

2008-06-12 Thread Avi Kivity 

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

2008-06-12 Thread Christian Borntraeger 
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

2008-06-12 Thread Freddie Cash 
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

2008-06-12 Thread Xu, Anthony 
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

RE: [RFC]RE: [PATCH] kvm-ia64 irq assignment 1/2 kernel

2008-06-12 Thread Xu, Anthony 
Marcelo Tosatti wrote:
> On Wed, Jun 11, 2008 at 07:24:09AM -0700, 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.
>> 
>>> 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"?
> 
> Hi Alexander, Anthony,
> 
> I think it would be better to avoid static PCI pin -> IOAPIC pin
> assignments, if PCI link devices can be used (allowing the OS to route
> IRQ's as it wishes to).
Seems PCI link device only support irq-pin < 16,
IOAPIC pin 16~23 can not be used.



> 
> Take a look at http://www.microsoft.com/whdc/archive/acpi-mp.mspx. It
> seems cleaner to use "bimodal link nodes" (using the parlance from URL
> above) instead of "bimodal _PRT" as your present GSI patch is using.
Bimodal _PRT is a great idea, I never thought of it before, thanks.

While in PIIX platform there are only 4 PCI link entries, how can we
introduce more? Where to put these added entries?
still in ISA bridge configure space.

Another concern is, can this link use irq-pin > 15?
In the example ASL code in the web page you provided, they use irq-pin
<=15


- Anthony




> 
> My current inclination is:
> 
> - Move the PCI interrupt link device code to a method in a separate
>   file (with arguments such as _UID, IRQ list, etc).
> - Create separate PCI interrupt link devices for each PCI pin of each
>   slot (see the example table at end of URL).
> - Assign all available IRQ's covered by the single IOAPIC (0-24) in
>   the interrupt list for these interrupt link devices.
> 
> I'll try Anthony's patch with Windows.
--
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

2008-06-12 Thread Jerone Young 
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

2008-06-12 Thread Jerone Young 
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

2008-06-12 Thread Jerone Young 
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

2008-06-12 Thread Xu, Anthony 
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

2008-06-12 Thread Xu, Anthony 
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

2.6.26-rc5 panic

2008-06-12 Thread Bernd Schubert 
Hello,

2.6.26-rc5 + git://git.kernel.org/pub/scm/linux/kernel/git/avi/kvm.git 
always freezes on booting with -smp 2 (kvm-69 on amd). So I re-compiled with 
almost 
all debug options enabled, the oops below is even without the -smp option

Starting Avahi mDNS/DNS-SD Daemon: avahi-daemon[   26.871095] warning: 
`avahi-daemon' 
uses 32-bit capabilities (legacy support in use)
[   26.924416] BUG: unable to handle kernel paging request at 810011a8c7f0
[   26.928205] IP: [] __memset+0x32/0xc0
[   26.928205] PGD 8063 PUD 9063 PMD 11803163 PTE 800011a8c160
[   26.928205] Oops: 0002 [1] SMP DEBUG_PAGEALLOC
[   26.928205] CPU 0
[   26.928205] Modules linked in: rtc psmouse i2c_piix4 i2c_core
[   26.928205] Pid: 2388, comm: 25avahi-daemon Not tainted 2.6.26-rc5-debug #21
[   26.928205] RIP: 0010:[]  [] 
__memset+0x32/0xc0
[   26.928205] RSP: 0018:807cfc18  EFLAGS: 00010212
[   26.928205] RAX: 5a5a5a5a5a5a5a5a RBX: 0800 RCX: 001f
[   26.928205] RDX:  RSI: 005a RDI: 810011a8c7f0
[   26.928205] RBP: 807cfc30 R08: 807cfbe0 R09: 
[   26.928205] R10: 810011a8c7f0 R11: 0800 R12: 810011a8c7f0
[   26.928205] R13: 810011a8c000 R14: 8029b4e3 R15: 0246
[   26.928205] FS:  7fe9230e36d0() GS:806c2000() 
knlGS:
[   26.928205] CS:  0010 DS:  ES:  CR0: 8005003b
[   26.928205] CR2: 810011a8c7f0 CR3: 115f6000 CR4: 06e0
[   26.928205] DR0:  DR1:  DR2: 
[   26.928205] DR3:  DR6: 0ff0 DR7: 0400
[   26.928205] Process 25avahi-daemon (pid: 2388, threadinfo 810011606000, 
task 8100117c89c0)
[   26.928205] Stack:  8029abe3 0001 8100124133c0 
807cfc70
[   26.928205]  8029ac76 0020  
810011a8c000
[   26.928205]  8100124133c0 0020  
807cfcb0
[   26.928205] Call Trace:
[   26.928205][] ? poison_obj+0x27/0x32
[   26.928205]  [] cache_alloc_debugcheck_after+0x88/0x1d7
[   26.928205]  [] kmem_cache_alloc_node+0x197/0x1c5
[   26.928205]  [] ? __kmalloc_node_track_caller+0x24/0x29
[   26.928205]  [] __kmalloc_node_track_caller+0x24/0x29
[   26.928205]  [] __alloc_skb+0x6f/0x138
[   26.928205]  [] igmpv3_newpack+0x3d/0x1c1
[   26.928205]  [] ? mark_lock+0x8b/0x430
[   26.928205]  [] ? __lock_acquire+0xcdb/0xcfc
[   26.928205]  [] add_grhead+0x2d/0x85
[   26.928205]  [] add_grec+0x351/0x388
[   26.928205]  [] igmp_ifc_timer_expire+0x1b1/0x21d
[   26.928205]  [] ? igmp_ifc_timer_expire+0x0/0x21d
[   26.928205]  [] run_timer_softirq+0x16f/0x1e9
[   26.928205]  [] __do_softirq+0x77/0xff
[   26.928205]  [] call_softirq+0x1c/0x28
[   26.928205]  [] do_softirq+0x4d/0xb0
[   26.928205]  [] irq_exit+0x4e/0x8f
[   26.928205]  [] smp_apic_timer_interrupt+0x8d/0xa6
[   26.928205]  [] apic_timer_interrupt+0x77/0x80
[   26.928205][] ? page_dup_rmap+0x1d/0x24
[   26.928205]  [] ? kvm_mmu_op+0x2b/0x3e
[   26.928205]  [] ? kvm_mmu_op+0x1e/0x3e
[   26.928205]  [] ? mmu_queue_flush+0x1b/0x29
[   26.928205]  [] ? kvm_deferred_mmu_op+0x57/0x7a
[   26.928205]  [] ? kvm_mmu_write+0x2e/0x35
[   26.928205]  [] ? kvm_set_pte_at+0x20/0x25
[   26.928205]  [] ? page_dup_rmap+0x1d/0x24
[   26.928205]  [] ? copy_page_range+0x715/0x86b
[   26.928205]  [] ? dup_mm+0x2af/0x3a6
[   26.928205]  [] ? copy_process+0xa7a/0x11b5
[   26.928205]  [] ? sigprocmask+0xc5/0xd1
[   26.928205]  [] ? do_fork+0xe8/0x247
[   26.928205]  [] ? trace_hardirqs_on+0xff/0x12a
[   26.928205]  [] ? _spin_unlock_irq+0x2b/0x37
[   26.928205]  [] ? trace_hardirqs_on_thunk+0x35/0x3a
[   26.928205]  [] ? system_call_after_swapgs+0x8a/0x8f
[   26.928205]  [] ? sys_clone+0x23/0x25
[   26.928205]  [] ? ptregscall_common+0x67/0xb0
[   26.928205]
[   26.928205]
[   26.928205] Code: 0f b6 ce 48 b8 01 01 01 01 01 01 01 01 48 f7 e1 41 89 f9 
41 83 e1 07 75 7e 44 89 d9 c1 e9 06 74 38 0f 1f 84 00 00 00 00 00 ff c9 <48> 89 
07 48 89 47 08 48 89 47 10 48 89 47 18 48 89 47 20 48 89
[   26.928205] RIP  [] __memset+0x32/0xc0
[   26.928205]  RSP 
[   26.928205] CR2: 810011a8c7f0
[   26.928205] ---[ end trace 5a12a8ccf58639a0 ]---
[   26.928205] Kernel panic - not syncing: Aiee, killing interrupt handler!


--
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

2008-06-12 Thread Xu, Anthony 
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  ->  (slot&7)+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,

[ kvm-Bugs-1935481 ] unhandled vm exit: 0x80000021 vcpu_id 0

2008-06-12 Thread SourceForge.net 
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=detail&atid=893831&aid=1935481&group_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=detail&atid=893831&aid=1935481&group_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

2008-06-12 Thread Avi Kivity 

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  ->  (slot&7)+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

Re: [RFC] kvm-s390: userspace snapshot

2008-06-12 Thread Oliver Paukstadt 
On Thu, 2008-06-12 at 16:14 +0200, Christian Borntraeger wrote:
> Am Donnerstag, 12. Juni 2008 schrieb Oliver Paukstadt:
> > 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.
> 
Thanks, looks like my new toy is running ;-)
Great job!

VM00 Name:KVMguest
VM00 Control Program: KVM/Linux   
VM00 Adjustment:  1000
VM00 CPUs Total:  1
VM00 CPUs Configured: 1
VM00 CPUs Standby:0
VM00 CPUs Reserved:   0

VM01 Name:KVM01   
VM01 Control Program: z/VM5.3.0   
VM01 Adjustment:  285
VM01 CPUs Total:  4
VM01 CPUs Configured: 4
VM01 CPUs Standby:0
VM01 CPUs Reserved:   0


--
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

2008-06-12 Thread Xu, Anthony 
Avi Kivity wrote:
> 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  ->  (slot&7)+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.
I think what you described is correct.


> 
> The _PIC method should disable the link interrupts if ioapic mode is
> disabled.
Typo!  If ioapic mode is enabled.

>From x86 BIOS, OS disable link interrupt through link device _DIS
mothod.


> 
> This removes the need for communication between the bios and qemu.
Agree

> 
>> 
>> +/* 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'll try this way.

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

KVM Test result, kernel c1b11eb.., userspace 8841cf1..

2008-06-12 Thread Yunfeng Zhao 

Hi All,

This is today's KVM test result against kvm.git 
c1b11ebee6bda13878562b894ee811141dd06198 and kvm-userspace.git 
8841cf174d3d13982c40e91800ef44e25756221e.
Nightly failed cases are old issues: Save/restore and live migration 
still failed, reboot guest will meet guest crash. There's no new issue.


Seven Old Issues:

1. 32bits Rhel5/FC6 guest may fail to reboot after installation
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1991647&group_id=180599 


2.  vista auto-unattended installation failed on kvm guests
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1991653&group_id=180599 


3. Guests crash while rebooting
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1976075&group_id=180599 


4. Fail to save restore and live migrate
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1976075&group_id=180599 


5. netperf  causes linux guest with virtnet kernel panic
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1972449&group_id=180599 


6.  XP crashes while rebooting
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1959452&group_id=180599 


7. failure to migrate guests with more than 4GB of RAM
https://sourceforge.net/tracker/index.php?func=detail&aid=1971512&group_id=180599&atid=893831 





Test environment
 
PlatformWoodcrest

CPU 4
Memory size 8G'

Details

IA32-pae: 
1. boot guest with 256M memory   PASS

2. boot guest with 1500M memory PASS
3. boot 4 same guest in parallel PASS
4. boot two windows xp guestPASS
5. boot linux and windows guest in parallel  PASS
6. save/restore 32-bit HVM guests  FAIL
7. save/restore 32-bit HVM guests with 4 vcpus   FAIL
8. live migration 32-bit HVM guests FAIL
9. live migration 32-bit HVM guests with 4 vcpus  FAIL
10. boot base kernel linux  PASS
11. kernel build on SMP linux guestPASS
12. LTP on linux guest   
PASS

13. boot Windows 2000 without ACPI  PASS
14. boot Windows 2000 with ACPI enabled  PASS
15. boot Windows 2003 with ACPI enabled   PASS
16. boot Windows xp with ACPI enabled  PASS
17. boot Windows vista with ACPI enabled   PASS
18. boot SMP Windows 2000 with ACPI enabled  PASS
19. boot SMP Windows 2003 with ACPI enabled  PASS
20. boot SMP Windows xp with ACPI enabled  PASS
21. boot SMP Windows 2008 with ACPI enabled   PASS


IA32e: 
1. boot 32-bit guest with 256M memory   PASS

2. boot 64-bit guest with 256M memory   PASS
3. boot 32-bit guest with 1500M memory PASS
4. boot 64-bit guest with 1500M memory PASS
5. boot 4G pae 
guest PASS
6. boot 4G 64-bit 
guest  PASS
7. boot four 32-bit guest in 
parallel  PASS
8. boot four 64-bit guest in 
parallel  PASS

9. boot two 32-bit windows xp in parallel  PASS
10. boot 32-bit linux and 32 bit windows guest in parallel   PASS
11. boot four 32-bit different guest in para 
PASS
12. save/restore 32-bit linux guests 
FAIL
13. save/restore 64-bit linux guests 
FAIL

14. save/restore 64-bit linux guests with 4 vcpus   FAIL
15. save/restore 32-bit linux guests with 4 vcpus   FAIL
16. live migration 64bit linux 
guests FAIL
17. live migration 32bit linux 
guests FAIL

18. live migration 64bit linux guests with 4 vcpus   FAIL
19. live migration 32bit linux guests with 4 vcpus   FAIL
20. boot 32-bit 
x-server   PASS 
21. kernel build in 32-bit linux guest OS  PASS

22. kernel build in 64-bit linux guest OS  PASS
23. LTP on 32-bit linux guest OSPASS
24. LTP on 64-bit linux guest OS
PASS

25. boot 64-bit guests with ACPI enabled

Re: [ kvm-Bugs-1985977 ] Guests crash while rebooting

2008-06-12 Thread Yunfeng Zhao 



Date: 2008-06-12 16:26

Message:
Logged In: YES 
user_id=539971

Originator: NO

Okay, I reverted the patch.
  

Avi,

The issue still exists on our nightly testing machine even after 
reverted the pmode transition patch.

I might make a mistake in the testing for your patch.
I am sorry about that.

thanks
Yunfeng


--

Comment By: yunfeng (yunfeng)
Date: 2008-06-11 09:42

Message:
Logged In: YES 
user_id=1283543

Originator: YES

This patch can fix this issue.
After reverted pmode transaition rebooting works again.


--

Comment By: Avi Kivity (avik)
Date: 2008-06-09 19:10

Message:
Logged In: YES 
user_id=539971

Originator: NO

Please try the attached patch (apply to kernel tree)
File Added: revert-pmode-transition.patch

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1985977&group_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

2008-06-12 Thread Xu, Anthony 
Hi Avi and all

This is the revised one,

All PCI devices send interrupt to both PIC and IOAPIC,  
a). When PIC is enabled and IOAPIC is disabled,  all redirect entries in
IOAPIC are masked.
B) When PIC is disabled and IPAPIC is enabled, link entry bit7 is set,
means this link entry is disable.
Guest OS need to guarantee PIC and IOAPIC are not enabled in the same
time. Otherwise cause many suspicious interrupt to guest.

Test by running guest linux in kvm/ia32 and kvm/ia64.


Thanks,
Anthony



diff --git a/bios/acpi-dsdt.dsl b/bios/acpi-dsdt.dsl
index 21fc76a..e12fd66 100755
--- a/bios/acpi-dsdt.dsl
+++ b/bios/acpi-dsdt.dsl
@@ -201,14 +201,28 @@ DefinitionBlock (
 }
 }
 
+Name (PICD, 0)
 
-/* PCI Bus definition */
+Method(_PIC, 1)
+{
+Store(Arg0, PICD)
+}
+
+/*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 +421,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, 18},
+
+// PCI Slot 11
+Package() {0x000b, 0, 0, 19},
+Package() {0x000b, 1, 0, 19},
+Package() {0x000b, 2, 0, 19},
+Package() {0x000b, 3, 0, 19},
+
+// PCI Slot 12
+Package() {0x000c, 0, 0, 20},
+Package() {0x000c, 1, 0, 20},
+Package() {0x000c, 2, 0, 20},
+Package() {0x000c, 3, 0, 20},
+
+// PCI Slot 13
+Package() {0x000d, 0, 0, 21},
+Package() {0x000d, 1, 0, 21},
+Package() {0x000d, 2, 0, 21},
+Package() {0x000d, 3, 0, 21},
+
+// PCI Slot 14
+Package() {0x000e,