Hi,
On Wed, Jul 20, 2011 at 10:35 AM, Gleb Natapov g...@redhat.com wrote:
On Tue, Jul 19, 2011 at 07:40:55PM +0200, Vasilis Liaskovitis wrote:
Hello,
I have encountered a problem trying to hotplug a CPU in my x86_64 guest
setup.
You do everything right. It's qemu who is buggy. Since qemu
On 07/21/2011 04:08 PM, Vasilis Liaskovitis wrote:
Hi,
thanks for looking at this closer.
On Thu, Jul 21, 2011 at 1:33 PM, Gleb Natapovg...@redhat.com wrote:
Note that there is probably another bug in qemu-kvm/master regarding
acpi-udev event delivery for
a cpu-hotplug event (cpu_set
On 07/21/2011 04:15 PM, Avi Kivity wrote:
I also tried to separately bisect the acpi-udev delivery issue between
0.13.0 and qemu-kvm/master but ended up
with a big merge commit as the culprit. Not sure if it would help.
You can bisect it further. If you tag the bad commit bad, then you do
On 07/21/2011 09:18 AM, Avi Kivity wrote:
On 07/21/2011 02:55 PM, Jan Kiszka wrote:
CPU hotplug for Linux suppose to be easy (with allow_hotplug patch
applied). But we have two bugs currently. One is that ACPI interrupt
I bet we have multiple bugs for quite a while now, which accelerated
On 2011-07-21 10:37, Avi Kivity wrote:
On 07/21/2011 12:43 AM, Jan Kiszka wrote:
On 2011-07-20 19:43, Avi Kivity wrote:
On 07/20/2011 08:41 PM, Jan Kiszka wrote:
On 2011-07-20 18:49, Avi Kivity wrote:
New in this version:
- more mindless conversions; I believe there are no
On 07/21/2011 04:38 PM, Jan Kiszka wrote:
On 2011-07-21 10:37, Avi Kivity wrote:
On 07/21/2011 12:43 AM, Jan Kiszka wrote:
On 2011-07-20 19:43, Avi Kivity wrote:
On 07/20/2011 08:41 PM, Jan Kiszka wrote:
On 2011-07-20 18:49, Avi Kivity wrote:
New in this version:
On 07/21/2011 04:17 PM, Jan Kiszka wrote:
On 2011-07-21 14:58, Avi Kivity wrote:
On 07/21/2011 03:52 PM, Jan Kiszka wrote:
The problem is that update can change lots of things. offset, size,
whether it's mmio or RAM, read-onlyness, even the wierd things like
coalesced mmio. So it's
I still cannot belive this.
This is test under bonding (round-robind) and bridging (bond0 - br0 to
expose VM to LAN)
From VM Debian with one Virtio NIC to Debian Hypervisor I have (1, 2
and 3 connections at once):
user@vhost:~$ iperf -c 10.0.0.250
On 2011-07-21 15:43, Avi Kivity wrote:
@@ -1093,9 +1093,26 @@ void
memory_region_add_subregion_overlap(MemoryRegion *mr,
void memory_region_del_subregion(MemoryRegion *mr,
MemoryRegion *subregion)
{
+MemoryRegion *target_region;
+
On 07/21/2011 05:19 PM, Jan Kiszka wrote:
Makes some sense. I even wonder if this isn't a KVM deficit and should
be handled there when a logged region is unmapped.
What do you mean? There is a known issue with kvm here, this is a just
workaround.
Then the logic indeed belongs to
On 2011-07-21 15:50, Avi Kivity wrote:
On 07/21/2011 04:17 PM, Jan Kiszka wrote:
On 2011-07-21 14:58, Avi Kivity wrote:
On 07/21/2011 03:52 PM, Jan Kiszka wrote:
The problem is that update can change lots of things. offset, size,
whether it's mmio or RAM, read-onlyness, even the wierd
On 2011-07-21 16:31, Avi Kivity wrote:
On 07/21/2011 05:19 PM, Jan Kiszka wrote:
Makes some sense. I even wonder if this isn't a KVM deficit and should
be handled there when a logged region is unmapped.
What do you mean? There is a known issue with kvm here, this is a just
workaround.
On 07/21/2011 05:32 PM, Jan Kiszka wrote:
On 2011-07-21 15:50, Avi Kivity wrote:
On 07/21/2011 04:17 PM, Jan Kiszka wrote:
On 2011-07-21 14:58, Avi Kivity wrote:
On 07/21/2011 03:52 PM, Jan Kiszka wrote:
The problem is that update can change lots of things. offset, size,
whether
On 07/21/2011 05:34 PM, Jan Kiszka wrote:
On 2011-07-21 16:31, Avi Kivity wrote:
On 07/21/2011 05:19 PM, Jan Kiszka wrote:
Makes some sense. I even wonder if this isn't a KVM deficit and should
be handled there when a logged region is unmapped.
What do you mean? There is a known
https://bugzilla.kernel.org/show_bug.cgi?id=37152
--- Comment #3 from Martin Chamberland martin.chamberl...@fadq.qc.ca
2011-07-21 14:59:37 ---
The problem was probably due because of the use of NFS in our setup.
I now use iSCSI to share LUN from both servers and everything seem to work
https://bugzilla.kernel.org/show_bug.cgi?id=37152
Martin Chamberland martin.chamberl...@fadq.qc.ca changed:
What|Removed |Added
Status|NEW
From: Cleber Rosa cr...@redhat.com
The ongoing refactor work on the virt installer has led the creation
of helper classes. There are basically three types of helper classes:
* Content helper classes, that ease and provide a common interface
for fetching content, usually source code, either
On 2011-07-21 16:39, Avi Kivity wrote:
On 07/21/2011 05:32 PM, Jan Kiszka wrote:
On 2011-07-21 15:50, Avi Kivity wrote:
On 07/21/2011 04:17 PM, Jan Kiszka wrote:
On 2011-07-21 14:58, Avi Kivity wrote:
On 07/21/2011 03:52 PM, Jan Kiszka wrote:
The problem is that update can change
On 07/21/2011 06:05 PM, Jan Kiszka wrote:
The point is _update() can only make changes for one region atomic,
while _commit() is more general. You can sometimes batch all changes
into a single container region, but sometimes it is clumsy, and
sometimes impossible.
Deletion and
On Tue, Jul 12, 2011 at 10:31:00AM +0100, Peter Zijlstra wrote:
On Tue, 2011-07-12 at 12:27 +0300, Avi Kivity wrote:
On 07/12/2011 12:18 PM, Peter Zijlstra wrote:
The guarantee is that the task was sleeping just before the function is
called. Of course it's woken up to run the
On 07/21/2011 06:32 PM, Will Deacon wrote:
Using TIF_bits sounds like a much better solution for this, wakeups are
really rather expensive and its best to avoid extra if at all possible.
The problem with using a TIF bit to tell a task that it needs to perform
some preempt_notifier
On Thu, Jul 21, 2011 at 04:36:43PM +0100, Avi Kivity wrote:
On 07/21/2011 06:32 PM, Will Deacon wrote:
Using TIF_bits sounds like a much better solution for this, wakeups are
really rather expensive and its best to avoid extra if at all possible.
The problem with using a TIF bit to
On 07/21/2011 04:11 AM, Michael S. Tsirkin wrote:
On Wed, Jul 20, 2011 at 07:49:34PM -0400, Donald Dutile wrote:
Bounds check to avoid walking off config_map[]
and corrupting what is after it.
Signed-off-by: Donald Dutileddut...@redhat.com
cc: Alex Williamsonalex.william...@redhat.com
cc:
On 07/21/2011 06:46 PM, Will Deacon wrote:
This is (and must be) called from a preempt disabled context, no mutexes
around here.
Bah, yes, that is essential if you're dealing with current. Maybe use a
spinlock instead?
Could work. Not thrilled about adding it to the kvm hot path, but I
On Thu, Jul 21, 2011 at 04:59:00PM +0100, Avi Kivity wrote:
On 07/21/2011 06:46 PM, Will Deacon wrote:
This is (and must be) called from a preempt disabled context, no mutexes
around here.
Bah, yes, that is essential if you're dealing with current. Maybe use a
spinlock instead?
On Thu, 2011-07-21 at 12:39 -0400, Donald Dutile wrote:
v2: do local boundary check with respect to legacy PCI header length,
and don't depend on it in pci_add_capability().
: fix compilation, and change else2 to simple else for all other cases.
Doing device assignement using a PCIe
v2: do local boundary check with respect to legacy PCI header length,
and don't depend on it in pci_add_capability().
: fix compilation, and change else2 to simple else for all other cases.
Doing device assignement using a PCIe device with it's
PCI Cap structure at offset 0xcc showed a
On 07/21/2011 01:02 PM, Alex Williamson wrote:
On Thu, 2011-07-21 at 12:39 -0400, Donald Dutile wrote:
v2: do local boundary check with respect to legacy PCI header length,
and don't depend on it in pci_add_capability().
: fix compilation, and change else2 to simple else for all other
Don't mess with assign_intx on devices that are in MSI or MSI-X mode, it
would corrupt their interrupt routing.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/device-assignment.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/hw/device-assignment.c
Always clear AssignedDevice::irq_requested_type after calling
kvm_deassign_irq. Moreover, drop the obviously incorrect exclusion when
reporting related errors - if irq_requested_type is non-zero, deassign
must not fail.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/device-assignment.c
All constants are now available through QEMU. Also drop the upstream
diff of pci_regs.h, it cannot clash with libpci anymore.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
configure | 21 -
hw/device-assignment.c | 13 ++---
hw/pci_regs.h
Update of the unmerged half of this series. It logically depends on
pci: Common overflow prevention, but not mechanically. Changes in this
release only affect the 6th patch. It gained support for 3-byte config
space accesses, received a fix as the previous version broke MSI-X, and
was further
Device assignment no longer peeks into config_map, so we can drop all
the related changes and sync the PCI core with upstream.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/pci.c | 29 +++--
hw/pci.h |8 ++--
2 files changed, 21 insertions(+), 16
Make calc_assigned_dev_id pick up all required bits from the device
passed to it.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/device-assignment.c | 25 +
hw/device-assignment.h |6 +++---
2 files changed, 12 insertions(+), 19 deletions(-)
diff --git
Store the MSI and MSI-X capability position in the same fields the QEMU
core uses as well. Although we still open-code MSI support, this does
not cause conflicts. Instead, it allow us to drop config space searches
from assigned_device_pci_cap_write_config. Moreover, we no longer need
to pass the
This drastically simplifies config space access management: Instead of
coding various range checks and merging bits, set up two access control
bitmaps. One defines, which bits can be directly read from the device,
the other allows direct write to the device, also with bit-granularity.
The setup
On Wed, Jul 20, 2011 at 7:49 PM, Avi Kivity a...@redhat.com wrote:
As with the rest of the memory API, the caller associates an eventfd
with an address, and the memory API takes care of registering or
unregistering when the address is made visible or invisible to the
guest.
Signed-off-by:
get support for the HV_X64_MSR_APIC_ASSIST_PAGE msr was missing, even
though it is explicitly enumerated as something the vmm should save in
msrs_to_save and reported to userland via the KVM_GET_MSR_INDEX_LIST
ioctl.
Add get support for HV_X64_MSR_APIC_ASSIST_PAGE. We simply return the
guest
- Original Message -
From: Marcelo Tosatti mtosa...@redhat.com
To: Umesh Deshpande udesh...@redhat.com
Cc: kvm@vger.kernel.org, qemu-de...@nongnu.org
Sent: Wednesday, July 20, 2011 3:02:46 PM
Subject: Re: [RFC 3/4] A separate thread for the VM migration
On Wed, Jul 20, 2011 at
I am trying to add 1366x768 resolution for standard VGA. I looked at
http://www.linux-kvm.org/page/FAQ#Can_I_have_higher_or_widescreen_resolutions_.28eg_1680_x_1050.29_in_KVM.3F
and
http://article.gmane.org/gmane.comp.emulators.kvm.devel/13557
I added a line to vbetables-gen.c but that did not
40 matches
Mail list logo
