Anthony Liguori wrote:
Avi Kivity wrote:
Anthony Liguori wrote:
Any thoughts?
SMM continues the tradition of making each x86 generation hackier
than before.
What happens (probably) is that the virtual hardware unmaps the vga
memory when SMM is entered, and uses the physical memory at
Anthony Liguori wrote:
Howdy,
The attached patch forward ports the KVM patch to QEMU's CVS. The
only significant change needed was hacking the Bochs BIOS to
dynamically disable SMM support if KVM is enabled. This was done by
using one of the Bochs DEBUG ports. Probably not the best
James Jacobsson wrote:
I've revised the documentation patch,
Applied; thanks.
and I've also created a new
version of the building KVM without gcc 3.x patch.
I'll take a closer look at this later.
--
error compiling committee.c: too many arguments to function
On Thu, 2006-12-21 at 11:20 +0200, Avi Kivity wrote:
Jeremy Katz wrote:
Currently, kvm ends up just using the standard qemu cpu initialization.
This means that all x86_64 virtual machines appear to have an
AuthenticAMD (AMD64) processor. This ends up causing a problem when
booting some
Avi Kivity wrote:
2. Add hacks in the memory slot code to not return a memory slot if
the physical address is in the forbidden range.
I'm not sure I understand what you mean by this. I guess I have to
spend some time and understand how the whole memory slot thing works.
Memory slots are
Avi Kivity wrote:
There are four issues I can see:
- if there are multiple sources of kvm userspace, there are bound to
be problems with incompatible kernel API and userspace, especially as
I have plans for extensive changes to the API. I'll go and implement
a version check now, so that
Anthony Liguori wrote:
Avi Kivity wrote:
There are four issues I can see:
- if there are multiple sources of kvm userspace, there are bound to
be problems with incompatible kernel API and userspace, especially as
I have plans for extensive changes to the API. I'll go and implement
a
