No, I'm not,
changing to
/usr/local/bin/qemu-system-x86_64
fixes it, Tnx!
Avi Kivity wrote:
> Pelle wrote:
>
>> The message that this should be fixed was reason for me to test it
>> again, and it fails miserably, even on kvm-36
>> I checked with "modinfo kvm-intel" that i am in fact using kv
invlpg shouldn't fetch the "src" address, since it may not be valid,
however SVM's "solution" which neuters emulation of all group 7
instruction is horrible and breaks kvm-lite. The simplest fix is to
put a special check in for invlpg.
Also, remove the unused invlpg member of struct kvm_arch_ops.
My current view of the IO stack is the following:
-- -- --
-- -
|NET_PCI_BACK| |BLK_PCI_BACK| |9P_PCI_BACK| |NET_FRONT|
|BLK_FRONT| |9P_FRONT|
-- -- --
---
Dor Laor wrote:
> Can you try it without rtc (either use -no-rtc, I'm not sure we have
> this flag or just rm /dev/rtc before you run the vm).
Tried it (and -tdf) without effect.
> What's your host HZ configuration?
CONFIG_HZ=250
> If the above doesn't work, can you repeat the test with -no-kvm
>kvm-36 is repeatedly timing out partway through a long network transfor
>and failing to resume. Both host and guest are 64-bit. This has
happened
>with a number of prior releases as well; it does not appear to be a
>recently-introduced issue.
>
>My command line looks like the following:
>
>$ qemu-
kvm-36 is repeatedly timing out partway through a long network transfor
and failing to resume. Both host and guest are 64-bit. This has happened
with a number of prior releases as well; it does not appear to be a
recently-introduced issue.
My command line looks like the following:
$ qemu-syste
mrintegrity wrote:
> I think it's kvm-16 if that makes any sense? As you can see, it's the
> ubuntu pre packaged version:
>
> Version: 1:16-1ubuntu2
>
Yes, that's kvm-16.
--
Any sufficiently difficult bug is indistinguishable from a feature.
-
Pelle wrote:
> The message that this should be fixed was reason for me to test it
> again, and it fails miserably, even on kvm-36
> I checked with "modinfo kvm-intel" that i am in fact using kvm-36,
> processor is a core 2 duo 6300
>
> $ /usr/local/bin/qemu -hda winXP.img -hdb vdisk.img -m 256 -so
Dor Laor wrote:
>>
>> Thinking a little more about this, it isn't about handling hypercalls
>>
> in
>
>> userspace, but about handling a virtio sync() in userspace.
>>
>> So how about having a KVM_HC_WAKE_CHANNEL hypercall (similar to Xen's
>> event channel, but assymetric) that has a chann
On Tue, 2007-08-21 at 18:02 +0200, Christian Borntraeger wrote:
> Am Dienstag, 21. August 2007 schrieb Rusty Russell:
> > The only reason that we don't do it in skb_xmit_done() is because
> > kfree_skb() isn't supposed to be called from an interrupt. But there's
> > dev_kfree_skb_any() which can b
Note: This patch was committed to the qemu CVS already, but I am posting
to make sure it gets into KVM also.
The new libata-eh in the Linux kernel is throwing a fit over the QEMU
cdrom device for two reasons:
1) DRQ can be set with ERR_STAT set. This is a violation of the ATAPI
state machine.
2
On 8/29/07, Cam Macdonell <[EMAIL PROTECTED]> wrote:
> Luca wrote:
> > On 8/29/07, Cam Macdonell <[EMAIL PROTECTED]> wrote:
> >> Dor Laor wrote:
> >>> The code can now be accessed by git:
> >>> git://kvm.qumranet.com/home/dor/src/virtio/kvm (kernel) and
> >>> git://kvm.qumranet.com/home/dor/src/vir
Luca wrote:
> On 8/29/07, Cam Macdonell <[EMAIL PROTECTED]> wrote:
>> Dor Laor wrote:
>>> The code can now be accessed by git:
>>> git://kvm.qumranet.com/home/dor/src/virtio/kvm (kernel) and
>>> git://kvm.qumranet.com/home/dor/src/virtio/kvm-userspace.
>>> branch name virt-final.
>>> --Dor
>> I'm r
Laurent Vivier wrote:
> Index: kvm/drivers/kvm/kvm.h
> @@ -1860,7 +1869,7 @@ static int kvm_vcpu_ioctl_run(struct kvm
> vcpu->mmio_read_completed = 1;
> vcpu->mmio_needed = 0;
> r = emulate_instruction(vcpu, kvm_run,
> -
I think that it would be nicer to implement the p9 transport on top of
virtio instead of directly on top of PCI. I think your PCI transport
would make a pretty nice start of a PCI virtio transport though.
Regards,
Anthony Liguori
On Tue, 2007-08-28 at 13:52 -0500, Eric Van Hensbergen wrote:
> F
move emulate_ctxt to kvm_vcpu to keep emulate context when we exit from kvm
module. Call x86_decode_insn() only when needed. Modify x86_emulate_insn() to
not modify the context if it must be re-entered.
Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
Index: kvm/drivers/kvm/kvm.h
emulate_instruction() calls now x86_decode_insn() and x86_emulate_insn().
x86_emulate_insn() is x86_emulate_memop() without the decoding part.
Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
Index: kvm/drivers/kvm/kvm_main.c
===
---
move all decoding process to function x86_decode_insn().
Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
Index: kvm/drivers/kvm/x86_emulate.c
===
--- kvm.orig/drivers/kvm/x86_emulate.c 2007-08-29 18:04:53.0 +0200
+++ kvm/dr
move all x86_emulate_memop() common variables between decode and execute to a
structure decode_cache.
struct decode_cache {
u8 twobyte;
u8 b;
u8 lock_prefix;
u8 rep_prefix;
u8 op_bytes;
u8 a
Remove #ifdef functions never used
Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
Index: kvm/drivers/kvm/x86_emulate.c
===
--- kvm.orig/drivers/kvm/x86_emulate.c 2007-08-27 10:55:05.0 +0200
+++ kvm/drivers/kvm/x86_emulate.
These patches split the emulator in two parts: one to decode the instruction,
the other to execute it. The decode part is then called only when needed.
[PATCH 1/5] x86_emulate-remove_unused, some cleanup: remove unused functions
[PATCH 2/5] x86_emulate-context, move all x86_emulate_memop() common
That's also in our plans. There was no virtio support in KVM when I
started working in the transport.
Thanks,
Lucho
On 8/29/07, Anthony Liguori <[EMAIL PROTECTED]> wrote:
> I think that it would be nicer to implement the p9 transport on top of
> virtio instead of directly on top of PCI. I th
On 8/29/07, Cam Macdonell <[EMAIL PROTECTED]> wrote:
> Dor Laor wrote:
> > The code can now be accessed by git:
> > git://kvm.qumranet.com/home/dor/src/virtio/kvm (kernel) and
> > git://kvm.qumranet.com/home/dor/src/virtio/kvm-userspace.
> > branch name virt-final.
> > --Dor
>
> I'm really new to g
Dor Laor wrote:
>
> The code can now be accessed by git:
> git://kvm.qumranet.com/home/dor/src/virtio/kvm (kernel) and
> git://kvm.qumranet.com/home/dor/src/virtio/kvm-userspace.
> branch name virt-final.
> --Dor
>
Hi Dor,
I'm really new to git and don't quite grasp it's subtleties. Do I have
I think it's kvm-16 if that makes any sense? As you can see, it's the
ubuntu pre packaged version:
Version: 1:16-1ubuntu2
Alan
On Wed, 2007-08-29 at 05:19 +0300, Izik Eidus wrote:
> On Wed, 2007-08-29 at 13:51 +0200, mrintegrity wrote:
> > When starting kvm with the -std-vga option I get the fol
The message that this should be fixed was reason for me to test it
again, and it fails miserably, even on kvm-36
I checked with "modinfo kvm-intel" that i am in fact using kvm-36,
processor is a core 2 duo 6300
$ /usr/local/bin/qemu -hda winXP.img -hdb vdisk.img -m 256 -soundhw
es1370 -std-vga
On Wed, 2007-08-29 at 13:51 +0200, mrintegrity wrote:
> When starting kvm with the -std-vga option I get the following crash and
> terminal output:
>
> [EMAIL PROTECTED]:~# kvm -hda /home/variant/XPtest.img -m 450 -soundhw
> sb16 -localtime -usb -usbdevice tablet -std-vga -snapshot
> kvm: get_dirt
When starting kvm with the -std-vga option I get the following crash and
terminal output:
[EMAIL PROTECTED]:~# kvm -hda /home/variant/XPtest.img -m 450 -soundhw
sb16 -localtime -usb -usbdevice tablet -std-vga -snapshot
kvm: get_dirty_pages returned -2
SNIP
kvm: get_dirty_pages returned -
Bugs item #1783936, was opened at 2007-08-29 13:20
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=1783936&group_id=180599
Please note that this message will contain a full copy
http://www.qqywj.com
MSN: [EMAIL PROTECTED]
Email: [EMAIL PROTECTED]
skype: qqywj1
TEL: +86 15938829425
If you think we are excellent, please contact us.We will serve for you will all
our effort.>--
>> The hypercalls can be called with various parameters number.
>> Both x86_64 and i386 are supported.
>>
>> Signed-off-by: Dor Laor <[EMAIL PROTECTED]>
>> ---
>> +static inline int
>> +__hypercall6(unsigned int nr, unsigned long p1, unsigned long p2,
>> + unsigned long p3, unsigned long p4
31 matches
Mail list logo
