I got this compile warning with today linux-next:
arch/x86/kvm/mmu.c: In function ‘kvm_set_pte_rmapp’:
arch/x86/kvm/mmu.c:770: warning: cast to pointer from integer of different size
arch/x86/kvm/mmu.c: In function ‘kvm_set_spte_hva’:
arch/x86/kvm/mmu.c:849: warning: cast from pointer to integer
On 10/09/2009 09:49 PM, Anthony Liguori wrote:
If I've just been sent an image produced by someone running KVM, and
my machine is not KVM-capable, or I cannot upgrade the KVM kernel
module because it's in use by other VMs (had this problem a few
times), there's no choice but to change the
On 10/09/2009 09:06 PM, Matthew Tippett wrote:
Thanks Duncan for reproducing the behavior outside myself and Phoronix.
I dug deeper into the actual syscalls being made by sqlite. The
salient part of the behaviour is small sequential writes followed by a
fdatasync (effectively a metadata-free
On Thu, Oct 08, 2009 at 07:40:12PM +0100, Jamie Lokier wrote:
Avi Kivity wrote:
On 10/08/2009 06:06 PM, Michael S. Tsirkin wrote:
On Thu, Oct 08, 2009 at 05:29:29PM +0200, Avi Kivity wrote:
On 10/08/2009 04:52 PM, Michael S. Tsirkin wrote:
PCI memory should be disabled at
On Sun, Oct 11, 2009 at 03:36:26PM +0200, Michael S. Tsirkin wrote:
No, I think Avi was right the first time.
Migrating from an older qemu will be fine at first, but at the next
reset _following_ migration, it'll be running the old BIOS on a new
qemu and fail.
-- Jamie
So after
On Sun, Oct 11, 2009 at 03:52:40PM +0200, Michael S. Tsirkin wrote:
On Sun, Oct 11, 2009 at 03:45:59PM +0200, Gleb Natapov wrote:
On Sun, Oct 11, 2009 at 03:36:26PM +0200, Michael S. Tsirkin wrote:
No, I think Avi was right the first time.
Migrating from an older qemu will be fine
On Sun, Oct 11, 2009 at 03:57:48PM +0200, Gleb Natapov wrote:
On Sun, Oct 11, 2009 at 03:52:40PM +0200, Michael S. Tsirkin wrote:
On Sun, Oct 11, 2009 at 03:45:59PM +0200, Gleb Natapov wrote:
On Sun, Oct 11, 2009 at 03:36:26PM +0200, Michael S. Tsirkin wrote:
No, I think Avi was right
On 10/11/2009 04:35 PM, Michael S. Tsirkin wrote:
No, this is not how it works, I think.
Currently BIOS ROM is loaded only on init, directly into qemu memory.
If we change it we break in-place upgrades - install qemu, run guest,
upgrade qemu, reboot guest - now the old qemu runs with a
On Sun, Oct 11, 2009 at 04:42:27PM +0200, Avi Kivity wrote:
On 10/11/2009 04:35 PM, Michael S. Tsirkin wrote:
No, this is not how it works, I think.
Currently BIOS ROM is loaded only on init, directly into qemu memory.
If we change it we break in-place upgrades - install qemu, run guest,
On Sun, Oct 11, 2009 at 04:39:46PM +0200, Gleb Natapov wrote:
On Sun, Oct 11, 2009 at 04:35:35PM +0200, Michael S. Tsirkin wrote:
On Sun, Oct 11, 2009 at 03:57:48PM +0200, Gleb Natapov wrote:
On Sun, Oct 11, 2009 at 03:52:40PM +0200, Michael S. Tsirkin wrote:
On Sun, Oct 11, 2009 at
On 10/11/2009 04:44 PM, Michael S. Tsirkin wrote:
On Sun, Oct 11, 2009 at 04:42:27PM +0200, Avi Kivity wrote:
On 10/11/2009 04:35 PM, Michael S. Tsirkin wrote:
No, this is not how it works, I think.
Currently BIOS ROM is loaded only on init, directly into qemu memory.
If we
On Sun, Oct 11, 2009 at 04:45:46PM +0200, Michael S. Tsirkin wrote:
AFAIR it is not writable on plain qemu.
What makes it non-writeable?
It goes:
bios_offset = qemu_ram_alloc(bios_size);
ret = load_image(filename, qemu_get_ram_ptr(bios_offset));
Does qemu_ram_alloc allocate
On 10/09/2009 12:03 PM, Zhai, Edwin wrote:
Tosatti,
See attached patch.
Avi,
Could you pls. do the check in if no any other comments.
Looks reasonable to me (Marcelo commits this week).
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the
On Sun, Oct 11, 2009 at 04:53:39PM +0200, Avi Kivity wrote:
On 10/11/2009 04:44 PM, Michael S. Tsirkin wrote:
On Sun, Oct 11, 2009 at 04:42:27PM +0200, Avi Kivity wrote:
On 10/11/2009 04:35 PM, Michael S. Tsirkin wrote:
No, this is not how it works, I think.
Currently BIOS ROM is
On 10/11/2009 06:12 PM, Michael S. Tsirkin wrote:
The guest is running during the upgrade, so the qemu executable is still
from the old install (but deleted).
Oh, I don't think we should re-read it from file each time.
We could read it at startup, keep a copy around for reboots.
On Sun, Oct 11, 2009 at 06:24:30PM +0200, Avi Kivity wrote:
On 10/11/2009 06:12 PM, Michael S. Tsirkin wrote:
The guest is running during the upgrade, so the qemu executable is still
from the old install (but deleted).
Oh, I don't think we should re-read it from file each time.
We
On 10/11/2009 06:33 PM, Michael S. Tsirkin wrote:
On Sun, Oct 11, 2009 at 06:24:30PM +0200, Avi Kivity wrote:
On 10/11/2009 06:12 PM, Michael S. Tsirkin wrote:
The guest is running during the upgrade, so the qemu executable is still
from the old install (but deleted).
On Sun, Oct 11, 2009 at 06:37:17PM +0200, Avi Kivity wrote:
On 10/11/2009 06:33 PM, Michael S. Tsirkin wrote:
On Sun, Oct 11, 2009 at 06:24:30PM +0200, Avi Kivity wrote:
On 10/11/2009 06:12 PM, Michael S. Tsirkin wrote:
The guest is running during the upgrade, so the qemu
On 10/11/2009 06:39 PM, Michael S. Tsirkin wrote:
rom_add_file().
Is it used for BIOS? pc.c seems to call this for initrd only?
It's used indirectly for everything.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line
On 10/11/2009 07:18 PM, Michael S. Tsirkin wrote:
On Sun, Oct 11, 2009 at 06:48:34PM +0200, Avi Kivity wrote:
On 10/11/2009 06:39 PM, Michael S. Tsirkin wrote:
rom_add_file().
Is it used for BIOS? pc.c seems to call this for initrd only?
It's used indirectly for
On 10/11/2009 07:27 PM, Avi Kivity wrote:
So we are fine then? After reset new BIOS will get used?
Yes.
I meant, we are fine for upgrade, and no, the new BIOS will not be
used. The file is only read once.
--
Do not meddle in the internals of kernels, for they are subtle and quick to
On Sun, Oct 11, 2009 at 07:28:13PM +0200, Avi Kivity wrote:
On 10/11/2009 07:27 PM, Avi Kivity wrote:
So we are fine then? After reset new BIOS will get used?
Yes.
I meant, we are fine for upgrade, and no, the new BIOS will not be used.
The file is only read once.
So this is what
On 10/11/2009 08:10 PM, Michael S. Tsirkin wrote:
So this is what happens:
- after migration from old qemu to new old BIOS is used until reset
- after reset new BIOS is used
- after upgrade from old version of qemu upgrade does not have any
effect until qemu is restarted
If this is a fair
Signed-off-by: Javier Martinez Canillas martinez.jav...@gmail.com
---
drivers/virtio/virtio_balloon.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 3978923..9dd5880 100644
---
Hi, all!
On Saturday, 22 August 2009 10:59:47 -0300,
Daniel Bareiro wrote:
According to I see in this document [1], is necessary that is loaded
two modules in the guest: acpiphp and pci_hotplug.
The pci_hotplug module is loaded. Nevertheless, in spite of existing
the acpiphp module, cannot
Bugs item #2868883, was opened at 2009-09-28 16:27
Message generated for change (Comment added) made by thekozmo
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=893831aid=2868883group_id=180599
Please note that this message will contain a full copy of the comment
On Sun, Oct 11, 2009 at 4:51 PM, Daniel Bareiro daniel-lis...@gmx.net wrote:
Hi, all!
On Saturday, 22 August 2009 10:59:47 -0300,
Daniel Bareiro wrote:
According to I see in this document [1], is necessary that is loaded
two modules in the guest: acpiphp and pci_hotplug.
The pci_hotplug
27 matches
Mail list logo
