Farkas Levente wrote:
> david ahern wrote:
>
>> Can you post the full qemu command that gets launched in each case?
>>
>
> this is the current running one, the only difference when smp set is -smp 4:
>
> root 3270 10.3 25.8 2213976 2111868 ? Sl 16:20 30:35
> /usr/bin/qemu-kvm -M
Farkas Levente wrote:
> Avi Kivity wrote:
>
>> Farkas Levente wrote:
>>
>>> first of all fully update your centos (a bit newer kernel), then i use
>>> these packages:
>>> http://www.lfarkas.org/linux/packages/centos/5/x86_64/
>>> use libvirtd and virt-manager too and start the guests from t
Zhang, Xiantao wrote:
> Hi Avi,
>smp_call_function_mask is introduced in latest commits, but not
> defined in UP configuration. So, it will run into compile fail when
> kernel is configured without smp support. Please check and do the fix
> :)
>
I see it in my include/linux/smp.h:
>
> #d
david ahern wrote:
> With kvm-52 my 32-bit host running RHEL5.1 can start an RHEL 5 SMP guest only
> once. Second and subsequent attempts hang. Removing kvm and kvm_intel modules
> have no affect; I need to reboot the host to get an SMP guest to start. My
> similarly configured 64-bit host does
Ryan Harper wrote:
> I can't seem to get to the nightly snapshot url:
>
> http://people.qumranet.com:/avi/snapshots/
>
>
>
It's http://people.qumranet.com/avi/snapshots/
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
--
Avi Kivity wrote:
> Farkas Levente wrote:
>> david ahern wrote:
>>
>>> Can you post the full qemu command that gets launched in each case?
>>>
>> this is the current running one, the only difference when smp set is -smp 4:
>>
>> root 3270 10.3 25.8 2213976 2111868 ? Sl 16:20 30:
Farkas Levente wrote:
> Avi Kivity wrote:
>
>> Farkas Levente wrote:
>>
>>> david ahern wrote:
>>>
>>>
Can you post the full qemu command that gets launched in each case?
>>> this is the current running one, the only difference when smp set is -smp 4:
Avi Kivity wrote:
> Zhang, Xiantao wrote:
>> Hi Avi,
>>smp_call_function_mask is introduced in latest commits, but not
>> defined in UP configuration. So, it will run into compile fail when
>> kernel is configured without smp support. Please check and do the
>> fix :)
>>
>
> I see it in my
Hi Levente,
Le mardi 13 novembre 2007 à 10:07 +0100, Farkas Levente a écrit :
> Avi Kivity wrote:
> > Farkas Levente wrote:
> >> Avi Kivity wrote:
> >>
> >>> Farkas Levente wrote:
> >>>
> first of all fully update your centos (a bit newer kernel), then i use
> these packages:
> >
Avi Kivity wrote:
> Farkas Levente wrote:
>> Avi Kivity wrote:
>>
>>> Farkas Levente wrote:
>>>
first of all fully update your centos (a bit newer kernel), then i use
these packages:
http://www.lfarkas.org/linux/packages/centos/5/x86_64/
use libvirtd and virt-manager too
Farkas Levente wrote:
> Avi Kivity wrote:
>
>> Farkas Levente wrote:
>>
>>> Avi Kivity wrote:
>>>
>>>
Farkas Levente wrote:
> first of all fully update your centos (a bit newer kernel), then i use
> these packages:
> http://www.lfarkas.org/
Bugs item #1830975, was opened at 2007-11-13 12:04
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=1830975&group_id=180599
Please note that this message will contain a full copy
Avi Kivity wrote:
>> anyway it'd be useful to if i can see which version of the userspace
>> running ie. give a short message into the stslog on the host about the
>> userspace version may be even a warning in case of the kmod and the
>> userspace version are different, but currently that's all:
>>
david ahern wrote:
> (Changed the subject to correspond with email.)
>
> I am having the same problem on the 64-bit host running RHEL5.1 as well, it
> just takes more reboots. Same symptoms as I mentioned for the 32-bit host.
> kernel side stack traces for each qemu thread for one of the lockups
Laurent Vivier wrote:
> Hi Levente,
>
> Le mardi 13 novembre 2007 à 10:07 +0100, Farkas Levente a écrit :
>> Avi Kivity wrote:
>>> Farkas Levente wrote:
Avi Kivity wrote:
> Farkas Levente wrote:
>
>> first of all fully update your centos (a bit newer kernel), then i u
Avi:
Maybe I am wrong, but it looks like we didn't disable
interrupt_window_open & GUEST_INTERRUPTIBILITY_INFO if the emulation
path does sti or mov from SS emulation.
Too paranoea?
Eddie
-
This SF.net email is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Avi Kivity escreveu:
> Glauber de Oliveira Costa wrote:
>> This is the host part of kvm clocksource implementation. As it does
>> not include clockevents, it is a fairly simple implementation. We
>> only have to register a per-vcpu area, and start writ
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andi Kleen escreveu:
> On Fri, Nov 09, 2007 at 04:43:05PM -0200, Glauber de Oliveira Costa wrote:
>> This patch makes vsmp a paravirt client. It now uses the whole
>> infrastructure provided by pvops. When we detect we're running
>> a vsmp box, we chan
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Amit Shah escreveu:
> On Saturday 10 November 2007 00:12:41 Glauber de Oliveira Costa wrote:
>> Hey folks,
>>
>> Here's a new spin of the pvops64 patch series.
>> We didn't get that many comments from the last time,
>> so it should be probably almost r
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dong, Eddie escreveu:
>> +static void kvm_write_guest_time(struct kvm_vcpu *vcpu) +{
>> +struct timespec ts;
>> +int r;
>> +
>> +if (!vcpu->clock_gpa)
>> +return;
>> +
>> +/* Updates version to the next odd number, indicatin
Glauber de Oliveira Costa wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Dong, Eddie escreveu:
>
>>> +static void kvm_write_guest_time(struct kvm_vcpu *vcpu) +{
>>> + struct timespec ts;
>>> + int r;
>>> +
>>> + if (!vcpu->clock_gpa)
>>> + return;
>>> +
>>> + /* U
> The vsmp_64.c file is now compiled unconditionally, according to which
> me and kiran agreed to. The detection code is always run, but will only
> trigger when a suitable box is found. Accordingly, the paravirt structs
> are only touched when PARAVIRT is on. Otherwise, we don't even have the
> s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andi Kleen escreveu:
>> The vsmp_64.c file is now compiled unconditionally, according to which
>> me and kiran agreed to. The detection code is always run, but will only
>> trigger when a suitable box is found. Accordingly, the paravirt structs
>> are
> If vsmp is selected, PARAVIRT will be too, and the interrupt code will
> be patched.
> the vsmp option triggers a select statement.
>
> the ifdef only exists because, as I said, the code itself will be always
> compiled in, to avoid an ifdef in setup_64.c. So it's just a taking it
> from here,
Farkas Levente wrote:
> anyway how should i've test noapic? qemu command line -noapic or guest
> kernel param noapic or both?
>
Add 'noapic' to guest kernel boot options. I've been adding it for a while to
workaround a networking issue (see kvm-Bugs-1802082).
david
---
Glauber de Oliveira Costa wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Avi Kivity escreveu:
>
>> Glauber de Oliveira Costa wrote:
>>
>>> This is the host part of kvm clocksource implementation. As it does
>>> not include clockevents, it is a fairly simple implementation. We
Glauber de Oliveira Costa wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Dong, Eddie escreveu:
>
>>> +static void kvm_write_guest_time(struct kvm_vcpu *vcpu) +{
>>> + struct timespec ts;
>>> + int r;
>>> +
>>> + if (!vcpu->clock_gpa)
>>> + return;
>>> +
>>> + /* U
Dong, Eddie wrote:
> Avi:
> Maybe I am wrong, but it looks like we didn't disable
> interrupt_window_open & GUEST_INTERRUPTIBILITY_INFO if the emulation
> path does sti or mov from SS emulation.
> Too paranoea?
>
Well, we should. I doubt it would affect anything, but patches to
im
Avi Kivity wrote:
> Glauber de Oliveira Costa wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Dong, Eddie escreveu:
>>
+static void kvm_write_guest_time(struct kvm_vcpu *vcpu) +{
+ struct timespec ts; + int r;
+
+ if (!vcpu->clock_gpa)
+ retu
* Avi Kivity <[EMAIL PROTECTED]> [2007-11-13 02:30]:
> Ryan Harper wrote:
> > I can't seem to get to the nightly snapshot url:
> >
> > http://people.qumranet.com:/avi/snapshots/
> >
> >
> >
>
> It's http://people.qumranet.com/avi/snapshots/
Ah, ok. The last place I saw the URL was from yo
I let the host stay up for 90 minutes before loading kvm and starting a VM. On
the first reboot it hangs at 'Starting udev'.
I added 'noapic' to the kernel boot options, and it boots fine. (Turns out I
only added that to grub.conf in images that run a particular ap for which I am
running perfor
Dong, Eddie wrote:
>>>
>>> After thinking for a little while, you are theoretically right.
>>> In the current state, we could even be preempted between all
>>> operations ;-) Maybe after avi's suggestion of moving the call to it
>>> it will end up in a preempt safe region, but anyway, it's safer to
david ahern wrote:
> I let the host stay up for 90 minutes before loading kvm and starting a VM.
> On the first reboot it hangs at 'Starting udev'.
>
>
First reboot or first boot?
I thought the problem was cold starting a VM.
> I added 'noapic' to the kernel boot options, and it boots fine.
First boot has been working fine since your patch this past weekend. It's been
subsequent boots that hang.
I added -no-kvm-irqchip to qemu command line and did not add the noapic boot
option: it's hung at 'Starting udev' again but this time it's not consuming
CPU. kernel stack traces for qemu t
david ahern wrote:
> First boot has been working fine since your patch this past weekend. It's
> been subsequent boots that hang.
>
> I added -no-kvm-irqchip to qemu command line and did not add the noapic boot
> option: it's hung at 'Starting udev' again but this time it's not consuming
> CPU.
I removed the kvm/kvm-intel modules. qemu command line was:
/usr/local/bin/qemu-system-x86_64 -boot c -localtime -hda
/opt/kvm/images/rhel5.img -m 1536 -smp 4 -net
nic,macaddr=00:0c:29:10:10:e8,model=rtl8139 -net
tap,ifname=tap0,script=/bin/true -monitor stdio -no-kvm -name
bldr-ccm89.cisco.co
david ahern wrote:
> I removed the kvm/kvm-intel modules. qemu command line was:
>
> /usr/local/bin/qemu-system-x86_64 -boot c -localtime -hda
> /opt/kvm/images/rhel5.img -m 1536 -smp 4 -net
> nic,macaddr=00:0c:29:10:10:e8,model=rtl8139 -net
> tap,ifname=tap0,script=/bin/true -monitor stdio -no-
Glauber de Oliveira Costa wrote:
> the ifdef only exists because, as I said, the code itself will be always
> compiled in, to avoid an ifdef in setup_64.c. So it's just a taking it
> from here, putting it there issue. Kiran seem to prefer this way, but I
> don't really have a preference.
It would
On Tue, Nov 13, 2007 at 09:36:42AM -0200, Glauber de Oliveira Costa wrote:
>-BEGIN PGP SIGNED MESSAGE-
>
>> And the "EM64T based comment" is wrong because there are AMD based
>> vSMPs too.
>Just got it as-is from the old Kconfig. Do you think it should be fixed
>as well?
Yep.
Thanks,
Kir
On Tue, Nov 13, 2007 at 02:09:41PM +0100, Andi Kleen wrote:
>
>> If vsmp is selected, PARAVIRT will be too, and the interrupt code will
>> be patched.
>> the vsmp option triggers a select statement.
>>
>> the ifdef only exists because, as I said, the code itself will be always
>> compiled in, to a
Hi,
I've been experimenting with creating IO threads for the PV device
drivers. Unfortunately, my experiments haven't gotten very far as QEMU
tends to hang up a bit into booting the guest whenever I spawn a thread
that does any sort of read/write on a file descriptor. My suspicion is
that it
Amit Shah wrote:
> Glauber, are you planning on consolidating the dma_ops structure for 32- and
> 64-bit? 32-bit doesn't currently have a dma_mapping_ops structure, which
> makes paravirtualizing DMA access difficult on 32-bit.
I think it's a good idea. While I haven't worked out the details y
Anthony Liguori wrote:
> Hi,
>
> I've been experimenting with creating IO threads for the PV device
> drivers. Unfortunately, my experiments haven't gotten very far as QEMU
> tends to hang up a bit into booting the guest whenever I spawn a thread
> that does any sort of read/write on a file des
On Nov 13, 2007 11:42 PM, Dor Laor <[EMAIL PROTECTED]> wrote:
> Anthony Liguori wrote:
> > I've been experimenting with creating IO threads for the PV device
> > drivers. Unfortunately, my experiments haven't gotten very far as QEMU
> > tends to hang up a bit into booting the guest whenever I spaw
>>
>> +kvm_get_msr(vcpu, MSR_IA32_TIME_STAMP_COUNTER,
>> + &vcpu->hv_clock.last_tsc);
>> +
>> +ktime_get_ts(&ts);
>> +vcpu->hv_clock.now_ns = ts.tv_nsec + (NSEC_PER_SEC *
>> (u64)ts.tv_sec); + vcpu->hv_clock.wc_sec = get_seconds();
>>
>> I am even thinking we ha
Hi Avi,
I rebased this series of patches to further split kvm_main.c. In
this version, I mainly improved the 3th patch, and make
kvm_arch_vcpu_create to hold more logics according to community's
response. Thanks Hollis and Carsteno for Acks. :)
Thanks
Xiantao
From: Zhang Xiantao <[EMAIL PROTECTED]>
Move some includes to x86.c from kvm_main.c, since the related functions
have been moved to x86.c
Signed-off-by: Zhang Xiantao <[EMAIL PROTECTED]>
---
drivers/kvm/kvm_main.c |2 --
drivers/kvm/x86.c |2 ++
2 files changed, 2 insertions(+), 2 del
From: Zhang Xiantao <[EMAIL PROTECTED]>
Using kvm arch support to replace kvm_x86_ops, and make them
arch-independent.
Signed-off-by: Zhang Xiantao <[EMAIL PROTECTED]>
---
drivers/kvm/kvm.h | 18 +++
drivers/kvm/kvm_main.c | 78 +++---
drivers/kvm/x86.c
From: Zhang Xiantao <[EMAIL PROTECTED]>
Combine kvm_init and kvm_init_x86 into one function, and will be called
when arch register.
Signed-off-by: Zhang Xiantao <[EMAIL PROTECTED]>
---
drivers/kvm/kvm.h |4 +-
drivers/kvm/kvm_main.c | 61
+--
From: Zhang Xiantao <[EMAIL PROTECTED]>
Move-some-x86-specific-part-from-kvm_init-to-kvm_arch
Signed-off-by: Zhang Xiantao <[EMAIL PROTECTED]>
---
drivers/kvm/kvm.h |5 +++--
drivers/kvm/kvm_main.c | 26 ++
drivers/kvm/x86.c | 27 ++
From: Zhang Xiantao <[EMAIL PROTECTED]>
Move kvm_x86_ops to x86.c
Signed-off-by: Zhang Xiantao <[EMAIL PROTECTED]>
---
drivers/kvm/kvm_main.c |1 -
drivers/kvm/x86.c |2 ++
drivers/kvm/x86.h |2 ++
3 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/kvm/kvm
Bugs item #1831586, was opened at 2007-11-14 14: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=1831586&group_id=180599
Please note that this message will contain a full copy
52 matches
Mail list logo
