Hi, Lucas,
On Thu, Dec 03, 2009 at 01:16:27AM -0200, Lucas Meneghel Rodrigues wrote:
> Chen, I have verified your patch, code looks good, but I am indeed a
> bit concerned about putting extra requirements on winutils.iso. How
> hard it is to get git working under windows? I did some quick research
Patch: Major control file cleanup
URL: http://patchwork.test.kernel.org/patch/1464/
Comments: Will split this work in 2 stages:
• Cleanups and splitting kvm_tests.cfg in a "base config" + "test
definitions"
• Move "test definitions" to control file then having an utility to
parse all config and gen
Chen, I have verified your patch, code looks good, but I am indeed a
bit concerned about putting extra requirements on winutils.iso. How
hard it is to get git working under windows? I did some quick research
and seems that we have a portable version of git that could be kept on
winutils.iso for tha
On 29 Nov 2009, n...@esperi.org.uk spake thusly:
> One qemu-kvm-specific bug, definitely non-kernel-related, is this crash,
> frequently encountered when hotadding more than one USB device (to an XP
> guest, as it happens, but that doesn't look relevant here):
I also see a crash when using -usbde
Ryan Harper wrote:
> * Ryan Harper [2009-12-02 13:11]:
>> * Jan Kiszka [2009-12-02 12:45]:
> So far, so consistent. Could you try kvm-kmod-2.6.32-rc7 on top of that?
>
Sure, can you remind me of the kvm-kmod build magic for building that
branch?
>>> If you want to build fro
* Ryan Harper [2009-12-02 13:11]:
> * Jan Kiszka [2009-12-02 12:45]:
> > >>>
> > >> So far, so consistent. Could you try kvm-kmod-2.6.32-rc7 on top of that?
> > >>
> > >
> > > Sure, can you remind me of the kvm-kmod build magic for building that
> > > branch?
> > >
> >
> > If you want to build
* Jan Kiszka [2009-12-02 12:45]:
> >>>
> >> So far, so consistent. Could you try kvm-kmod-2.6.32-rc7 on top of that?
> >>
> >
> > Sure, can you remind me of the kvm-kmod build magic for building that
> > branch?
> >
>
> If you want to build from git, check Wolfgang's nice README. But it
> might
Ryan Harper wrote:
> * Jan Kiszka [2009-12-02 12:18]:
>> Ryan Harper wrote:
>>> * Jan Kiszka [2009-12-02 12:07]:
Ryan Harper wrote:
> * Jan Kiszka [2009-12-02 09:28]:
>> Hi,
>>
>> I'm facing stalled x86-64 guests after live migration when using kvm
>> (share disk images)
* Jan Kiszka [2009-12-02 12:18]:
> Ryan Harper wrote:
> > * Jan Kiszka [2009-12-02 12:07]:
> >> Ryan Harper wrote:
> >>> * Jan Kiszka [2009-12-02 09:28]:
> Hi,
>
> I'm facing stalled x86-64 guests after live migration when using kvm
> (share disk images). This does not happen
Jan Kiszka wrote:
> Hi,
>
> I'm facing stalled x86-64 guests after live migration when using kvm
> (share disk images). This does not happen with x86-32 guests or when
> disabling kvm. Both qemu and qemu-kvm git heads are affected (recent
> vmstate fixes applied). Running I/O load during the migra
Ryan Harper wrote:
> * Jan Kiszka [2009-12-02 12:07]:
>> Ryan Harper wrote:
>>> * Jan Kiszka [2009-12-02 09:28]:
Hi,
I'm facing stalled x86-64 guests after live migration when using kvm
(share disk images). This does not happen with x86-32 guests or when
disabling kvm. Bo
* Jan Kiszka [2009-12-02 12:07]:
> Ryan Harper wrote:
> > * Jan Kiszka [2009-12-02 09:28]:
> >> Hi,
> >>
> >> I'm facing stalled x86-64 guests after live migration when using kvm
> >> (share disk images). This does not happen with x86-32 guests or when
> >> disabling kvm. Both qemu and qemu-kvm g
Ryan Harper wrote:
> * Jan Kiszka [2009-12-02 09:28]:
>> Hi,
>>
>> I'm facing stalled x86-64 guests after live migration when using kvm
>> (share disk images). This does not happen with x86-32 guests or when
>> disabling kvm. Both qemu and qemu-kvm git heads are affected (recent
>> vmstate fixes a
On Wed, Dec 2, 2009 at 9:10 AM, Lucas Meneghel Rodrigues
wrote:
> On Wed, 2009-12-02 at 08:59 +0530, sudhir kumar wrote:
>> On Wed, Dec 2, 2009 at 7:51 AM, Yolkfull Chow wrote:
>> >
>> > Looks good for me. Thanks Lucas for improving this test.
>> >
>> > Sudhir, what do you think about this? :)
>
Bugs item #2907597, was opened at 2009-12-02 16:57
Message generated for change (Tracker Item Submitted) made by mcsoccer
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2907597&group_id=180599
Please note that this message will contain a full copy of the
* Jan Kiszka [2009-12-02 09:28]:
> Hi,
>
> I'm facing stalled x86-64 guests after live migration when using kvm
> (share disk images). This does not happen with x86-32 guests or when
> disabling kvm. Both qemu and qemu-kvm git heads are affected (recent
> vmstate fixes applied). Running I/O load
On Tue, Dec 01, 2009 at 03:36:36PM +0100, Chris Lalancette wrote:
> Call it kvm_apic_in_virtual_wire_mode, which is more
> correct. Also change it to not only operate properly
> on the boot CPU, but on any CPU.
>
Currently it is assumed that if kvm_cpu_has_interrupt() returns true
kvm_cpu_get_int
On Tue, Dec 01, 2009 at 03:36:41PM +0100, Chris Lalancette wrote:
> Make sure that we kick the appropriate vcpu when delivering
> an interrupt. This makes sure that we wake any idle cpus
> to cause a "vcpu_run" and an interrupt injection to occur.
>
> Signed-off-by: Chris Lalancette
> ---
> vir
Hi,
I'm facing stalled x86-64 guests after live migration when using kvm
(share disk images). This does not happen with x86-32 guests or when
disabling kvm. Both qemu and qemu-kvm git heads are affected (recent
vmstate fixes applied). Running I/O load during the migration (e.g. a
simple "ls -R /")
On 12/01/2009 04:36 PM, Chris Lalancette wrote:
In order to be able to call kvm_set_irq from an interrupt
context, the IOAPIC lock can't be a (possibly sleeping) mutex.
Convert it to a spinlock.
The ioapic can call various notifiers (ack_notifiers, mask_notifiers).
Have you validated that
On 12/01/2009 04:36 PM, Chris Lalancette wrote:
Call it kvm_apic_in_virtual_wire_mode, which is more
correct. Also change it to not only operate properly
on the boot CPU, but on any CPU.
I'm a little worried about the latter change. It effectively modifies
the platform from having the PI
On 12/02/2009 04:16 PM, Avi Kivity wrote:
Unfortunately, this does sort of put a damper on what's going on later
in the series. If the i8254 doesn't belong to the BSP (which it really
shouldn't), then I don't know which vcpu to raise the bit on. Maybe I
can do it in the kvm_irq_delivery_to_ap
On 12/02/2009 02:59 PM, Chris Lalancette wrote:
On 12/01/2009 08:04 PM, Jan Kiszka wrote:
Chris Lalancette wrote:
KVM_REQ_PENDING_TIMER is set and cleared in a couple of places,
but it never seems to be actually checked. Remove it.
I would suggest to study the introducing c
On 12/02/2009 03:33 PM, Michael S. Tsirkin wrote:
This for qemu.git
Please set the To: header correctly to avoid confusion.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord..
On Wed, Dec 02, 2009 at 02:52:33PM +0200, Avi Kivity wrote:
> On 11/30/2009 09:02 PM, Michael S. Tsirkin wrote:
>> PCI memory should be disabled at reset, otherwise
>> we might claim transactions at address 0.
>> I/O should also be disabled, although for cirrus
>> it is harmless to enable it as we
On 11/30/2009 04:17 PM, Michael S. Tsirkin wrote:
On Thu, Oct 08, 2009 at 05:52:56PM +0200, Michael S. Tsirkin wrote:
VGA adapters need to claim memory and i/o
transactions even if they do not have any
i/o or memory bars. E.g. PCI spec, page 297,
gives an example of such a device:
Progr
On 11/29/2009 04:23 PM, Avi Kivity wrote:
On 11/29/2009 03:48 PM, Nix wrote:
On 29 Nov 2009, Avi Kivity uttered the following:
66 0f 7f 07 movdqa %xmm0,(%rdi)
which we don't emulate.
x86-64 glibc 2.10 memset(), perhaps? On SSE-capable platforms that does
a whole bunch of
L(SSE0Q
Ok, as discussed on this thread, following Michael's suggestion, I
increased the time needed to rule a session as unresponsive from the
default 5 seconds to 30 seconds.
http://autotest.kernel.org/changeset/3987
This ought to be enough, if it isn't, let me know Chen!
On Thu, Nov 26, 2009 at 5:57
> This is in the copy of the headers that qemu-kvm.git carries, not the
> kernel master.
Right, I missed that. Thanks
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-in
On 12/02/2009 03:09 PM, Christian Borntraeger wrote:
Am Montag 30 November 2009 13:02:08 schrieb Michael S. Tsirkin:
__user macro does not appear in exported headers
and should not be in headers qemu-kvm includes.
Signed-off-by: Michael S. Tsirkin
---
kvm/include/linux/kvm.h |2 +-
1
On 11/27/2009 01:17 PM, Elmar Haneke wrote:
My Linux box running several KVM/QEmu-proceses did stop work (until
reset). In kern.log I found this message:
[ cut here ]
Nov 27 11:16:57 winserver kernel: [15721.577859] kernel BUG at
/home/blank/debian/kernel/release/linux-2
Am Montag 30 November 2009 13:02:08 schrieb Michael S. Tsirkin:
> __user macro does not appear in exported headers
> and should not be in headers qemu-kvm includes.
>
> Signed-off-by: Michael S. Tsirkin
> ---
> kvm/include/linux/kvm.h |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
On 11/16/2009 07:05 PM, Jan Kiszka wrote:
This hunk is bogus, probably some merge left-over.
Applied, thanks.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel
On 11/17/2009 01:39 AM, Marty Kurtz wrote:
Hi all
I work in the embedded world and am evaluating potential hypervisors
and kvm looks suitable for what we want
However, I see some old references to 1:1 mapping which would allow a
guest to see a PCI device even without an IOMMU
Is this currently
On 11/30/2009 02:02 PM, Michael S. Tsirkin wrote:
__user macro does not appear in exported headers
and should not be in headers qemu-kvm includes.
Applied, thanks.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe
On 12/01/2009 05:27 PM, Kusanagi Kouichi wrote:
If DEBUG_MEMREG is defined, build fails as follows.
CCx86_64-softmmu/kvm-all.o
cc1: warnings being treated as errors
In file included from kvm-all.c:1094:
qemu-kvm.c: In function 'set_gsi':
qemu-kvm.c:127: error: too few arguments for format
On 12/01/2009 08:04 PM, Jan Kiszka wrote:
> Chris Lalancette wrote:
>> KVM_REQ_PENDING_TIMER is set and cleared in a couple of places,
>> but it never seems to be actually checked. Remove it.
>>
>
> I would suggest to study the introducing commit
> 06e05645661211b9eaadaf6344c335d2e80f0ba2. My str
On 11/30/2009 06:14 PM, Carsten Otte wrote:
This patch corrects the checking of the new address for the prefix register.
On s390, the prefix register is used to address the cpu's lowcore (address
0...8k). This check is supposed to verify that the memory is readable and
present.
copy_from_guest is
On 11/30/2009 06:04 PM, Avi Kivity wrote:
Why hasn't qemu-kvm switched to seabios?
Regressions. AFAICT all have been fixed now, and the switch is imminent.
The switch is now complete.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send t
On 11/30/2009 09:02 PM, Michael S. Tsirkin wrote:
PCI memory should be disabled at reset, otherwise
we might claim transactions at address 0.
I/O should also be disabled, although for cirrus
it is harmless to enable it as we do not
have I/O bar.
Note: bios fix needed for this patch to work
was a
On Wed, 2009-12-02 at 09:45 +0530, sudhir kumar wrote:
> >> Signed-off-by: Lucas Meneghel Rodrigues
> >
> > Yeah, I like noinstall as a default.
> Definitely good, but I will prefer a name like no_kvm_install.
We might leave this for the control file refactoring!
Thanks,
--
To unsubscribe from
update_transition_efer() masks out some efer bits when deciding whether
to switch the msr during guest entry; for example, NX is emulated using the
mmu so we don't need to disable it, and LMA/LME are handled by the hardware.
However, with shared msrs, the comparison is made against a stale value;
This fixes a problem with importing the autotest subtest.
It may be safer than importing tests. because, according to the
Python documentation, imp.find_module() searches only the given path,
regardless of what's in sys.path.
Signed-off-by: Michael Goldish
---
client/tests/kvm/kvm.py | 15
Signed-off-by: Michael Goldish
---
client/tests/kvm/tests/steps.py |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/client/tests/kvm/tests/steps.py b/client/tests/kvm/tests/steps.py
index 11b2ae1..456fb44 100644
--- a/client/tests/kvm/tests/steps.py
+++ b/client/tests/kv
- "Lucas Meneghel Rodrigues" wrote:
> The KVM test was breaking when trying to import the subtest
> 'autotest', as a naming clash was happening (client/bin/autotest
> was being imported instead of the autotest subtest), so to
> make naming clashes less likely, import test.[type] instead
> of
45 matches
Mail list logo
