On Sunday 11 January 2009 21:59:15 Harald Braumann wrote:
> On Sun, 11 Jan 2009 12:35:12 +0800
>
> Sheng Yang wrote:
> > On Sun, Jan 11, 2009 at 01:12:42AM +0100, Harald Braumann wrote:
> > > Hi!
> > >
> > > (please CC me, as I'm not subscribed)
> > >
> > > I try to give the guest (Windows XP) dir
Anthony Liguori wrote:
+
+#ifdef TAP_VNET_HDR
+qemu_put_be32(f, tap_has_vnet_hdr(n->vc->vlan->first_client));
+#endif
This should increment the save/restore format version number to
preserve backwards compatibility. It'll also be required for merging
into QEMU upstream.
As a rule, i
On Sunday 11 January 2009 17:38:22 Avi Kivity wrote:
> Sheng Yang wrote:
> > After reconsidering, I must say I prefer add/remove ioctls.
> >
> > About the code size, I don't think it would increase much. I've rewritten
> > the code twice, I think I know the difference is little.
> >
> :( sorry abou
Andre Przywara wrote:
ehrha...@linux.vnet.ibm.com wrote:
From: Christian Ehrhardt
There is already a variable kvm_cflags which gets the path of the kernel
includes when using --kerneldir. But eventually with newer kernels we
all will
need arch/$arch/include too (my case was a incldue of asm/k
If this is the wrong place to ask this question, please let me know.
I’m running kvm-80 on ubuntu 8.04 x64 kernel 2.6.24-22-server, md raid 5 with
LVM. When my host is first booted my windows XP guest runs fine, but after
around a week or so of uptime, they start to run very sluggish. It takes a
Avi Kivity wrote:
From: Mark McLoughlin
We were failing to save whether the tx/rx buffers we exchange with the tap
code should include a virtio_net_hdr header; this caused the migrated guest
to receive garbage packets because the tap code was stripping away the header
and virtio_net was interpr
Bugs item #2494730, was opened at 2009-01-09 09:59
Message generated for change (Comment added) made by kmshanah
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2494730&group_id=180599
Please note that this message will contain a full copy of the comment
In the segment descriptor _cache_ the accessed bit is always set
(although it can be cleared in the descriptor itself). Since Intel
checks for this condition on a VMENTRY, set this bit in the AMD path
to enable cross vendor migration.
Signed-off-by: Andre Przywara
Acked-By: Amit Shah
---
arch/x
Some typos, comments, whitespace errors corrected in the cpuid code
Signed-off-by: Amit Shah
---
arch/x86/include/asm/kvm.h |6 +++---
arch/x86/kvm/x86.c | 43 +--
2 files changed, 24 insertions(+), 25 deletions(-)
diff --git a/arch/x86/incl
Avi Kivity wrote:
Mark McLoughlin wrote:
Hi Avi,
A new version, with Anthony's suggested savevm version number bump.
I've already committed this as ea47a77149b1. Sorry if my previous
message gave the impression I didn't.
Oops. For some reason I though this was a new message.
--
er
Mark McLoughlin wrote:
Hi Avi,
A new version, with Anthony's suggested savevm version number bump.
I've already committed this as ea47a77149b1. Sorry if my previous
message gave the impression I didn't.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe f
I've rebased the kvm bios modifications on top of the latest bochs
bios. The patchqueue can be found in the branch bios-patchqueue in
kvm-userspace.git; the baseline is bochs-bios-cvs (so that git
format-patch bochs-bios-cvs..bios-patchqueue will dump the entire queue).
Note that it's possibl
On Sun, 11 Jan 2009 12:35:12 +0800
Sheng Yang wrote:
> On Sun, Jan 11, 2009 at 01:12:42AM +0100, Harald Braumann wrote:
> > Hi!
> >
> > (please CC me, as I'm not subscribed)
> >
> > I try to give the guest (Windows XP) direct access to one of the
> > graphics adaptors.
> > [...]
>
> Hi Harry
Bill Rieske wrote:
dev_memsize ends up 0 when it shouldn't be on 16G boundary conditions.
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.org
Amit Shah wrote:
On Sun, Jan 11, 2009 at 12:46:49PM +0200, Avi Kivity wrote:
Amit Shah wrote:
The CPUID instruction takes the value of ECX as an input parameter
in addition to the value of EAX for function 4. Make sure we pass
the value to the instruction.
This needs to go to
On Sun, Jan 11, 2009 at 12:46:49PM +0200, Avi Kivity wrote:
> Amit Shah wrote:
>> The CPUID instruction takes the value of ECX as an input parameter
>> in addition to the value of EAX for function 4. Make sure we pass
>> the value to the instruction.
>>
>>
>
> This needs to go to upstream qemu.
Amit Shah wrote:
The CPUID instruction takes the value of ECX as an input parameter
in addition to the value of EAX for function 4. Make sure we pass
the value to the instruction.
This needs to go to upstream qemu. I'd suggest adding a new parameter
rather than making ecx an in/out parame
The CPUID instruction takes the value of ECX as an input parameter
in addition to the value of EAX for function 4. Make sure we pass
the value to the instruction.
Signed-off-by: Amit Shah
---
qemu/target-i386/helper.c |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git
Avi Kivity wrote:
1. add/remove ioctls
The advantage is that very little work needs to be done when something
changes, but the code size (and bug count) doubles.
One disadvantage of add/remove is that we cannot effect a change
atomically. Probably not a big deal, but something to keep in
Sheng Yang wrote:
After reconsidering, I must say I prefer add/remove ioctls.
About the code size, I don't think it would increase much. I've rewritten
the code twice, I think I know the difference is little.
:( sorry about that.
For the option 2 route table ioctl, we got a array from use
Sheng Yang wrote:
On Fri, Jan 09, 2009 at 08:06:01PM +0200, Avi Kivity wrote:
Sheng Yang wrote:
+struct kvm_gsi_route_entry_guest {
what does _guest mean here? almost all kvm stuff is _guest related.
Because I can't think of a good name... kvm_gsi_route_
Marcelo Tosatti wrote:
On Wed, Jan 07, 2009 at 01:32:41PM +0200, Avi Kivity wrote:
Marcelo Tosatti wrote:
Let me shoot at one direction: a shadow page with PGE bit in either
state is created. Later that shadow page is nuked (via mmu notifiers,
for example).
I doubt that mmu noti
On Wed, Jan 07, 2009 at 01:32:41PM +0200, Avi Kivity wrote:
> Marcelo Tosatti wrote:
>> Let me shoot at one direction: a shadow page with PGE bit in either
>> state is created. Later that shadow page is nuked (via mmu notifiers,
>> for example).
>
> I doubt that mmu notifiers were invoked in this
On Sun, Jan 11, 2009 at 04:16:03AM +0100, Paolo Pedaletti wrote:
> ciao,
> I have a problem to run a 64 bit intel guest inside a 64 bit intel host.
> It doesn' boot.
Looks like the core2duo CPU type has the problem.
> trying to boot the guest:
> /usr/local/bin/qemu-system-x86_64 -cpu core2duo
>
Anthony Liguori wrote:
Paul Brook wrote:
A concern here is the growing size of the virtio-net I/O port space
config. This series brings it up to 256 bytes with PCI resource
rounding. The VLAN filter bitmap would increase that by another 512
bytes, making it 1kB and limiting us to something les
25 matches
Mail list logo
