On 25/11/2014 04:15, Zhang, Yang Z wrote:
> > The IRR register means an interrupt was received and not serviced yet,
> > similar to the LAPIC or PIC register. It is not the same thing as the
> > interrupt line level (it happens to be for level-triggered interrupts).
>
> Yes, but commit(0bc830b05
[Re-adding cc list]
On Mon, Nov 24, 2014 at 05:42:30PM +0100, Eric Auger wrote:
> On 11/24/2014 04:47 PM, Christoffer Dall wrote:
> > On Mon, Nov 24, 2014 at 12:02 PM, Eric Auger wrote:
> >> On 11/24/2014 11:00 AM, Christoffer Dall wrote:
> >>> On Sun, Nov 23, 2014 at 06:56:59PM +0100, Eric Auger
Hi Mario,
On Thu, Nov 13, 2014 at 05:57:41PM -0800, Mario Smarduch wrote:
> Patch series adds support for ARMv7 and generic dirty page logging support.
> As we try to move towards generic dirty page logging additional logic is
> moved
> to generic code. Initially x86, armv7 KVM_GET_DIRTY_LOG re
Hi Paolo,
On Mon, Nov 24, 2014 at 05:43:32PM +0100, Paolo Bonzini wrote:
>The first patch ensures that XSAVES is not exposed in the guest until
>we emulate MSR_IA32_XSS. The second exports XSAVE data in the correct
>format.
>
>I tested these on a non-XSAVES system so they should not be completely
On 25/11/2014 11:13, Wanpeng Li wrote:
> Hi Paolo,
> On Mon, Nov 24, 2014 at 05:43:32PM +0100, Paolo Bonzini wrote:
>> The first patch ensures that XSAVES is not exposed in the guest until
>> we emulate MSR_IA32_XSS. The second exports XSAVE data in the correct
>> format.
>>
>> I tested these on
On Mon, Nov 24, 2014 at 01:22:16PM -0800, Mario Smarduch wrote:
> On 11/22/2014 12:02 PM, Christoffer Dall wrote:
> > On Sat, Nov 15, 2014 at 12:19:10AM -0800, m.smard...@samsung.com wrote:
> >> From: Mario Smarduch
> >>
> >> This patch enables ARMv8 ditry page logging support. Plugs ARMv8 into
>
>> I tested win-server-2008 with "-cpu
>> core2duo,hv_spinlocks=0x,hv_relaxed,hv_time",
>> this problem still happened, about 200,000 vmexits per-second,
>> bringing very bad experience, just like being stuck.
>
>Please upload a full trace somewhere, or at least the "perf report" output.
>
#
This patch adds and documents a new attribute
KVM_DEV_VFIO_DEVICE_POSTING_IRQ in KVM_DEV_VFIO_DEVICE group.
This new attribute is used for VT-d Posted-Interrupts.
When guest OS changes the interrupt configuration for an
assigned device, such as, MSI/MSIx data/address fields,
QEMU will use this IRQ
VT-d Posted-Interrupts is an enhancement to CPU side Posted-Interrupt.
With VT-d Posted-Interrupts enabled, external interrupts from
direct-assigned devices can be delivered to guests without VMM
intervention when guest is running in non-root mode.
You can find the VT-d Posted-Interrtups Spec. in
This patch adds the kvm-vfio interface for VT-d Posted-Interrrupts.
When guests updates MSI/MSI-x information for an assigned-device,
QEMU will use KVM_DEV_VFIO_DEVICE_POSTING_IRQ attribute to setup
IRTE for VT-d PI. This patch implement this IRQ attribute.
Signed-off-by: Feng Wu
---
virt/kvm/vf
Hi Michael,
> Hi Razya,
> On the netperf benchmark, it looks like polling=10 gives a modest but
> measureable gain. So from that perspective it might be worth it if it's
> not too much code, though we'll need to spend more time checking the
> macro effect - we barely moved the needle on the macro
Hi Christoffer,
On Mon, Nov 24, 2014 at 8:07 PM, Christoffer Dall
wrote:
> On Mon, Nov 24, 2014 at 02:14:48PM +0530, Anup Patel wrote:
>> On Fri, Nov 21, 2014 at 5:19 PM, Christoffer Dall
>> wrote:
>> > On Fri, Nov 21, 2014 at 04:06:05PM +0530, Anup Patel wrote:
>> >> Hi Christoffer,
>> >>
>> >>
On 11/25/2014 11:19 AM, Christoffer Dall wrote:
> [Re-adding cc list]
>
> On Mon, Nov 24, 2014 at 05:42:30PM +0100, Eric Auger wrote:
>> On 11/24/2014 04:47 PM, Christoffer Dall wrote:
>>> On Mon, Nov 24, 2014 at 12:02 PM, Eric Auger wrote:
On 11/24/2014 11:00 AM, Christoffer Dall wrote:
>>>
Support the new CCW_CMD_SET_VQ format for virtio-1 devices.
While we're at it, refactor the code a bit and enforce big endian
fields (which had always been required, even for legacy).
Reviewed-by: Thomas Huth
Signed-off-by: Cornelia Huck
---
hw/s390x/virtio-ccw.c | 114 +++
The only user of this function was virtio-ccw, and it should use
virtio_set_features() like everybody else: We need to make sure
that bad features are masked out properly, which this function did
not do.
Reviewed-by: Thomas Huth
Signed-off-by: Cornelia Huck
---
hw/s390x/virtio-ccw.c |
Hi,
here's the next version of my virtio-1 qemu patchset. Using virtio-1
virtio-blk and virtio-net devices with a guest kernel built from
<1416829787-14252-1-git-send-email-...@redhat.com> still seems to
work for the virtio-ccw transport.
Changes from v1:
- rebased against current master
- don't
Handle endianness conversion for virtio-1 virtqueues correctly.
Note that dataplane now needs to be built per-target.
Signed-off-by: Cornelia Huck
---
hw/block/dataplane/virtio-blk.c |3 +-
hw/scsi/virtio-scsi-dataplane.c |2 +-
hw/virtio/Makefile.objs |2 +-
hw/
virtio-ccw should now have everything in place to operate virtio 1.0
devices, so let's enable revision 1.
Signed-off-by: Cornelia Huck
---
hw/s390x/virtio-ccw.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/s390x/virtio-ccw.h b/hw/s390x/virtio-ccw.h
index 03d5955..08e
From: Thomas Huth
Add the new VIRTIO_F_VERSION_1 definition to the virtio_config.h
linux header.
Signed-off-by: Thomas Huth
Signed-off-by: Cornelia Huck
---
linux-headers/linux/virtio_config.h |3 +++
1 file changed, 3 insertions(+)
diff --git a/linux-headers/linux/virtio_config.h
b/lin
From: Thomas Huth
Handle the virtio-ccw revision according to what the guest sets.
When revision 1 is selected, we have a virtio-1 standard device
with byteswapping for the virtio rings.
When a channel gets disabled, we have to revert to the legacy behavior
in case the next user of the device do
Introduce a helper function to indicate whether a virtio device is
operating in legacy or virtio standard mode.
It may be used to make decisions about the endianess of virtio accesses
and other virtio-1 specific changes, enabling us to support transitional
devices.
Reviewed-by: Thomas Huth
Sign
We need to check guest feature size, not host feature size to find
out whether we should call virtio_set_features(). This check is
possible now that vdev->guest_features is an array.
Reviewed-by: Thomas Huth
Signed-off-by: Cornelia Huck
---
hw/s390x/virtio-ccw.c |2 +-
1 file changed, 1 ins
virtio-net (non-vhost) and virtio-blk have everything in place to support
virtio 1.0: let's enable the feature bit for them.
Note that VIRTIO_F_VERSION_1 is technically a transport feature; once
every device is ready for virtio 1.0, we can move this setting this
feature bit out of the individual d
From: Thomas Huth
We need a possibility to run code when a subchannel gets disabled.
This patch adds the necessary infrastructure.
Signed-off-by: Thomas Huth
Signed-off-by: Cornelia Huck
---
hw/s390x/css.c | 12
hw/s390x/css.h |1 +
2 files changed, 13 insertions(+)
diff -
For virtio-1 devices, we allow a more complex queue layout that doesn't
require descriptor table and rings on a physically-contigous memory area:
add virtio_queue_set_rings() to allow transports to set this up.
Signed-off-by: Cornelia Huck
---
hw/virtio/virtio.c | 16
With virtio-1, we support more than 32 feature bits. Let's make
vdev->guest_features depend on the number of supported feature bits,
allowing us to grow the feature bits automatically.
We also need to enhance the internal functions dealing with getting
and setting features with an additional index
On 11/25/2014 02:12 PM, Eric Auger wrote:
> On 11/25/2014 11:19 AM, Christoffer Dall wrote:
>> [Re-adding cc list]
>>
>> On Mon, Nov 24, 2014 at 05:42:30PM +0100, Eric Auger wrote:
>>> On 11/24/2014 04:47 PM, Christoffer Dall wrote:
On Mon, Nov 24, 2014 at 12:02 PM, Eric Auger wrote:
> On
On 11/25/2014 05:33 AM, Wu, Feng wrote:
>
>
>> -Original Message-
>> From: Eric Auger [mailto:eric.au...@linaro.org]
>> Sent: Monday, November 24, 2014 2:36 AM
>> To: eric.au...@st.com; eric.au...@linaro.org; christoffer.d...@linaro.org;
>> marc.zyng...@arm.com; linux-arm-ker...@lists.inf
On Tue, Nov 25, 2014 at 06:17:03PM +0530, Anup Patel wrote:
> Hi Christoffer,
>
> On Mon, Nov 24, 2014 at 8:07 PM, Christoffer Dall
> wrote:
> > On Mon, Nov 24, 2014 at 02:14:48PM +0530, Anup Patel wrote:
> >> On Fri, Nov 21, 2014 at 5:19 PM, Christoffer Dall
> >> wrote:
> >> > On Fri, Nov 21, 2
On 25/11/2014 12:20, Zhang Haoyu wrote:
>>> I tested win-server-2008 with "-cpu
>>> core2duo,hv_spinlocks=0x,hv_relaxed,hv_time",
>>> this problem still happened, about 200,000 vmexits per-second,
>>> bringing very bad experience, just like being stuck.
>>
>> Please upload a full trace some
> On Nov 25, 2014, at 12:36, Paolo Bonzini wrote:
>
>
>
> On 25/11/2014 11:13, Wanpeng Li wrote:
>> Hi Paolo,
>> On Mon, Nov 24, 2014 at 05:43:32PM +0100, Paolo Bonzini wrote:
>>> The first patch ensures that XSAVES is not exposed in the guest until
>>> we emulate MSR_IA32_XSS. The second exp
On 25/11/2014 15:05, Nadav Amit wrote:
> > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > index 373b0ab9a32e..ca26681455c2 100644
> > --- a/arch/x86/kvm/x86.c
> > +++ b/arch/x86/kvm/x86.c
> > @@ -6955,6 +6955,9 @@ int fx_init(struct kvm_vcpu *vcpu)
> > return err;
> >
> >
Hi
In today call ony one announcement in the agenda:
- Greesocs announces that they are starting ultithreading TCG.
- They would start with usermode (it looks easier). Althought they are
more interested in system mode.
- would start with a minimal wiki page, and ask for colaboration about
i
> On Nov 25, 2014, at 16:17, Paolo Bonzini wrote:
>
>
>
> On 25/11/2014 15:05, Nadav Amit wrote:
>>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>>> index 373b0ab9a32e..ca26681455c2 100644
>>> --- a/arch/x86/kvm/x86.c
>>> +++ b/arch/x86/kvm/x86.c
>>> @@ -6955,6 +6955,9 @@ int fx_init(
On 11/25/2014 01:23 PM, Feng Wu wrote:
> This patch adds and documents a new attribute
> KVM_DEV_VFIO_DEVICE_POSTING_IRQ in KVM_DEV_VFIO_DEVICE group.
> This new attribute is used for VT-d Posted-Interrupts.
>
> When guest OS changes the interrupt configuration for an
> assigned device, such as, M
As some architectures (e.g. s390) can't disable preemption while
entering/leaving the guest, they won't receive the yield in all situations.
kvm_enter_guest() has to be called with preemption_disabled and will set
PF_VCPU. After that point e.g. s390 reenables preemption and starts to execute
the
Currently, we allow changing the PID of a VCPU. This PID is used to
identify the thread to yield to if we want to yield to this specific
VCPU.
In practice (e.g. QEMU), the thread creating and executing the VCPU remains
always the same. Temporarily exchanging the PID (e.g. because an ioctl is
trigg
On Tue, 2014-11-25 at 20:23 +0800, Feng Wu wrote:
> This patch adds the kvm-vfio interface for VT-d Posted-Interrrupts.
> When guests updates MSI/MSI-x information for an assigned-device,
> QEMU will use KVM_DEV_VFIO_DEVICE_POSTING_IRQ attribute to setup
> IRTE for VT-d PI. This patch implement thi
This series improves yielding on architectures that cannot disable preemption
while entering the guest and makes the creating thread of a VCPU the owning
thread and therefore the yield target when yielding to that VCPU.
We should focus on the case creating thread == executing thread and therefore
On Tue, 2014-11-25 at 16:01 +0100, Eric Auger wrote:
> On 11/25/2014 01:23 PM, Feng Wu wrote:
> > This patch adds and documents a new attribute
> > KVM_DEV_VFIO_DEVICE_POSTING_IRQ in KVM_DEV_VFIO_DEVICE group.
> > This new attribute is used for VT-d Posted-Interrupts.
> >
> > When guest OS changes
The following patches implement support for debugging of KVM guests on
arm64 hardware. It supports SW and HW break points as well as
single-step functionality. I've created a branch of QEMU with the
userspace support to test this at:
https://github.com/stsquad/qemu/tree/kvm/guest-debug-kvm-submiss
Bring into line with the commentary for the other structures and their
KVM_EXIT_* cases.
Signed-off-by: Alex Bennée
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 6076882..523f476 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -226,6 +226,7 @@ str
This adds support for userspace to control the HW debug registers for
guest debug. We'll only copy the $ARCH defined number across as that's
all that hyp.S will use anyway. I've moved some helper functions into
the hw_breakpoint.h header for re-use.
As with single step we need to tweak the guest r
This adds support for SW breakpoints inserted by userspace.
First we need to trap all BKPT exceptions in the hypervisor (ELS). This
in controlled through the MDCR_EL2 register. I've added a new field to
the vcpu structure to hold this value. There should be scope to
rationlise this with the VCPU_D
This commit adds a stub function to support the KVM_SET_GUEST_DEBUG
ioctl. Currently any operation flag will return EINVAL. Actual
functionality will be added with further patches.
Signed-off-by: Alex Bennée .
diff --git a/Documentation/virtual/kvm/api.txt
b/Documentation/virtual/kvm/api.txt
ind
This commit defines the API headers for guest debugging. There are two
architecture specific debug structures:
- kvm_guest_debug_arch, allows us to pass in HW debug registers
- kvm_debug_exit_arch, signals the exact debug exit and address
The type of debugging being used is control by the arc
This adds support for single-stepping the guest. As userspace can and
will manipulate guest registers before restarting any tweaking of the
registers has to occur just before control is passed back to the guest.
Furthermore while guest debugging is in effect we need to squash the
ability of the gue
This is a pre-cursor to sharing the code with the guest debug support.
This replaces the big macro that fishes data out of a fixed location
with a more general helper macro to restore a set of debug registers. It
uses macro substitution so it can be re-used for debug control and value
registers. It
On 25 November 2014 at 16:10, Alex Bennée wrote:
> +/* Exit types which define why we did a debug exit */
> +#define KVM_DEBUG_EXIT_ERROR 0x0
> +#define KVM_DEBUG_EXIT_SINGLE_STEP 0x1
> +#define KVM_DEBUG_EXIT_SW_BKPT 0x2
> +#define KVM_DEBUG_EXIT_HW_BKPT 0x3
> +#defi
On 24/11/2014 14:59, Alex Bennée wrote:
> Alexander Graf pointed out that KVM_CHECK_EXTENSION can return any
> positive number for success. How about using:
>
> max_hw_bps = kvm_check_extension(kvm_state, KVM_CAP_GUEST_DEBUG_HW_BPS);
> max_hw_wps = kvm_check_extension(kvm_state, KVM_CAP_GUEST_DE
On 25.11.14 17:21, Paolo Bonzini wrote:
>
>
> On 24/11/2014 14:59, Alex Bennée wrote:
>> Alexander Graf pointed out that KVM_CHECK_EXTENSION can return any
>> positive number for success. How about using:
>>
>> max_hw_bps = kvm_check_extension(kvm_state, KVM_CAP_GUEST_DEBUG_HW_BPS);
>> max_hw_w
On 24/11/2014 15:52, Christoffer Dall wrote:
>
> We had a lenghty IRC discussion on this, for the curious, go read it
> here:
> http://irclogs.linaro.org/2014/11/24/%23kvm-arm.html
Some notes...
> chazy but saying that you want to design an ABI that potentially exposes
> fewer debug registers
Include all endian conversions as required by virtio 1.0.
Don't set virtio 1.0 yet, since that requires ANY_LAYOUT
which we don't yet support.
Signed-off-by: Michael S. Tsirkin
---
drivers/vhost/scsi.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/d
On Tue, Nov 25, 2014 at 02:24:11PM +0100, Cornelia Huck wrote:
> Hi,
>
> here's the next version of my virtio-1 qemu patchset. Using virtio-1
> virtio-blk and virtio-net devices with a guest kernel built from
> <1416829787-14252-1-git-send-email-...@redhat.com> still seems to
> work for the virtio
Signed-off-by: Michael S. Tsirkin
---
drivers/vhost/net.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 1ac58d0..984242e 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -61,7 +61,8 @@ MODULE_PARM_DESC(experiment
len is always initialized since function is called with size > 0.
Signed-off-by: Michael S. Tsirkin
---
drivers/vhost/net.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 984242e..54ffbb0 100644
--- a/drivers/vhost/net.c
+++ b/
On 25/11/2014 17:35, Alexander Graf wrote:
> Unfortunately on ARM you also have a few other constraints - the debug
> register space is partitioned into magic super debug registers at the
> top (with an implementation specific amount) and normal debug registers
> in the lower end of the space.
D
Signed-off-by: Michael S. Tsirkin
---
drivers/vhost/net.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index cae22f9..1ac58d0 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -1027,7 +1027,8 @@ static int vhost_net_se
Signed-off-by: Michael S. Tsirkin
---
drivers/vhost/vhost.h | 33 -
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h
index 3eda654..b9032e8 100644
--- a/drivers/vhost/vhost.h
+++ b/drivers/vhost/vhost.h
@@
We use native endian-ness internally but never
expose it to guest.
Signed-off-by: Michael S. Tsirkin
---
drivers/vhost/net.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 8dae2f7..dce5c58 100644
--- a/drivers/vhost/
Signed-off-by: Michael S. Tsirkin
---
drivers/vhost/vhost.c | 93 +++
1 file changed, 56 insertions(+), 37 deletions(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index c90f437..4d379ed 100644
--- a/drivers/vhost/vhost.c
+++ b/drive
On 25/11/2014 17:10, Alex Bennée wrote:
> +/* Exit types which define why we did a debug exit */
> +#define KVM_DEBUG_EXIT_ERROR 0x0
> +#define KVM_DEBUG_EXIT_SINGLE_STEP 0x1
> +#define KVM_DEBUG_EXIT_SW_BKPT 0x2
> +#define KVM_DEBUG_EXIT_HW_BKPT 0x3
> +#defi
On 25 November 2014 at 17:05, Paolo Bonzini wrote:
> So there is no register that says "this breakpoint has triggered" or
> "this watchpoint has triggered"?
Nope. You take a debug exception; the syndrome register tells
you if it was a bp or a wp, and if it was a wp the fault address
register tell
On Tue, 25 Nov 2014 18:44:10 +0200
"Michael S. Tsirkin" wrote:
> On Tue, Nov 25, 2014 at 02:24:11PM +0100, Cornelia Huck wrote:
> > Hi,
> >
> > here's the next version of my virtio-1 qemu patchset. Using virtio-1
> > virtio-blk and virtio-net devices with a guest kernel built from
> > <141682978
We need to use bit 32 for virtio 1.0
Signed-off-by: Michael S. Tsirkin
---
drivers/vhost/vhost.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h
index b9032e8..1f321fd 100644
--- a/drivers/vhost/vhost.h
+++ b/drivers/vhost/vhost.h
Signed-off-by: Michael S. Tsirkin
---
drivers/vhost/net.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index dce5c58..cae22f9 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -416,7 +416,7 @@ static void ha
On 25/11/2014 18:13, Peter Maydell wrote:
> On 25 November 2014 at 17:05, Paolo Bonzini wrote:
>> > So there is no register that says "this breakpoint has triggered" or
>> > "this watchpoint has triggered"?
> Nope. You take a debug exception; the syndrome register tells
> you if it was a bp or a
The problem:
On -RT, an emulated LAPIC timer instances has the following path:
1) hard interrupt
2) ksoftirqd is scheduled
3) ksoftirqd wakes up vcpu thread
4) vcpu thread is scheduled
This extra context switch introduces unnecessary latency in the
LAPIC path for a KVM guest.
The solution:
All
Since lapic timer handler only wakes up a simple waitqueue,
it can be executed from hardirq context.
Reduces average cyclictest latency by 3us.
Signed-off-by: Marcelo Tosatti
---
arch/x86/kvm/lapic.c | 42 +++---
1 file changed, 39 insertions(+), 3 deletio
The problem:
On -RT, an emulated LAPIC timer instances has the following path:
1) hard interrupt
2) ksoftirqd is scheduled
3) ksoftirqd wakes up vcpu thread
4) vcpu thread is scheduled
This extra context switch introduces unnecessary latency in the
LAPIC path for a KVM guest.
The solution:
Al
These represent xsave-related capabilities of the processor, and KVM may
or may not support them.
Add feature bits so that they are considered by "-cpu ...,enforce", and use
the new feature work instead of calling kvm_arch_get_supported_cpuid.
Signed-off-by: Paolo Bonzini
---
target-i386/cpu.c
On 25/11/2014 18:21, Marcelo Tosatti wrote:
> +
> + if (r == HRTIMER_RESTART) {
> + do {
> + ret = hrtimer_start_expires(data, HRTIMER_MODE_ABS);
> + if (ret == -ETIME)
> + hrtimer_add_expires_ns(&ktimer->timer,
>
On Tue, 25 Nov 2014 14:24:18 +0100
Cornelia Huck wrote:
> Handle endianness conversion for virtio-1 virtqueues correctly.
>
> Note that dataplane now needs to be built per-target.
>
> Signed-off-by: Cornelia Huck
> ---
We still have the same error as in your previous post...
In file included
On Tue, 25 Nov 2014 18:55:56 +0100
Greg Kurz wrote:
> On Tue, 25 Nov 2014 14:24:18 +0100
> Cornelia Huck wrote:
>
> > Handle endianness conversion for virtio-1 virtqueues correctly.
> >
> > Note that dataplane now needs to be built per-target.
> >
> > Signed-off-by: Cornelia Huck
> > ---
>
On 11/24/2014 09:56 PM, Alex Williamson wrote:
> On Sun, 2014-11-23 at 19:35 +0100, Eric Auger wrote:
>> This patch introduces a new KVM_DEV_VFIO_DEVICE group.
>>
>> This is a new control channel which enables KVM to cooperate with
>> viable VFIO devices.
>>
>> Functions are introduced to check the
On Fri, Nov 21, 2014 at 03:46:55PM +0100, Paolo Bonzini wrote:
>
>
> On 20/11/2014 17:34, Nadav Amit wrote:
> > Fenghua,
> >
> > I got KVM (v3.17) crashing on a machine that supports XRSTORS - It appears
> > to get a #GP when it is trying to load the guest FPU.
> > One reason for the #GP is tha
On Tue, Nov 25, 2014 at 06:35:42PM +0100, Paolo Bonzini wrote:
> These represent xsave-related capabilities of the processor, and KVM may
> or may not support them.
>
> Add feature bits so that they are considered by "-cpu ...,enforce", and use
> the new feature work instead of calling kvm_arch_ge
On 11/25/2014 12:21 PM, Marcelo Tosatti wrote:
> The problem:
>
> On -RT, an emulated LAPIC timer instances has the following path:
>
> 1) hard interrupt
> 2) ksoftirqd is scheduled
> 3) ksoftirqd wakes up vcpu thread
> 4) vcpu thread is scheduled
>
> This extra context switch introduces unneces
On Tue, 2014-11-25 at 19:20 +0100, Eric Auger wrote:
> On 11/24/2014 09:56 PM, Alex Williamson wrote:
> > On Sun, 2014-11-23 at 19:35 +0100, Eric Auger wrote:
> >> This patch introduces a new KVM_DEV_VFIO_DEVICE group.
> >>
> >> This is a new control channel which enables KVM to cooperate with
> >>
On 2014-11-25 18:38, Paolo Bonzini wrote:
>
>
> On 25/11/2014 18:21, Marcelo Tosatti wrote:
>> +
>> +if (r == HRTIMER_RESTART) {
>> +do {
>> +ret = hrtimer_start_expires(data, HRTIMER_MODE_ABS);
>> +if (ret == -ETIME)
>> +
On 11/25/2014 01:57 PM, Rik van Riel wrote:
> On 11/25/2014 12:21 PM, Marcelo Tosatti wrote:
>> The problem:
>>
>> On -RT, an emulated LAPIC timer instances has the following path:
>>
>> 1) hard interrupt
>> 2) ksoftirqd is scheduled
>> 3) ksoftirqd wakes up vcpu thread
>> 4) vcpu thread is schedul
On 11/25/2014 12:21 PM, Marcelo Tosatti wrote:
> Since lapic timer handler only wakes up a simple waitqueue,
> it can be executed from hardirq context.
>
> Reduces average cyclictest latency by 3us.
Can this patch be merged in the KVM tree, and go
upstream via Paolo?
> Signed-off-by: Marcelo Tos
On Tue, Nov 25, 2014 at 01:57:37PM -0500, Rik van Riel wrote:
> On 11/25/2014 12:21 PM, Marcelo Tosatti wrote:
> > The problem:
> >
> > On -RT, an emulated LAPIC timer instances has the following path:
> >
> > 1) hard interrupt
> > 2) ksoftirqd is scheduled
> > 3) ksoftirqd wakes up vcpu thread
>
On Fri, Nov 21, 2014 at 11:05:45PM +, Peter Maydell wrote:
> If it's mapped and readable-but-not-writable then it should still
> fault on write accesses, though? These are cases we currently get
> SEGV for, anyway.
Yes then it'll work just fine.
> Ah, I guess we have a terminology difference.
On 25/11/2014 19:45, Eduardo Habkost wrote:
>> > +static const char *cpuid_xsave_feature_name[] = {
>> > +"xsaveopt", "xsavec", "xgetbv1", "xsaves",
> None of the above features introduce any new state that might need to be
> migrated, or will require other changes in QEMU to work, right?
>
On Tue, 25 Nov 2014, Rik van Riel wrote:
> On 11/25/2014 12:21 PM, Marcelo Tosatti wrote:
> > The problem:
> >
> > On -RT, an emulated LAPIC timer instances has the following path:
> >
> > 1) hard interrupt
> > 2) ksoftirqd is scheduled
> > 3) ksoftirqd wakes up vcpu thread
> > 4) vcpu thread is
On Tue, 25 Nov 2014, Rik van Riel wrote:
> On 11/25/2014 12:21 PM, Marcelo Tosatti wrote:
> > Since lapic timer handler only wakes up a simple waitqueue,
> > it can be executed from hardirq context.
> >
> > Reduces average cyclictest latency by 3us.
>
> Can this patch be merged in the KVM tree, a
On 11/25/2014 02:22 AM, Christoffer Dall wrote:
> Hi Mario,
>
> On Thu, Nov 13, 2014 at 05:57:41PM -0800, Mario Smarduch wrote:
>> Patch series adds support for ARMv7 and generic dirty page logging support.
>> As we try to move towards generic dirty page logging additional logic is
>> moved
>>
On 10/27/2014 02:02 PM, Konrad Rzeszutek Wilk wrote:
On Mon, Oct 27, 2014 at 01:38:20PM -0400, Waiman Long wrote:
My concern is that spin_unlock() can be called in many places, including
loadable kernel modules. Can the paravirt_patch_ident_32() function able to
patch all of them in reasonable
> -Original Message-
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Wednesday, November 26, 2014 12:10 AM
> To: Eric Auger
> Cc: Wu, Feng; pbonz...@redhat.com; g...@kernel.org; kvm@vger.kernel.org
> Subject: Re: [RFC PATCH v2 1/2] KVM: kvm-vfio: User API for VT-d
> Po
Hi all,
On Tue, Nov 25, 2014 at 04:50:06PM +0200, Nadav Amit wrote:
>
>> On Nov 25, 2014, at 16:17, Paolo Bonzini wrote:
>>
>>
>>
>> On 25/11/2014 15:05, Nadav Amit wrote:
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 373b0ab9a32e..ca26681455c2 100644
--- a/arch/x86/
> -Original Message-
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Wednesday, November 26, 2014 12:04 AM
> To: Wu, Feng
> Cc: pbonz...@redhat.com; g...@kernel.org; kvm@vger.kernel.org;
> eric.au...@linaro.org
> Subject: Re: [RFC PATCH v2 2/2] KVM: kvm-vfio: implement
Am 25.11.2014 um 17:04 schrieb David Hildenbrand:
> As some architectures (e.g. s390) can't disable preemption while
> entering/leaving the guest, they won't receive the yield in all situations.
>
> kvm_enter_guest() has to be called with preemption_disabled and will set
> PF_VCPU. After that poin
Am 25.11.2014 um 17:04 schrieb David Hildenbrand:
> Currently, we allow changing the PID of a VCPU. This PID is used to
> identify the thread to yield to if we want to yield to this specific
> VCPU.
>
> In practice (e.g. QEMU), the thread creating and executing the VCPU remains
> always the same.
94 matches
Mail list logo
