From: Yang Zhang yang.z.zh...@intel.com
Guest may mask the IOAPIC entry before issue EOI. In such case,
EOI will not be intercepted by hypervisor due to the corrensponding
bit in eoi exit bitmap is not setting.
The solution is to check ISR + TMR to construct the EOI exit bitmap.
This patch is a
On 2014/8/8 14:02, Yang Zhang wrote:
From: Yang Zhang yang.z.zh...@intel.com
Guest may mask the IOAPIC entry before issue EOI. In such case,
EOI will not be intercepted by hypervisor due to the corrensponding
bit in eoi exit bitmap is not setting.
The solution is to check ISR + TMR to
Hi All,
This is KVM upstream test result against kvm.git next branch and qemu.git
master branch.
kvm.git next branch: c77dcacb397519b6ade8f08201a4a90a7f4f751e based on
kernel 3.16.0
qemu.git master branch: 69f87f713069f1f70f86cb65883f7d43e3aa21de
We found one new bug and two
Hello Markus,
On 07/21/2014 07:35 PM, Markus Armbruster wrote:
Do you have a compelling reason why you can't license under GPLv2+? If
yes, please explain it to us. If no, please use
* This work is licensed under the terms of the GNU GPL, version 2 or
* later. See the COPYING file in
Here is a patchset containing an update on ivshmem specs documentation and
importing ivshmem server and client tools.
These tools have been written from scratch and are not related to what is
available in nahanni repository.
I put them in contrib/ directory as the qemu-doc.texi was already telling
When using ivshmem devices, notifications between guests can be sent as
interrupts using a ivshmem-server (typical use described in documentation).
The client is provided as a debug tool.
Signed-off-by: Olivier Matz olivier.m...@6wind.com
Signed-off-by: David Marchand david.march...@6wind.com
---
Add some notes on the parts needed to use ivshmem devices: more specifically,
explain the purpose of an ivshmem server and the basic concept to use the
ivshmem devices in guests.
Move some parts of the documentation and re-organise it.
Signed-off-by: David Marchand david.march...@6wind.com
---
Hello David,
On 08.08.2014 10:55, David Marchand wrote:
Add some notes on the parts needed to use ivshmem devices: more specifically,
explain the purpose of an ivshmem server and the basic concept to use the
ivshmem devices in guests.
Move some parts of the documentation and re-organise it.
Hi,
Subject: [Qemu-devel] [PATCH v3 0/2] ivshmem: update documentation, add
client/server tools
Here is a patchset containing an update on ivshmem specs documentation and
importing ivshmem server and client tools.
These tools have been written from scratch and are not related to what is
Hello Claudio,
On 08/08/2014 11:04 AM, Claudio Fontana wrote:
On 08.08.2014 10:55, David Marchand wrote:
Add some notes on the parts needed to use ivshmem devices: more specifically,
explain the purpose of an ivshmem server and the basic concept to use the
ivshmem devices in guests.
Move some
Hello Gonglei,
On 08/08/2014 11:30 AM, Gonglei (Arei) wrote:
If you can describe the steps of using example about
your ivshmem-client and ivshmem-server will be great IMHO.
I already have included a note in the qemu-doc.texi file on how to start
the ivshmem-server.
The (debug) client is
https://bugzilla.kernel.org/show_bug.cgi?id=81841
--- Comment #11 from Marti Raudsepp ma...@juffo.org ---
(In reply to Joel Schopp from comment #10)
How would I go about confirming that? What are the chances that they care,
and provide accurate information to a random person?
Are you
Hi,
Subject: Re: [Qemu-devel] [PATCH v3 0/2] ivshmem: update documentation,
add client/server tools
Hello Gonglei,
On 08/08/2014 11:30 AM, Gonglei (Arei) wrote:
If you can describe the steps of using example about
your ivshmem-client and ivshmem-server will be great IMHO.
I already
From: Ulrich Obergfell uober...@redhat.com
In some cases we don't want hard lockup detection enabled by default.
An example is when running as a guest. Introduce
watchdog_enable_hardlockup_detector(bool)
allowing those cases to disable hard lockup detection. This must be
executed early by the
On Fri, Aug 08, 2014 at 10:55:17AM +0200, David Marchand wrote:
Looks good, a few minor comments:
diff --git a/contrib/ivshmem-client/Makefile b/contrib/ivshmem-client/Makefile
new file mode 100644
index 000..eee97c6
--- /dev/null
+++ b/contrib/ivshmem-client/Makefile
@@ -0,0 +1,29 @@
On Fri, Aug 08, 2014 at 10:55:18AM +0200, David Marchand wrote:
+For each client (QEMU processes) that connects to the server:
+- the server assigns an ID for this client and sends this ID to him as the
first
+ message,
+- the server sends a fd to the shared memory object to this client,
As a generic function, deassign_guest_irq() assumes it can be called
even if assign_guest_irq() is not be called successfully (which can be
triggered by ioctl from user mode, indirectly).
So for assign_guest_irq() failure process, need set 'dev-irq_source_id'
to -1 after free 'dev-irq_source_id',
On Thu, 2014-08-07 at 12:47 +1000, Gavin Shan wrote:
The patchset is mainly for fixing errors from building VFIO compoments
as dynamic modules. PATCH[4/4] allows VFIO can be used though EEH fails
to initialize for VFIO PCI devices.
Alexey Kardashevskiy (2):
drivers/vfio: Allow EEH to be
Hello,
I'm circling back on this patch series for review comments. Primarily
patches 1 and 3 (numbered below).
To summarize this patch series adds dirty page logging for ARMv7, the dirty
page log read function has been moved to generic layer common between
x86, armv7, as result the function
On Fri, 2014-08-08 at 14:02 +0800, Yang Zhang wrote:
From: Yang Zhang yang.z.zh...@intel.com
Guest may mask the IOAPIC entry before issue EOI. In such case,
EOI will not be intercepted by hypervisor due to the corrensponding
bit in eoi exit bitmap is not setting.
The solution is to check
Hi Guys,
I have recently deployed a new hypervisor with the intent to use in
the hosting of both Linux Windows virtual machines, however after
getting everything setup I am running into issues where is appears the
virtual machines are freezing or stuttering for a few seconds at
random intervals.
On Mon, Aug 04, 2014 at 09:38:45AM -0500, Joel Schopp wrote:
The current VTTBR_BADDR_MASK only masks 39 bits, which is broken on current
systems. Rather than just add a bit it seems like a good time to also set
things at run-time instead of compile time to accomodate more hardware.
This
https://bugzilla.kernel.org/show_bug.cgi?id=53361
--- Comment #2 from Ian Allison ifalli...@gmail.com ---
seems to be working for me now.
--
You are receiving this mail because:
You are watching the assignee of the bug.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body
23 matches
Mail list logo
