A question about "CONFIG_KVM_DEVICE_ASSIGNMENT" configuration

[Nan Xiao]

Hi all,

When building kernel, it prompts "CONFIG_KVM_DEVICE_ASSIGNMENT" is "deprecated".
But it is still used in kernel code. E.g.:
"kvm_vm_ioctl_check_extension" function:
{
...
#ifdef CONFIG_KVM_DEVICE_ASSIGNMENT
case KVM_CAP_ASSIGN_DEV_IRQ:
case KVM_CAP_PCI_2_3:
#endif
r = 1;
break;
   ...
#ifdef CONFIG_KVM_DEVICE_ASSIGNMENT
case KVM_CAP_IOMMU:
r = iommu_present(_bus_type);
break;
#endif
   ...
}

If not configure this option, the following code will execute failed:

ret = ioctl(dev, KVM_CHECK_EXTENSION, KVM_CAP_IOMMU);

So does it mean to use KVM assigned device feature, the
"CONFIG_KVM_DEVICE_ASSIGNMENT"
is not "deprecated"?

Thanks very much in advance!
Best Regards
Nan Xiao
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Qemu-devel] [PATCH v2 08/18] nvdimm: init backend memory mapping and config data area

[Igor Mammedov]

On Tue, 8 Sep 2015 21:38:17 +0800
Xiao Guangrong  wrote:

> 
> 
> On 09/07/2015 10:11 PM, Igor Mammedov wrote:
> > On Fri, 14 Aug 2015 22:52:01 +0800
> > Xiao Guangrong  wrote:
> >
> >> The parameter @file is used as backed memory for NVDIMM which is
> >> divided into two parts if @dataconfig is true:
> >> - first parts is (0, size - 128K], which is used as PMEM (Persistent
> >>Memory)
> >> - 128K at the end of the file, which is used as Config Data Area, it's
> >>used to store Label namespace data
> >>
> >> The @file supports both regular file and block device, of course we
> >> can assign any these two kinds of files for test and emulation, however,
> >> in the real word for performance reason, we usually used these files as
> >> NVDIMM backed file:
> >> - the regular file in the filesystem with DAX enabled created on NVDIMM
> >>device on host
> >> - the raw PMEM device on host, e,g /dev/pmem0
> >
> > A lot of code in this series could reuse what QEMU already
> > uses for implementing pc-dimm devices.
> >
> > here is common concepts that could be reused.
> >- on physical system both DIMM and NVDIMM devices use
> >  the same slots. We could share QEMU's '-m slots' option between
> >  both devices. An alternative to not sharing would be to introduce
> >  '-machine nvdimm_slots' option.
> >  And yes, we need to know number of NVDIMMs to describe
> >  them all in ACPI table (taking in amount future hotplug
> >  include in this possible NVDIMM devices)
> >  I'd go the same way as on real hardware on make them share the same 
> > slots.
> 
> I'd prefer sharing slots for pc-dimm and nvdimm, it's easier to reuse the
> logic of slot-assignment and plug/unplug.
> 
> >- they share the same physical address space and limits
> >  on how much memory system can handle. So I'd suggest sharing existing
> >  '-m maxmem' option and reuse hotplug_memory address space.
> 
> Sounds good to me.
> 
> >
> > Essentially what I'm suggesting is to inherit NVDIMM's implementation
> > from pc-dimm reusing all of its code/backends and
> > just override parts that do memory mapping into guest's address space to
> > accommodate NVDIMM's requirements.
> 
> Good idea!
> 
> We have to differentiate pc-dimm and nvdimm in the common code and nvdimm
> has different points with pc-dimm (for example, its has reserved-region, and
> need support live migration of label data). How about rename 'pc-nvdimm' to
> 'memory-device' and make it as a common device type, then build pc-dimm and
> nvdimm on top of it?
sound good, only I'd call it just 'dimm' as 'memory-device' is too broad.
Also I'd make base class abstract.

> 
> Something like:
> static TypeInfo memory_device_info = {
>  .name  = TYPE_MEM_DEV,
>  .parent= TYPE_DEVICE,
> };
> 
> static TypeInfo memory_device_info = {
> .name = TYPE_PC_DIMM,
> .parent = TYPE_MEM_DEV,
> };
> 
> static TypeInfo memory_device_info = {
> .name = TYPE_NVDIMM,
> .parent = TYPE_MEM_DEV,
> };
> 
> It also make CONIFG_NVDIMM and CONFIG_HOT_PLUG be independent.
> 
> >
> >>
> >> Signed-off-by: Xiao Guangrong 
> >> ---
> >>   hw/mem/nvdimm/pc-nvdimm.c  | 109 
> >> -
> >>   include/hw/mem/pc-nvdimm.h |   7 +++
> >>   2 files changed, 115 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/hw/mem/nvdimm/pc-nvdimm.c b/hw/mem/nvdimm/pc-nvdimm.c
> >> index 7a270a8..97710d1 100644
> >> --- a/hw/mem/nvdimm/pc-nvdimm.c
> >> +++ b/hw/mem/nvdimm/pc-nvdimm.c
> >> @@ -22,12 +22,20 @@
> >>* License along with this library; if not, see 
> >> 
> >>*/
> >>
> >> +#include 
> >> +#include 
> >> +#include 
> >> +
> >> +#include "exec/address-spaces.h"
> >>   #include "hw/mem/pc-nvdimm.h"
> >>
> >> -#define PAGE_SIZE  (1UL << 12)
> >> +#define PAGE_SIZE   (1UL << 12)
> >> +
> >> +#define MIN_CONFIG_DATA_SIZE(128 << 10)
> >>
> >>   static struct nvdimms_info {
> >>   ram_addr_t current_addr;
> >> +int device_index;
> >>   } nvdimms_info;
> >>
> >>   /* the address range [offset, ~0ULL) is reserved for NVDIMM. */
> >> @@ -37,6 +45,26 @@ void pc_nvdimm_reserve_range(ram_addr_t offset)
> >>   nvdimms_info.current_addr = offset;
> >>   }
> >>
> >> +static ram_addr_t reserved_range_push(uint64_t size)
> >> +{
> >> +uint64_t current;
> >> +
> >> +current = ROUND_UP(nvdimms_info.current_addr, PAGE_SIZE);
> >> +
> >> +/* do not have enough space? */
> >> +if (current + size < current) {
> >> +return 0;
> >> +}
> >> +
> >> +nvdimms_info.current_addr = current + size;
> >> +return current;
> >> +}
> > You can't use all memory above hotplug_memory area since
> > we have to tell guest where 64-bit PCI window starts,
> > and currently it should start at reserved-memory-end
> > (but it isn't due to a bug: I've just posted fix to 

Re: [PATCH] kvmtool Makefile: relax arm test

[Riku Voipio]

On 10 September 2015 at 13:30, Will Deacon  wrote:
> On Thu, Sep 10, 2015 at 06:45:59AM +0100, Riku Voipio wrote:
>> Ping?

> Applied and pushed, thanks.

thanks

> In future, it's best to Cc me if you want to make sure stuff doesn't
> get missed :)

I just followed the CONTRIBUTING section from the README, maybe it
needs to be appended with the CC hint?

Riku
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 0/3] KVM: Dynamic Halt-Polling

[Christian Borntraeger]

Am 10.09.2015 um 03:55 schrieb Wanpeng Li:
> On 9/9/15 9:39 PM, Christian Borntraeger wrote:
>> Am 03.09.2015 um 16:07 schrieb Wanpeng Li:
>>> v6 -> v7:
>>>   * explicit signal (set a bool)
>>>   * fix the tracepoint
>>>
>>> v5 -> v6:
>>>   * fix wait_ns and poll_ns
>>>
>>> v4 -> v5:
>>>   * set base case 10us and max poll time 500us
>>>   * handle short/long halt, idea from David, many thanks David
>>>
>>> v3 -> v4:
>>>   * bring back grow vcpu->halt_poll_ns when interrupt arrives and shrinks
>>> when idle VCPU is detected
>>>
>>> v2 -> v3:
>>>   * grow/shrink vcpu->halt_poll_ns by *halt_poll_ns_grow or 
>>> /halt_poll_ns_shrink
>>>   * drop the macros and hard coding the numbers in the param definitions
>>>   * update the comments "5-7 us"
>>>   * remove halt_poll_ns_max and use halt_poll_ns as the max halt_poll_ns 
>>> time,
>>> vcpu->halt_poll_ns start at zero
>>>   * drop the wrappers
>>>   * move the grow/shrink logic before "out:" w/ "if (waited)"
>>>
>>> v1 -> v2:
>>>   * change kvm_vcpu_block to read halt_poll_ns from the vcpu instead of
>>> the module parameter
>>>   * use the shrink/grow matrix which is suggested by David
>>>   * set halt_poll_ns_max to 2ms
>>>
>>> There is a downside of always-poll since poll is still happened for idle
>>> vCPUs which can waste cpu usage. This patchset add the ability to adjust
>>> halt_poll_ns dynamically, to grow halt_poll_ns when shot halt is detected,
>>> and to shrink halt_poll_ns when long halt is detected.
>>>
>>> There are two new kernel parameters for changing the halt_poll_ns:
>>> halt_poll_ns_grow and halt_poll_ns_shrink.
>>>
>>>  no-poll  always-polldynamic-poll
>>> ---
>>> Idle (nohz) vCPU %c0 0.15%0.3%0.2%
>>> Idle (250HZ) vCPU %c01.1% 4.6%~14%1.2%
>>> TCP_RR latency   34us 27us26.7us
>>>
>>> "Idle (X) vCPU %c0" is the percent of time the physical cpu spent in
>>> c0 over 60 seconds (each vCPU is pinned to a pCPU). (nohz) means the
>>> guest was tickless. (250HZ) means the guest was ticking at 250HZ.
>>>
>>> The big win is with ticking operating systems. Running the linux guest
>>> with nohz=off (and HZ=250), we save 3.4%~12.8% CPUs/second and get close
>>> to no-polling overhead levels by using the dynamic-poll. The savings
>>> should be even higher for higher frequency ticks.
>>>
>>> Wanpeng Li (3):
>>>KVM: make halt_poll_ns per-vCPU
>>>KVM: dynamic halt-polling
>>>KVM: trace kvm_halt_poll_ns grow/shrink
>>>
>>>   include/linux/kvm_host.h   |  1 +
>>>   include/trace/events/kvm.h | 30 +++
>>>   virt/kvm/kvm_main.c| 72 
>>> ++
>>>   3 files changed, 97 insertions(+), 6 deletions(-)
>>>
>> I get some nice improvements for uperf between 2 guests,
> 
> Good to hear that.
> 
>> but there is one "bug":
>> If there is already some polling ongoing, its impossible to disable the 
>> polling,
> 
> The polling will stop if long halt is detected, and there is no need to 
> manual tuning. Just like dynamise PLE window can detect false positive and 
> handle ple window suitably.


Yes, but as soon as somebody sets halt_poll_ns to 0, polling will never stop,
as grow and shrink are only handled if halt_poll_ns is !=0.

[...]
if (halt_poll_ns) {
if (block_ns <= vcpu->halt_poll_ns)
;
/* we had a long block, shrink polling */
else if (vcpu->halt_poll_ns && block_ns > halt_poll_ns)
shrink_halt_poll_ns(vcpu);
/* we had a short halt and our poll time is too small */
else if (vcpu->halt_poll_ns < halt_poll_ns &&
block_ns < halt_poll_ns)
grow_halt_poll_ns(vcpu);
}
[...]

so maybe just do something like
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 4662a88..48828d6 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -2012,6 +2012,8 @@ out:
else if (vcpu->halt_poll_ns < halt_poll_ns &&
block_ns < halt_poll_ns)
grow_halt_poll_ns(vcpu);
+   } else {
+   vcpu->halt_poll_ns = 0;
}
 
trace_kvm_vcpu_wakeup(block_ns, waited);


--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 3/4] irqchip: GIC: Convert to EOImode == 1

[Marc Zyngier]

Hi Julian,

On 09/09/15 20:23, Julien Grall wrote:
> Hi,
> 
> I've been trying the latest linus/master (a794b4f), which include this
> patch, as baremetal kernel on X-gene. This is failing on early boot
> without much log.
> 
> After bisecting the tree, I found the error coming from this patch.
> While this patch is valid, it made me remembered that X-Gene (at least
> the first version) as an odd GICv2.
> 
> The GICC is divided in 2 area of 4K, each one aligned at a 64KB address.
> This means that, the address of GICC_DIR won't be 0x1000 but 0x1.

Not really. I already mentioned that one a while ago:

http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/332249.html

The first page of GIC is aliased over the first 64kB, and the second 
page aliased over the second 64kB. So you get a consistent mapping if 
you use (base + 0xF000) to address GICC. Also, the DT that's in 
mainline is showing a 4kB CPU interface, which doesn't enable 
EOImode==1. You must be using a firmware that's newer than mine, since 
I'm perfectly able to boot my Mustang with these patches.

> We had the same issue on Xen when we did the first port of X-gene [1].
> Although, we choose to add a quirk in Xen for this platform in order to
> map contiguously in the virtual memory the 2 part of GICC.
> 
> Note that, back then, Ian suggested to extend the bindings to support a
> such platform [2]. AFAICT, there was no follow-up on it.

The main problem here is not to update the binding, but the fact that 
you *cannot* update the DT on x-gene (the firmware will replace your 
GIC node with what it thinks it is), and the APM guys can't be bothered 
to fix their stuff.

In the meantime, can you give the following patch a shot? My Mustang is 
wired to a 4kB CPU interface, so I'll need your help to test it.

Thanks,

M.

>From f0f086a4462198a5a2ac840901d9b8fd23b25134 Mon Sep 17 00:00:00 2001
From: Marc Zyngier 
Date: Thu, 10 Sep 2015 10:23:45 +0100
Subject: [PATCH] irqchip/GIC: Add workaround for aliased GIC400

The GICv2 architecture mandates that the two 4kB GIC regions are
contiguous, and on two separate physical pages. This doesn't work
very well when PAGE_SIZE is 64kB.

A relatively common hack to work around this is to alias each 4kB
region over its own 64kB page. Of course in this case, the base
address you want to use is not really the begining of the region,
but base + 60kB (so that you get a contiguous 8kB region over two
distinct pages).

Normally, this would be describe in DT with a new property, but
some HW is already out there, and the firmware makes sure that
it will override whatever you put in the GIC node. Duh. And of course,
said firmware source code is not available, despite being based
on u-boot.

The workaround is to detect the case where the CPU interface size
is set to 128kB, and verify the aliasing by checking that the ID
register for GIC400 (which is the only GIC wired this way so far)
is the same at base and base + 0xF000. In this case, we update
the GIC base address and let it roll.

And if you feel slightly sick by looking at this, rest assured that
I do too...

Reported-by: Julien Grall 
Signed-off-by: Marc Zyngier 
---
 drivers/irqchip/irq-gic.c | 45 -
 1 file changed, 40 insertions(+), 5 deletions(-)

diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index e6b7ed5..b62f2b2 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -1119,12 +1119,50 @@ void __init gic_init_bases(unsigned int gic_nr, int 
irq_start,
 #ifdef CONFIG_OF
 static int gic_cnt __initdata;
 
+static bool gic_check_eoimode(struct device_node *node, void __iomem **base)
+{
+   struct resource cpuif_res;
+
+   of_address_to_resource(node, 1, _res);
+
+   if (!is_hyp_mode_available())
+   return false;
+   if (resource_size(_res) < SZ_8K)
+   return false;
+   if (resource_size(_res) == SZ_128K) {
+   u32 val;
+
+   /*
+* Verify that we have a GIC400 aliased over the first
+* 64kB by checking the GICC_IIDR register.
+*/
+   val = readl_relaxed(*base + GIC_CPU_IDENT);
+   if (val != 0x0202043B)
+   return false;
+
+   val = readl_relaxed(*base + GIC_CPU_IDENT + 0xF000);
+   if (val != 0x0202043B)
+   return false;
+
+   /*
+* Move the base up by 60kB, so that we have a 8kB
+* contiguous region, which allows us to use GICC_DIR
+* at its normal offset.
+*/
+   *base += 0xF000;
+   cpuif_res.start += 0xF000;
+   pr_warn("GIC: Adjusting CPU interface base to %pa",
+   _res.start);
+   }
+
+   return true;
+}
+
 static int __init
 gic_of_init(struct 

[PATCH 2/4] vhost: move features to core

[Michael S. Tsirkin]

virtio 1 and any layout are core features, move them
there. This fixes vhost test.

Signed-off-by: Michael S. Tsirkin 
---
 drivers/vhost/vhost.h | 4 +++-
 drivers/vhost/net.c   | 3 +--
 drivers/vhost/scsi.c  | 4 +---
 drivers/vhost/test.c  | 3 +++
 4 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h
index ce6f6da..4772862 100644
--- a/drivers/vhost/vhost.h
+++ b/drivers/vhost/vhost.h
@@ -173,7 +173,9 @@ enum {
VHOST_FEATURES = (1ULL << VIRTIO_F_NOTIFY_ON_EMPTY) |
 (1ULL << VIRTIO_RING_F_INDIRECT_DESC) |
 (1ULL << VIRTIO_RING_F_EVENT_IDX) |
-(1ULL << VHOST_F_LOG_ALL),
+(1ULL << VHOST_F_LOG_ALL) |
+(1ULL << VIRTIO_F_ANY_LAYOUT) |
+(1ULL << VIRTIO_F_VERSION_1)
 };
 
 static inline bool vhost_has_feature(struct vhost_virtqueue *vq, int bit)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 7d137a4..fa68bc9 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -61,8 +61,7 @@ MODULE_PARM_DESC(experimental_zcopytx, "Enable Zero Copy TX;"
 enum {
VHOST_NET_FEATURES = VHOST_FEATURES |
 (1ULL << VHOST_NET_F_VIRTIO_NET_HDR) |
-(1ULL << VIRTIO_NET_F_MRG_RXBUF) |
-(1ULL << VIRTIO_F_VERSION_1),
+(1ULL << VIRTIO_NET_F_MRG_RXBUF);
 };
 
 enum {
diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
index dfcc02c..0321fc4 100644
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@ -166,9 +166,7 @@ enum {
 /* Note: can't set VIRTIO_F_VERSION_1 yet, since that implies ANY_LAYOUT. */
 enum {
VHOST_SCSI_FEATURES = VHOST_FEATURES | (1ULL << VIRTIO_SCSI_F_HOTPLUG) |
-  (1ULL << VIRTIO_SCSI_F_T10_PI) |
-  (1ULL << VIRTIO_F_ANY_LAYOUT) |
-  (1ULL << VIRTIO_F_VERSION_1)
+  (1ULL << VIRTIO_SCSI_F_T10_PI);
 };
 
 #define VHOST_SCSI_MAX_TARGET  256
diff --git a/drivers/vhost/test.c b/drivers/vhost/test.c
index d9c501e..f2882ac 100644
--- a/drivers/vhost/test.c
+++ b/drivers/vhost/test.c
@@ -277,10 +277,13 @@ static long vhost_test_ioctl(struct file *f, unsigned int 
ioctl,
return -EFAULT;
return 0;
case VHOST_SET_FEATURES:
+   printk(KERN_ERR "1\n");
if (copy_from_user(, featurep, sizeof features))
return -EFAULT;
+   printk(KERN_ERR "2\n");
if (features & ~VHOST_FEATURES)
return -EOPNOTSUPP;
+   printk(KERN_ERR "3\n");
return vhost_test_set_features(n, features);
case VHOST_RESET_OWNER:
return vhost_test_reset_owner(n);
-- 
MST

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Qemu-devel] [PATCH v2 06/18] pc: implement NVDIMM device abstract

[Igor Mammedov]

On Tue, 8 Sep 2015 22:03:01 +0800
Xiao Guangrong  wrote:

> 
> 
> On 09/07/2015 09:40 PM, Igor Mammedov wrote:
> > On Sun, 6 Sep 2015 14:07:21 +0800
> > Xiao Guangrong  wrote:
> >
> >>
> >>
> >> On 09/02/2015 07:31 PM, Igor Mammedov wrote:
> >>> On Wed, 2 Sep 2015 18:36:43 +0800
> >>> Xiao Guangrong  wrote:
> >>>
> 
> 
>  On 09/02/2015 05:58 PM, Igor Mammedov wrote:
> > On Fri, 14 Aug 2015 22:51:59 +0800
> > Xiao Guangrong  wrote:
> >
> >> Introduce "pc-nvdimm" device and it has two parameters:
> > Why do you use prefix "pc-", I suppose we potentially
> > could use this device not only with x86 targets but with
> > other targets as well.
> > I'd just drop 'pc' prefix through out patchset.
> 
>  Yeah, the prefix is stolen from pc-dimm, will drop this
>  prefix as your suggestion.
> 
> >
> >> - @file, which is the backed memory file for NVDIMM device
> > Could you try to split device into backend/frontend parts,
> > like it's done with pc-dimm. As I understand it's preferred
> > way to implement this kind of devices.
> > Then you could reuse memory backends that we already have
> > including file backend.
> 
>  I considered it too and Stefan, Paolo got the some idea in
>  V1's review, however:
> 
>  | However, file-based memory used by NVDIMM is special, it divides the 
>  file
>  | to two parts, one part is used as PMEM and another part is used to 
>  store
>  | NVDIMM's configure data.
>  |
>  | Maybe we can introduce "end-reserved" property to reserve specified 
>  size
>  | at the end of the file. Or create a new class type based on
>  | memory-backend-file (named nvdimm-backend-file) class to hide this 
>  magic
>  | thing?
> >>> I'd go with separate backend/frontend idea.
> >>>
> >>> Question is if this config area is part backend or frontend?
> >>
> >> Configdata area is used to store nvdimm device's configuration, normally, 
> >> it's
> >> namespace info.
> >>
> >> Currently, we chosen configdata located at the end of nvdimm's 
> >> backend-memory
> >> as it's easy to configure / use and configdata is naturally non-volatile 
> >> and it
> >> is like the layout on physical device.
> >>
> >> However, using two separated backed-memory is okay, for example:
> >> -object memory-backend-file,id=mem0,file=/storage/foo
> >> -object memory-backend-file,id=mem1,file=/storage/bar
> >> -device nvdimm,memdev=mem0,configdata=mem1
> >> then configdata is written to a single backend.
> >>
> >> Which one is better for you? :)
> >>
> >>> If we pass-through NVDIMM device do we need to set configdata=true
> >>> and QEMU would skip building config structures and use structures
> >>> that are already present on passed-through device in that place?
> >>>
> >>
> >> The file specified by @file is something like a normal disk, like 
> >> /dev/sda/,
> >> host process can use whole space on it. If we want to directly pass it to 
> >> guest,
> >> we can specify 'configdata=false'. If we allow guest to 'partition' (create
> >> namespace on) it then we use 'configdata=true' to reserve some space to 
> >> store
> >> its partition info (namesapce info).
> > As far as I understand currently linux provides to userspace only one 
> > interface
> > which is block device i.e. /dev/sdX and on top of it userspace can put
> > PM/DAX aware filesystem and use files from it. In either cases kernel
> > just provides access to separate namespaces and not to a whole NVDIMM which
> > includes 'labels area'. Hence /dev/sdX is not passed-though NVDIMM,
> > so we could consider it as just a file/storage that could be used by 
> > userspace.
> >
> 
> Yes, it is.
> 
> > Lets assume that NVDIMM should always have 'labels area'.
> > In that case I'd always reserve space for it and
> >   * format it (build a new one) if backend doesn't have a
> > valid labels area dropping configdata parameter along the way
On a second glance, qemu probably shouldn't 'format/build' labels
in this case and only supply non configured NVDIMM to guest.
It probably should be guest responsibility to configure namespaces
on bare NVDIMM. Also it would allow to seamlessly introduce separate labels
backend as described below to cover 'configdata = false' case.

> >   * or if backing-file already has valid labels area I'd just use it.
> 
> Yes.
> 
> >
> > If you need to make labels area readonly you can introduce 
> > 'NVDIMM.readonly_labels'
> > option and just use labels backend's without allowing changes writeback.
> > IT would be better to make it another series on top of basic NVDIMM 
> > implementation
> > if there is an actual usecase for it.
> 
> I'd prefer the way that discards not only its label data but also the whole 
> nvdimm device,
> that is, open(, RDONLY) + mmap(, MAP_PRIVATE), the idea 

Re: [PATCH] kvmtool Makefile: relax arm test

[Will Deacon]

On Thu, Sep 10, 2015 at 06:45:59AM +0100, Riku Voipio wrote:
> On 4 September 2015 at 14:06, Andre Przywara  wrote:
> > On 04/09/15 11:52, Riku Voipio wrote:
> >> On 4 September 2015 at 13:10, Andre Przywara  
> >> wrote:
> >>> On 03/09/15 12:20, riku.voi...@linaro.org wrote:
>  From: Riku Voipio 
> 
>  Currently Makefile accepts only armv7l.* When building kvmtool under 
>  32bit
>  personality on Aarch64 machines, uname -m reports "armv8l", so build 
>  fails.
>  We expect doing 32bit arm builds in Aarch64 to become standard the same 
>  way
>  people do i386 builds on x86_64 machines.
> 
>  Make the sed test a little more greedy so armv8l becomes acceptable.
> 
>  Signed-off-by: Riku Voipio 
> >>>
> >>> The patch looks OK to me, I just wonder how you do the actual build
> >>> within the linux32 environment?
> >>> Do you have an arm cross compiler installed and set CROSS_COMPILE? Or is
> >>> there a magic compiler (driver) which uses uname -m as well?
> >>> And what would be the difference to setting ARCH=arm as well? Just
> >>> convenience?
> >>
> >> It's just an arm32 chroot, with an native arm32 compiler. The chroot
> >> is on an arm64 machine since these tend to be much faster than arm32
> >> hardware.
> >
> > Oh right, a chroot, didn't think about the obvious ;-)
> > Also it applies to 64-bit kernels with 32-bit root filesystems, I think.
> > So:
> >
> > Acked-by: Andre Przywara 
> 
> Ping?

Applied and pushed, thanks.

In future, it's best to Cc me if you want to make sure stuff doesn't
get missed :)

Cheers,

Will
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: linux-next: Tree for Sep 10

[Christian Borntraeger]

Am 10.09.2015 um 06:02 schrieb Stephen Rothwell:
> Hi all,
> 
> Please do not add material for v4.4 until after v4.3-rc1 is out.
> 
[...]
> The kvm tree still had its build failure for which I reverted a commit.
[..]
> Merging kvm/linux-next (2cbd78244fb2 KVM: trace kvm_halt_poll_ns grow/shrink)
> CONFLICT (content): Merge conflict in arch/powerpc/kvm/book3s_hv.c
> $ git am -3 
> ../patches/0001-Revert-KVM-trace-kvm_halt_poll_ns-grow-shrink.patch
> Applying: Revert "KVM: trace kvm_halt_poll_ns grow/shrink"

Can you add
kvm@vger.kernel.org
for build failures of the kernel tree?

Thanks a lot

Christian

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[kvm-unit-tests PATCH 04/11] configure: emit HOST=$host to config.mak

[Andrew Jones]

From: Alex Bennée 

This is useful information for the run scripts to know, especially if
they want to drop to using TCG.

Signed-off-by: Alex Bennée 
Reviewed-by: Andrew Jones 
---
 configure | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configure b/configure
index b2ad32a3e3a52..078b70ce096a6 100755
--- a/configure
+++ b/configure
@@ -7,6 +7,7 @@ ld=ld
 objcopy=objcopy
 ar=ar
 arch=`uname -m | sed -e s/i.86/i386/ | sed -e 's/arm.*/arm/'`
+host=$arch
 cross_prefix=
 
 usage() {
@@ -122,6 +123,7 @@ ln -s $asm lib/asm
 cat < config.mak
 PREFIX=$prefix
 KERNELDIR=$(readlink -f $kerneldir)
+HOST=$host
 ARCH=$arch
 ARCH_NAME=$arch_name
 PROCESSOR=$processor
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[kvm-unit-tests PATCH 07/11] run_tests: probe for max-smp

[Andrew Jones]

KVM can be configured to only support a few vcpus. ARM and AArch64
currently have a default config of only 4. While it's nice to be
able to write tests that use the maximum recommended, nr-host-cpus,
we can't assume that nr-host-cpus == kvm-max-vcpus. This patch allows
one to put $MAX_SMP in the smp =  line of a unittests.cfg file.
That variable will then expand to the number of host cpus, or to the
maximum vcpus allowed by KVM.

[Inspired by a patch from Alex Bennée solving the same issue.]

Signed-off-by: Andrew Jones 
---
 arm/unittests.cfg   | 3 ++-
 run_tests.sh| 9 +
 scripts/mkstandalone.sh | 9 -
 x86/unittests.cfg   | 1 +
 4 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/arm/unittests.cfg b/arm/unittests.cfg
index 243c13301811b..5e26da1a8c1bc 100644
--- a/arm/unittests.cfg
+++ b/arm/unittests.cfg
@@ -2,6 +2,7 @@
 # [unittest_name]
 # file = foo.flat # Name of the flat file to be used
 # smp  = 2# Number of processors the VM will use during this test
+# # Use $MAX_SMP to use the maximum the host supports.
 # extra_params = -append  # Additional parameters used
 # arch = arm|arm64   # Only if test case is specific to one
 # groups = group1 group2 # Used to identify test cases with run_tests -g ...
@@ -34,6 +35,6 @@ groups = selftest
 # Test SMP support
 [selftest-smp]
 file = selftest.flat
-smp = `getconf _NPROCESSORS_CONF`
+smp = $MAX_SMP
 extra_params = -append 'smp'
 groups = selftest
diff --git a/run_tests.sh b/run_tests.sh
index b1b4c541ecaea..fad22a935b007 100755
--- a/run_tests.sh
+++ b/run_tests.sh
@@ -98,4 +98,13 @@ while getopts "g:hv" opt; do
 esac
 done
 
+#
+# Probe for MAX_SMP
+#
+MAX_SMP=$(getconf _NPROCESSORS_CONF)
+while ./$TEST_DIR-run _NO_FILE_4Uhere_ -smp $MAX_SMP \
+   |& grep -q 'exceeds max cpus'; do
+   ((--MAX_SMP))
+done
+
 for_each_unittest $config run
diff --git a/scripts/mkstandalone.sh b/scripts/mkstandalone.sh
index 0c39451e538c9..3ce244aff67b9 100755
--- a/scripts/mkstandalone.sh
+++ b/scripts/mkstandalone.sh
@@ -95,12 +95,19 @@ qemu="$qemu"
 if [ "\$QEMU" ]; then
qemu="\$QEMU"
 fi
+
+MAX_SMP="MAX_SMP"
 echo \$qemu $cmdline -smp $smp $opts
 
 cmdline="\`echo '$cmdline' | sed s%$kernel%_NO_FILE_4Uhere_%\`"
 if \$qemu \$cmdline 2>&1 | grep 'No accelerator found'; then
-ret=2
+   ret=2
 else
+   MAX_SMP=\`getconf _NPROCESSORS_CONF\`
+   while \$qemu \$cmdline -smp \$MAX_SMP 2>&1 | grep 'exceeds max cpus' > 
/dev/null; do
+   MAX_SMP=\`expr \$MAX_SMP - 1\`
+   done
+
cmdline="\`echo '$cmdline' | sed s%$kernel%\$bin%\`"
\$qemu \$cmdline -smp $smp $opts
ret=\$?
diff --git a/x86/unittests.cfg b/x86/unittests.cfg
index a38544f77c056..337cc19d3d19d 100644
--- a/x86/unittests.cfg
+++ b/x86/unittests.cfg
@@ -2,6 +2,7 @@
 # [unittest_name]
 # file = foo.flat # Name of the flat file to be used
 # smp = 2 # Number of processors the VM will use during this test
+# # Use $MAX_SMP to use the maximum the host supports.
 # extra_params = -cpu qemu64,+x2apic # Additional parameters used
 # arch = i386/x86_64 # Only if the test case works only on one of them
 # groups = group1 group2 # Used to identify test cases with run_tests -g ...
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[kvm-unit-tests PATCH 06/11] arm/run: use ACCEL to choose between kvm and tcg

[Andrew Jones]

Inspired by a patch by Alex Bennée. This version uses a new
unittests.cfg variable and includes support for DRYRUN.

Signed-off-by: Andrew Jones 
---
 arm/run | 43 +--
 arm/unittests.cfg   |  4 +++-
 run_tests.sh|  3 ++-
 scripts/functions.bash  |  8 ++--
 scripts/mkstandalone.sh | 15 +++
 5 files changed, 59 insertions(+), 14 deletions(-)

diff --git a/arm/run b/arm/run
index 8cc2fa2571967..4a648697d7fb5 100755
--- a/arm/run
+++ b/arm/run
@@ -7,6 +7,42 @@ fi
 source config.mak
 processor="$PROCESSOR"
 
+if [ -c /dev/kvm ]; then
+   if [ "$HOST" = "arm" ] && [ "$ARCH" = "arm" ]; then
+   kvm_available=yes
+   elif [ "$HOST" = "aarch64" ]; then
+   kvm_available=yes
+   fi
+fi
+
+if [ "$ACCEL" = "kvm" ] && [ "$kvm_available" != "yes" ] &&
+   [ "$DRYRUN" != "yes" ]; then
+   printf "skip $TESTNAME (kvm only)\n\n"
+   exit 2
+fi
+
+if [ -z "$ACCEL" ]; then
+   if [ "$DRYRUN" = "yes" ]; then
+   # Output kvm with tcg fallback for dryrun (when both are
+   # allowed), since the command line we output may get used
+   # elsewhere.
+   ACCEL="kvm:tcg"
+   elif [ "$kvm_available" = "yes" ]; then
+   ACCEL="kvm"
+   else
+   ACCEL="tcg"
+   fi
+fi
+
+if [ "$ARCH" = "arm64" ]; then
+   if [[ $ACCEL =~ kvm ]]; then
+   # arm64 must use '-cpu host' with kvm, and we can't use
+   # '-cpu host' with tcg, so we force kvm-only (no fallback)
+   ACCEL="kvm"
+   processor="host"
+   fi
+fi
+
 qemu="${QEMU:-qemu-system-$ARCH_NAME}"
 qpath=$(which $qemu 2>/dev/null)
 
@@ -33,15 +69,10 @@ if $qemu $M -chardev testdev,id=id -initrd . 2>&1 \
exit 2
 fi
 
-M='-machine virt,accel=kvm:tcg'
 chr_testdev='-device virtio-serial-device'
 chr_testdev+=' -device virtconsole,chardev=ctd -chardev testdev,id=ctd'
 
-# arm64 must use '-cpu host' with kvm
-if [ "$(arch)" = "aarch64" ] && [ "$ARCH" = "arm64" ] && [ -c /dev/kvm ]; then
-   processor="host"
-fi
-
+M+=",accel=$ACCEL"
 command="$qemu $M -cpu $processor $chr_testdev"
 command+=" -display none -serial stdio -kernel"
 echo $command "$@"
diff --git a/arm/unittests.cfg b/arm/unittests.cfg
index e068a0cdd9c1f..243c13301811b 100644
--- a/arm/unittests.cfg
+++ b/arm/unittests.cfg
@@ -3,8 +3,10 @@
 # file = foo.flat # Name of the flat file to be used
 # smp  = 2# Number of processors the VM will use during this test
 # extra_params = -append  # Additional parameters used
-# arch = arm/arm64   # Only if test case is specific to one
+# arch = arm|arm64   # Only if test case is specific to one
 # groups = group1 group2 # Used to identify test cases with run_tests -g ...
+# accel = kvm|tcg # Optionally specify if test must run with kvm or tcg.
+# # If not specified, then kvm will be used when available.
 
 #
 # Test that the configured number of processors (smp = ), and
diff --git a/run_tests.sh b/run_tests.sh
index 80b87823c3358..b1b4c541ecaea 100755
--- a/run_tests.sh
+++ b/run_tests.sh
@@ -20,6 +20,7 @@ function run()
 local opts="$5"
 local arch="$6"
 local check="$7"
+local accel="$8"
 
 if [ -z "$testname" ]; then
 return
@@ -46,7 +47,7 @@ function run()
 fi
 done
 
-cmdline="TESTNAME=$testname ./$TEST_DIR-run $kernel -smp $smp $opts"
+cmdline="TESTNAME=$testname ACCEL=$accel ./$TEST_DIR-run $kernel -smp $smp 
$opts"
 if [ $verbose != 0 ]; then
 echo $cmdline
 fi
diff --git a/scripts/functions.bash b/scripts/functions.bash
index 7ed5a517250bc..f13fe6f88f23d 100644
--- a/scripts/functions.bash
+++ b/scripts/functions.bash
@@ -10,12 +10,13 @@ function for_each_unittest()
local groups
local arch
local check
+   local accel
 
exec {fd}<"$unittests"
 
while read -u $fd line; do
if [[ "$line" =~ ^\[(.*)\]$ ]]; then
-   "$cmd" "$testname" "$groups" "$smp" "$kernel" "$opts" 
"$arch" "$check"
+   "$cmd" "$testname" "$groups" "$smp" "$kernel" "$opts" 
"$arch" "$check" "$accel"
testname=${BASH_REMATCH[1]}
smp=1
kernel=""
@@ -23,6 +24,7 @@ function for_each_unittest()
groups=""
arch=""
check=""
+   accel=""
elif [[ $line =~ ^file\ *=\ *(.*)$ ]]; then
kernel=$TEST_DIR/${BASH_REMATCH[1]}
elif [[ $line =~ ^smp\ *=\ *(.*)$ ]]; then
@@ -35,8 +37,10 @@ function for_each_unittest()
arch=${BASH_REMATCH[1]}
elif [[ $line =~ ^check\ *=\ *(.*)$ ]]; then
check=${BASH_REMATCH[1]}
+   elif 

[kvm-unit-tests PATCH 08/11] lib/printf: support the %u unsigned fmt field

[Andrew Jones]

From: Alex Bennée 

Signed-off-by: Alex Bennée 
Reviewed-by: Andrew Jones 
---
 lib/printf.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/lib/printf.c b/lib/printf.c
index 89308fb26b7d2..5d83605afe829 100644
--- a/lib/printf.c
+++ b/lib/printf.c
@@ -180,6 +180,19 @@ int vsnprintf(char *buf, int size, const char *fmt, 
va_list va)
break;
}
break;
+   case 'u':
+   switch (nlong) {
+   case 0:
+   print_unsigned(, va_arg(va, unsigned), 10, props);
+   break;
+   case 1:
+   print_unsigned(, va_arg(va, unsigned long), 10, props);
+   break;
+   default:
+   print_unsigned(, va_arg(va, unsigned long long), 10, props);
+   break;
+   }
+   break;
case 'x':
switch (nlong) {
case 0:
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[kvm-unit-tests PATCH 10/11] lib/arm: add flush_tlb_page mmu function

[Andrew Jones]

From: Alex Bennée 

This introduces a new flush_tlb_page function which does exactly what
you expect. It's going to be useful for the future TLB torture test.

Signed-off-by: Alex Bennée 
Reviewed-by: Andrew Jones 
---
 lib/arm/asm/mmu.h   | 11 +++
 lib/arm64/asm/mmu.h |  8 
 2 files changed, 19 insertions(+)

diff --git a/lib/arm/asm/mmu.h b/lib/arm/asm/mmu.h
index c1bd01c9ee1b9..2bb0cde820f8a 100644
--- a/lib/arm/asm/mmu.h
+++ b/lib/arm/asm/mmu.h
@@ -14,8 +14,11 @@
 #define PTE_AF PTE_EXT_AF
 #define PTE_WBWA   L_PTE_MT_WRITEALLOC
 
+/* See B3.18.7 TLB maintenance operations */
+
 static inline void local_flush_tlb_all(void)
 {
+   /* TLBIALL */
asm volatile("mcr p15, 0, %0, c8, c7, 0" :: "r" (0));
dsb();
isb();
@@ -27,6 +30,14 @@ static inline void flush_tlb_all(void)
local_flush_tlb_all();
 }
 
+static inline void flush_tlb_page(unsigned long vaddr)
+{
+   /* TLBIMVAA */
+   asm volatile("mcr p15, 0, %0, c8, c7, 3" :: "r" (vaddr));
+   dsb();
+   isb();
+}
+
 #include 
 
 #endif /* __ASMARM_MMU_H_ */
diff --git a/lib/arm64/asm/mmu.h b/lib/arm64/asm/mmu.h
index 18b4d6be18fae..3bc31c91c36f8 100644
--- a/lib/arm64/asm/mmu.h
+++ b/lib/arm64/asm/mmu.h
@@ -19,6 +19,14 @@ static inline void flush_tlb_all(void)
isb();
 }
 
+static inline void flush_tlb_page(unsigned long vaddr)
+{
+   unsigned long page = vaddr >> 12;
+   dsb(ishst);
+   asm("tlbi   vaae1is, %0" :: "r" (page));
+   dsb(ish);
+}
+
 #include 
 
 #endif /* __ASMARM64_MMU_H_ */
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[kvm-unit-tests PATCH 11/11] makefiles: use bash

[Andrew Jones]

Use bash in the makefiles, like we do in the scripts.

Signed-off-by: Andrew Jones 
---
 Makefile | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Makefile b/Makefile
index 0d5933474cd8c..3e60b4f8e4a57 100644
--- a/Makefile
+++ b/Makefile
@@ -1,4 +1,6 @@
 
+SHELL := /bin/bash
+
 ifeq ($(wildcard config.mak),)
 $(error run ./configure first. See ./configure -h)
 endif
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[kvm-unit-tests PATCH 05/11] run_tests: pass test name to run script

[Andrew Jones]

With this $TEST_DIR/run can output test specific error messages.

Signed-off-by: Andrew Jones 
---
 run_tests.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/run_tests.sh b/run_tests.sh
index ebb7e9fe6fdfc..80b87823c3358 100755
--- a/run_tests.sh
+++ b/run_tests.sh
@@ -46,7 +46,7 @@ function run()
 fi
 done
 
-cmdline="./$TEST_DIR-run $kernel -smp $smp $opts"
+cmdline="TESTNAME=$testname ./$TEST_DIR-run $kernel -smp $smp $opts"
 if [ $verbose != 0 ]; then
 echo $cmdline
 fi
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL] Second batch of KVM changes for 4.3

[Paolo Bonzini]

Linus,

The following changes since commit 4d283ec908e617fa28bcb06bce310206f0655d67:

  x86/kvm: Rename VMX's segment access rights defines (2015-08-15 00:47:13 
+0200)

are available in the git repository at:

  git://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus

for you to fetch changes up to ba60c41ae392b473a1897faa0b8739fcb8759d69:

  kvm: irqchip: fix memory leak (2015-09-08 11:16:41 +0200)


ARM:
- Full debug support for arm64
- Active state switching for timer interrupts
- Lazy FP/SIMD save/restore for arm64
- Generic ARMv8 target

PPC:
- Book3S: A few bug fixes
- Book3S: Allow micro-threading on POWER8

x86:
- Compiler warnings

Generic:
- Adaptive polling for guest halt


Alex Bennée (11):
  KVM: add comments for kvm_debug_exit_arch struct
  KVM: arm64: guest debug, define API headers
  KVM: arm: guest debug, add stub KVM_SET_GUEST_DEBUG ioctl
  KVM: arm: introduce kvm_arm_init/setup/clear_debug
  KVM: arm64: guest debug, add SW break point support
  KVM: arm64: guest debug, add support for single-step
  KVM: arm64: re-factor hyp.S debug register code
  KVM: arm64: introduce vcpu->arch.debug_ptr
  KVM: arm64: guest debug, HW assisted debug support
  KVM: arm64: enable KVM_CAP_SET_GUEST_DEBUG
  KVM: arm64: add trace points for guest_debug debug

Alexander Kuleshov (1):
  kvm: compile process_smi_save_seg_64() only for x86_64

Gautham R. Shenoy (2):
  KVM: PPC: Book3S HV: Fix race in starting secondary threads
  KVM: PPC: Book3S HV: Exit on H_DOORBELL if HOST_IPI is set

Greg Kurz (1):
  KVM: PPC: Book3S: Fix typo in top comment about locking

Marc Zyngier (10):
  arm/arm64: KVM: Fix ordering of timer/GIC on guest entry
  arm/arm64: KVM: Move vgic handling to a non-preemptible section
  KVM: arm/arm64: vgic: Convert struct vgic_lr to use bitfields
  KVM: arm/arm64: vgic: Allow HW irq to be encoded in LR
  KVM: arm/arm64: vgic: Relax vgic_can_sample_irq for edge IRQs
  KVM: arm/arm64: vgic: Allow dynamic mapping of physical/virtual interrupts
  KVM: arm/arm64: vgic: Allow HW interrupts to be queued to a guest
  KVM: arm/arm64: vgic: Add vgic_{get,set}_phys_irq_active
  KVM: arm/arm64: vgic: Prevent userspace injection of a mapped interrupt
  KVM: arm/arm64: timer: Allow the timer to control the active state

Mario Smarduch (2):
  arm64: KVM: Optimize arm64 skip 30-50% vfp/simd save/restore on exits
  arm: KVM: keep arm vfp/simd exit handling consistent with arm64

Paolo Bonzini (3):
  Merge tag 'kvm-arm-for-4.3' of git://git.kernel.org/.../kvmarm/kvmarm 
into kvm-queue
  Merge tag 'signed-kvm-ppc-next' of git://github.com/agraf/linux-2.6 into 
kvm-queue
  KVM: x86: avoid uninitialized variable warning

Paul Mackerras (7):
  KVM: PPC: Book3S HV: Make use of unused threads when running guests
  KVM: PPC: Book3S HV: Implement dynamic micro-threading on POWER8
  KVM: PPC: Book3S HV: Fix race in reading change bit when removing HPTE
  KVM: PPC: Book3S HV: Fix bug in dirty page tracking
  KVM: PPC: Book3S HV: Implement H_CLEAR_REF and H_CLEAR_MOD
  KVM: PPC: Book3S HV: Fix preempted vcore list locking
  KVM: PPC: Book3S HV: Fix preempted vcore stolen time calculation

Sam bobroff (1):
  KVM: PPC: Book3S: correct width in XER handling

Sudip Mukherjee (1):
  kvm: irqchip: fix memory leak

Suzuki K. Poulose (1):
  arm64/kvm: Add generic v8 KVM target

Thomas Huth (3):
  KVM: PPC: Remove PPC970 from KVM_BOOK3S_64_HV text in Kconfig
  KVM: PPC: Fix warnings from sparse
  KVM: PPC: Book3S: Fix size of the PSPB register

Tudor Laurentiu (2):
  KVM: PPC: fix suspicious use of conditional operator
  KVM: PPC: add missing pt_regs initialization

Valdis Kletnieks (1):
  Silence compiler warning in arch/x86/kvm/emulate.c

Vladimir Murzin (1):
  arm64: KVM: remove remaining reference to vgic_sr_vectors

Wanpeng Li (4):
  KVM: make halt_poll_ns per-vCPU
  KVM: dynamic halt-polling
  KVM: trace kvm_halt_poll_ns grow/shrink
  kvm: move new trace event outside #ifdef CONFIG_KVM_ASYNC_PF

 Documentation/virtual/kvm/api.txt |  15 +-
 arch/arm/include/asm/kvm_host.h   |   5 +
 arch/arm/kvm/arm.c|  36 +-
 arch/arm/kvm/guest.c  |   6 +
 arch/arm/kvm/interrupts.S |  14 +-
 arch/arm/kvm/reset.c  |   4 +-
 arch/arm64/include/asm/hw_breakpoint.h|  14 +
 arch/arm64/include/asm/kvm_arm.h  |   5 +-
 arch/arm64/include/asm/kvm_asm.h  |  26 +-
 arch/arm64/include/asm/kvm_host.h |  42 +-
 arch/arm64/include/uapi/asm/kvm.h |  37 +-
 arch/arm64/kernel/asm-offsets.c   |   9 +-
 arch/arm64/kernel/hw_breakpoint.c |  12 -
 arch/arm64/kvm/Makefile

[kvm-unit-tests RFC PATCH 2/2] Revert "arm/arm64: import include/uapi/linux/psci.h"

[Andrew Jones]

The previous patch allows us to "unimport" this header now.

This reverts commit 7bc9f5e757bfa5c5a520281640fcf47a14b3.

Signed-off-by: Andrew Jones 
---
 lib/arm/asm/uapi-psci.h   | 73 ---
 lib/arm64/asm/uapi-psci.h |  1 -
 2 files changed, 74 deletions(-)
 delete mode 100644 lib/arm/asm/uapi-psci.h
 delete mode 100644 lib/arm64/asm/uapi-psci.h

diff --git a/lib/arm/asm/uapi-psci.h b/lib/arm/asm/uapi-psci.h
deleted file mode 100644
index 5c6fada2b5105..0
--- a/lib/arm/asm/uapi-psci.h
+++ /dev/null
@@ -1,73 +0,0 @@
-#ifndef _ASMARM_UAPI_PSCI_H_
-#define _ASMARM_UAPI_PSCI_H_
-/*
- * From include/uapi/linux/psci.h
- */
-
-/* PSCI v0.2 interface */
-#define PSCI_0_2_FN_BASE   0x8400
-#define PSCI_0_2_FN(n) (PSCI_0_2_FN_BASE + (n))
-#define PSCI_0_2_64BIT 0x4000
-#define PSCI_0_2_FN64_BASE \
-   (PSCI_0_2_FN_BASE + PSCI_0_2_64BIT)
-#define PSCI_0_2_FN64(n)   (PSCI_0_2_FN64_BASE + (n))
-
-#define PSCI_0_2_FN_PSCI_VERSION   PSCI_0_2_FN(0)
-#define PSCI_0_2_FN_CPU_SUSPENDPSCI_0_2_FN(1)
-#define PSCI_0_2_FN_CPU_OFFPSCI_0_2_FN(2)
-#define PSCI_0_2_FN_CPU_ON PSCI_0_2_FN(3)
-#define PSCI_0_2_FN_AFFINITY_INFO  PSCI_0_2_FN(4)
-#define PSCI_0_2_FN_MIGRATEPSCI_0_2_FN(5)
-#define PSCI_0_2_FN_MIGRATE_INFO_TYPE  PSCI_0_2_FN(6)
-#define PSCI_0_2_FN_MIGRATE_INFO_UP_CPUPSCI_0_2_FN(7)
-#define PSCI_0_2_FN_SYSTEM_OFF PSCI_0_2_FN(8)
-#define PSCI_0_2_FN_SYSTEM_RESET   PSCI_0_2_FN(9)
-
-#define PSCI_0_2_FN64_CPU_SUSPEND  PSCI_0_2_FN64(1)
-#define PSCI_0_2_FN64_CPU_ON   PSCI_0_2_FN64(3)
-#define PSCI_0_2_FN64_AFFINITY_INFOPSCI_0_2_FN64(4)
-#define PSCI_0_2_FN64_MIGRATE  PSCI_0_2_FN64(5)
-#define PSCI_0_2_FN64_MIGRATE_INFO_UP_CPU  PSCI_0_2_FN64(7)
-
-/* PSCI v0.2 power state encoding for CPU_SUSPEND function */
-#define PSCI_0_2_POWER_STATE_ID_MASK   0x
-#define PSCI_0_2_POWER_STATE_ID_SHIFT  0
-#define PSCI_0_2_POWER_STATE_TYPE_SHIFT16
-#define PSCI_0_2_POWER_STATE_TYPE_MASK \
-   (0x1 << PSCI_0_2_POWER_STATE_TYPE_SHIFT)
-#define PSCI_0_2_POWER_STATE_AFFL_SHIFT24
-#define PSCI_0_2_POWER_STATE_AFFL_MASK \
-   (0x3 << PSCI_0_2_POWER_STATE_AFFL_SHIFT)
-
-/* PSCI v0.2 affinity level state returned by AFFINITY_INFO */
-#define PSCI_0_2_AFFINITY_LEVEL_ON 0
-#define PSCI_0_2_AFFINITY_LEVEL_OFF1
-#define PSCI_0_2_AFFINITY_LEVEL_ON_PENDING 2
-
-/* PSCI v0.2 multicore support in Trusted OS returned by MIGRATE_INFO_TYPE */
-#define PSCI_0_2_TOS_UP_MIGRATE0
-#define PSCI_0_2_TOS_UP_NO_MIGRATE 1
-#define PSCI_0_2_TOS_MP2
-
-/* PSCI version decoding (independent of PSCI version) */
-#define PSCI_VERSION_MAJOR_SHIFT   16
-#define PSCI_VERSION_MINOR_MASK\
-   ((1U << PSCI_VERSION_MAJOR_SHIFT) - 1)
-#define PSCI_VERSION_MAJOR_MASK~PSCI_VERSION_MINOR_MASK
-#define PSCI_VERSION_MAJOR(ver)\
-   (((ver) & PSCI_VERSION_MAJOR_MASK) >> PSCI_VERSION_MAJOR_SHIFT)
-#define PSCI_VERSION_MINOR(ver)\
-   ((ver) & PSCI_VERSION_MINOR_MASK)
-
-/* PSCI return values (inclusive of all PSCI versions) */
-#define PSCI_RET_SUCCESS   0
-#define PSCI_RET_NOT_SUPPORTED -1
-#define PSCI_RET_INVALID_PARAMS-2
-#define PSCI_RET_DENIED-3
-#define PSCI_RET_ALREADY_ON-4
-#define PSCI_RET_ON_PENDING-5
-#define PSCI_RET_INTERNAL_FAILURE  -6
-#define PSCI_RET_NOT_PRESENT   -7
-#define PSCI_RET_DISABLED  -8
-
-#endif /* _ASMARM_UAPI_PSCI_H_ */
diff --git a/lib/arm64/asm/uapi-psci.h b/lib/arm64/asm/uapi-psci.h
deleted file mode 100644
index 83d018f954e4c..0
--- a/lib/arm64/asm/uapi-psci.h
+++ /dev/null
@@ -1 +0,0 @@
-#include "../../arm/asm/uapi-psci.h"
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[kvm-unit-tests RFC PATCH 1/2] lib: link in linux kernel headers (uapi)

[Andrew Jones]

Rather than import uapi headers, e.g. lib/arm/asm/uapi-psci.h, just
include them. For cross compilation we'll need the headers explicitly
added to the include path, but doing -I /usr/include won't work, as
some of our local header names will collide with /usr/include names.
Even just doing -I /usr/include/linux would leave too many potential
name collisions. So we create a lib/linux link, and do *not*
add -I lib/linux. Doing it this way requires code to include the uapi
headers with , putting them in their own "linux"
namespace.

Signed-off-by: Andrew Jones 
---
 .gitignore |  1 +
 Makefile   |  4 ++--
 configure  |  9 +
 lib/arm/asm/page.h |  2 +-
 lib/arm/asm/psci.h |  2 +-
 lib/arm64/asm/page.h   |  2 +-
 lib/arm64/asm/psci.h   |  2 +-
 lib/asm-generic/page.h |  2 +-
 lib/const.h| 11 ---
 9 files changed, 17 insertions(+), 18 deletions(-)
 delete mode 100644 lib/const.h

diff --git a/.gitignore b/.gitignore
index 242fae475094c..48ae6293e7ed0 100644
--- a/.gitignore
+++ b/.gitignore
@@ -10,6 +10,7 @@ patches
 cscope.*
 *.swp
 /lib/asm
+/lib/linux
 /config.mak
 /*-run
 /test.log
diff --git a/Makefile b/Makefile
index 0d5933474cd8c..77f8863af706c 100644
--- a/Makefile
+++ b/Makefile
@@ -80,10 +80,10 @@ libfdt_clean:
$(LIBFDT_objdir)/.*.d
 
 distclean: clean libfdt_clean
-   $(RM) lib/asm config.mak $(TEST_DIR)-run test.log msr.out cscope.*
+   $(RM) lib/linux lib/asm config.mak $(TEST_DIR)-run test.log msr.out 
cscope.*
$(RM) -r tests
 
-cscope: common_dirs = lib lib/libfdt lib/asm lib/asm-generic
+cscope: common_dirs = lib lib/libfdt lib/linux lib/asm lib/asm-generic
 cscope:
$(RM) ./cscope.*
find -L $(TEST_DIR) lib/$(TEST_DIR) lib/$(ARCH) $(common_dirs) 
-maxdepth 1 \
diff --git a/configure b/configure
index b2ad32a3e3a52..88e17a49f2660 100755
--- a/configure
+++ b/configure
@@ -90,6 +90,15 @@ if [ -f $testdir/run ]; then
 ln -fs $testdir/run $testdir-run
 fi
 
+# link uapi/linux
+rm -f lib/linux
+if [ ! -d /usr/include/linux ]; then
+echo kernel-headers not installed, aborting...
+exit 1
+else
+ln -s /usr/include/linux lib/linux
+fi
+
 # check for dependent 32 bit libraries
 if [ "$arch" != "arm" ]; then
 cat << EOF > lib_test.c
diff --git a/lib/arm/asm/page.h b/lib/arm/asm/page.h
index 039e2ddfb8e0f..df76969964ed3 100644
--- a/lib/arm/asm/page.h
+++ b/lib/arm/asm/page.h
@@ -6,7 +6,7 @@
  * This work is licensed under the terms of the GNU LGPL, version 2.
  */
 
-#include 
+#include 
 
 #define PAGE_SHIFT 12
 #define PAGE_SIZE  (_AC(1,UL) << PAGE_SHIFT)
diff --git a/lib/arm/asm/psci.h b/lib/arm/asm/psci.h
index c5fe78184b5ac..11ac45028d787 100644
--- a/lib/arm/asm/psci.h
+++ b/lib/arm/asm/psci.h
@@ -1,7 +1,7 @@
 #ifndef _ASMARM_PSCI_H_
 #define _ASMARM_PSCI_H_
 #include 
-#include 
+#include 
 
 #define PSCI_INVOKE_ARG_TYPE   u32
 #define PSCI_FN_CPU_ON PSCI_0_2_FN_CPU_ON
diff --git a/lib/arm64/asm/page.h b/lib/arm64/asm/page.h
index 29ad1f1f720c4..3144e8efcc7ae 100644
--- a/lib/arm64/asm/page.h
+++ b/lib/arm64/asm/page.h
@@ -11,7 +11,7 @@
  * This work is licensed under the terms of the GNU LGPL, version 2.
  */
 
-#include 
+#include 
 
 #define PGTABLE_LEVELS 2
 #define VA_BITS42
diff --git a/lib/arm64/asm/psci.h b/lib/arm64/asm/psci.h
index 940d61d34c05d..0a7d7c854e2b3 100644
--- a/lib/arm64/asm/psci.h
+++ b/lib/arm64/asm/psci.h
@@ -1,7 +1,7 @@
 #ifndef _ASMARM64_PSCI_H_
 #define _ASMARM64_PSCI_H_
 #include 
-#include 
+#include 
 
 #define PSCI_INVOKE_ARG_TYPE   u64
 #define PSCI_FN_CPU_ON PSCI_0_2_FN64_CPU_ON
diff --git a/lib/asm-generic/page.h b/lib/asm-generic/page.h
index 66c72a62bb0f7..f872f6fa0dad2 100644
--- a/lib/asm-generic/page.h
+++ b/lib/asm-generic/page.h
@@ -9,7 +9,7 @@
  * This work is licensed under the terms of the GNU LGPL, version 2.
  */
 
-#include "const.h"
+#include 
 
 #define PAGE_SHIFT 12
 #define PAGE_SIZE  (_AC(1,UL) << PAGE_SHIFT)
diff --git a/lib/const.h b/lib/const.h
deleted file mode 100644
index 5cd94d7067541..0
--- a/lib/const.h
+++ /dev/null
@@ -1,11 +0,0 @@
-#ifndef _CONST_H_
-#define _CONST_H_
-#ifdef __ASSEMBLY__
-#define _AC(X,Y)   X
-#define _AT(T,X)   X
-#else
-#define __AC(X,Y)  (X##Y)
-#define _AC(X,Y)   __AC(X,Y)
-#define _AT(T,X)   ((T)(X))
-#endif
-#endif
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[kvm-unit-tests RFC PATCH 0/2] try another approach for uapi headers

[Andrew Jones]

Rather than import uapi headers, just include them. I've put an RFC on
this series because it will now require kernel headers to be installed on
the build machine. I'm guessing that's not a big problem, but before we
commit to it, it'd be good to hear opinions from others.

This change wouldn't be worth it just for psci.h, but we're looking at PCI
support now, and thus we'll also want pci.h (and pci_regs.h). Although
after pci.h I'm not sure what else we'll eventually want. If nothing, then
maybe importing pci.h is also the right thing to do?

Thanks,
drew

Andrew Jones (2):
  lib: link in linux kernel headers (uapi)
  Revert "arm/arm64: import include/uapi/linux/psci.h"

 .gitignore|  1 +
 Makefile  |  4 +--
 configure |  9 ++
 lib/arm/asm/page.h|  2 +-
 lib/arm/asm/psci.h|  2 +-
 lib/arm/asm/uapi-psci.h   | 73 ---
 lib/arm64/asm/page.h  |  2 +-
 lib/arm64/asm/psci.h  |  2 +-
 lib/arm64/asm/uapi-psci.h |  1 -
 lib/asm-generic/page.h|  2 +-
 lib/const.h   | 11 ---
 11 files changed, 17 insertions(+), 92 deletions(-)
 delete mode 100644 lib/arm/asm/uapi-psci.h
 delete mode 100644 lib/arm64/asm/uapi-psci.h
 delete mode 100644 lib/const.h

-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[kvm-unit-tests PATCH 00/11] RESEND staging branch

[Andrew Jones]

This series is just a reposting of the patches on

https://github.com/rhdrjones/kvm-unit-tests/commits/staging

I believe all patches have been posted before, well except 07/11.

Thanks,
drew

Alex Bennée (5):
  README: add some CONTRIBUTING notes
  configure: emit HOST=$host to config.mak
  lib/printf: support the %u unsigned fmt field
  lib: add isaac prng library from CCAN
  lib/arm: add flush_tlb_page mmu function

Andrew Jones (6):
  arm/arm64: uart0_init: check /chosen/stdout-path
  arm/arm64: allow building a single test
  run_tests: pass test name to run script
  arm/run: use ACCEL to choose between kvm and tcg
  run_tests: probe for max-smp
  makefiles: use bash

 Makefile |   2 +
 README   |  26 +++
 arm/run  |  43 ++--
 arm/unittests.cfg|   7 +-
 config/config-arm-common.mak |   7 ++
 configure|   2 +
 lib/arm/asm/mmu.h|  11 +++
 lib/arm/io.c |  36 +++---
 lib/arm64/asm/mmu.h  |   8 +++
 lib/printf.c |  13 
 lib/prng.c   | 162 +++
 lib/prng.h   |  82 ++
 run_tests.sh |  12 +++-
 scripts/functions.bash   |   8 ++-
 scripts/mkstandalone.sh  |  22 --
 x86/unittests.cfg|   1 +
 16 files changed, 418 insertions(+), 24 deletions(-)
 create mode 100644 lib/prng.c
 create mode 100644 lib/prng.h

-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[kvm-unit-tests PATCH 01/11] arm/arm64: uart0_init: check /chosen/stdout-path

[Andrew Jones]

Arguably all of uart0_init() is unnecessary, as we're pretty sure
that the address we initialize uart0_base to is correct. We go
through the motions of finding the uart anyway though, because it's
easy. It's also easy to check chosen/stdout-path first, so let's do
that too. But, just to make all this stuff a little less unnecessary,
let's add a warning when we do actually find an address that doesn't
match our initializer.

Signed-off-by: Andrew Jones 
---
 lib/arm/io.c | 36 +++-
 1 file changed, 27 insertions(+), 9 deletions(-)

diff --git a/lib/arm/io.c b/lib/arm/io.c
index 8b1501886736a..a08d394e4aa1c 100644
--- a/lib/arm/io.c
+++ b/lib/arm/io.c
@@ -19,12 +19,14 @@ extern void halt(int code);
 /*
  * Use this guess for the pl011 base in order to make an attempt at
  * having earlier printf support. We'll overwrite it with the real
- * base address that we read from the device tree later.
+ * base address that we read from the device tree later. This is
+ * the address we expect QEMU's mach-virt machine type to put in
+ * its generated device tree.
  */
-#define QEMU_MACH_VIRT_PL011_BASE 0x0900UL
+#define UART_EARLY_BASE 0x0900UL
 
 static struct spinlock uart_lock;
-static volatile u8 *uart0_base = (u8 *)QEMU_MACH_VIRT_PL011_BASE;
+static volatile u8 *uart0_base = (u8 *)UART_EARLY_BASE;
 
 static void uart0_init(void)
 {
@@ -32,16 +34,32 @@ static void uart0_init(void)
struct dt_pbus_reg base;
int ret;
 
-   ret = dt_pbus_get_base_compatible(compatible, );
-   assert(ret == 0 || ret == -FDT_ERR_NOTFOUND);
+   ret = dt_get_default_console_node();
+   assert(ret >= 0 || ret == -FDT_ERR_NOTFOUND);
 
-   if (ret) {
-   printf("%s: %s not found in the device tree, aborting...\n",
-   __func__, compatible);
-   abort();
+   if (ret == -FDT_ERR_NOTFOUND) {
+
+   ret = dt_pbus_get_base_compatible(compatible, );
+   assert(ret == 0 || ret == -FDT_ERR_NOTFOUND);
+
+   if (ret) {
+   printf("%s: %s not found in the device tree, "
+   "aborting...\n",
+   __func__, compatible);
+   abort();
+   }
+
+   } else {
+   assert(dt_pbus_translate_node(ret, 0, ) == 0);
}
 
uart0_base = ioremap(base.addr, base.size);
+
+   if (uart0_base != (u8 *)UART_EARLY_BASE) {
+   printf("WARNING: early print support may not work. "
+  "Found uart at %p, but early base is %p.\n",
+   uart0_base, (u8 *)UART_EARLY_BASE);
+   }
 }
 
 void io_init(void)
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[kvm-unit-tests PATCH 03/11] README: add some CONTRIBUTING notes

[Andrew Jones]

From: Alex Bennée 

Signed-off-by: Alex Bennée 
Reviewed-by: Andrew Jones 
---
 README | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/README b/README
index eab5ea28f7fab..0884aafa21d18 100644
--- a/README
+++ b/README
@@ -35,3 +35,29 @@ Directory structure:
 ./:  the sources of the tests and the created objects/images
 
 See /README for architecture specific documentation.
+
+CONTRIBUTING:
+=
+
+Style
+-
+
+Currently there is a mix of indentation styles so any changes to
+existing files should be consistent with the existing style. For new
+files:
+
+  - C: please use standard linux-with-tabs
+  - Shell: use TABs for indentation
+
+Patches
+---
+
+Patches are welcome at the KVM mailing list .
+
+Please prefix messages with: [kvm-unit-tests PATCH]
+
+You can add the following to .git/config to do this automatically for you:
+
+[format]
+   subjectprefix = kvm-unit-tests PATCH
+
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[kvm-unit-tests PATCH 02/11] arm/arm64: allow building a single test

[Andrew Jones]

This is mostly useful for building new tests that don't yet (and
may never) have entries in the makefiles (config-arm*.mak). Of course
it can be used to build tests that do have entries as well, in order
to avoid building all tests, if the plan is to run just the one.

Just do 'make TEST=some-test' to use it, where "some-test" matches
the name of the source file, i.e. arm/some-test.c

Signed-off-by: Andrew Jones 
---
 config/config-arm-common.mak | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/config/config-arm-common.mak b/config/config-arm-common.mak
index 698555d6a676f..937d408574751 100644
--- a/config/config-arm-common.mak
+++ b/config/config-arm-common.mak
@@ -13,6 +13,11 @@ tests-common = \
$(TEST_DIR)/selftest.flat \
$(TEST_DIR)/spinlock-test.flat
 
+ifneq ($(TEST),)
+   tests = $(TEST_DIR)/$(TEST).flat
+   tests-common =
+endif
+
 all: test_cases
 
 ##
@@ -68,5 +73,6 @@ generated_files = $(asm-offsets)
 
 test_cases: $(generated_files) $(tests-common) $(tests)
 
+$(TEST_DIR)/$(TEST).elf: $(cstart.o) $(TEST_DIR)/$(TEST).o
 $(TEST_DIR)/selftest.elf: $(cstart.o) $(TEST_DIR)/selftest.o
 $(TEST_DIR)/spinlock-test.elf: $(cstart.o) $(TEST_DIR)/spinlock-test.o
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 3/4] irqchip: GIC: Convert to EOImode == 1

[Marc Zyngier]

On 10/09/15 10:54, Marc Zyngier wrote:
> Hi Julian,
> 
> On 09/09/15 20:23, Julien Grall wrote:
>> Hi,
>>
>> I've been trying the latest linus/master (a794b4f), which include this
>> patch, as baremetal kernel on X-gene. This is failing on early boot
>> without much log.
>>
>> After bisecting the tree, I found the error coming from this patch.
>> While this patch is valid, it made me remembered that X-Gene (at least
>> the first version) as an odd GICv2.
>>
>> The GICC is divided in 2 area of 4K, each one aligned at a 64KB address.
>> This means that, the address of GICC_DIR won't be 0x1000 but 0x1.
> 
> Not really. I already mentioned that one a while ago:
> 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/332249.html
> 
> The first page of GIC is aliased over the first 64kB, and the second 
> page aliased over the second 64kB. So you get a consistent mapping if 
> you use (base + 0xF000) to address GICC. Also, the DT that's in 
> mainline is showing a 4kB CPU interface, which doesn't enable 
> EOImode==1. You must be using a firmware that's newer than mine, since 
> I'm perfectly able to boot my Mustang with these patches.
> 
>> We had the same issue on Xen when we did the first port of X-gene [1].
>> Although, we choose to add a quirk in Xen for this platform in order to
>> map contiguously in the virtual memory the 2 part of GICC.
>>
>> Note that, back then, Ian suggested to extend the bindings to support a
>> such platform [2]. AFAICT, there was no follow-up on it.
> 
> The main problem here is not to update the binding, but the fact that 
> you *cannot* update the DT on x-gene (the firmware will replace your 
> GIC node with what it thinks it is), and the APM guys can't be bothered 
> to fix their stuff.
> 
> In the meantime, can you give the following patch a shot? My Mustang is 
> wired to a 4kB CPU interface, so I'll need your help to test it.
> 
> Thanks,
> 
>   M.
> 
> From f0f086a4462198a5a2ac840901d9b8fd23b25134 Mon Sep 17 00:00:00 2001
> From: Marc Zyngier 
> Date: Thu, 10 Sep 2015 10:23:45 +0100
> Subject: [PATCH] irqchip/GIC: Add workaround for aliased GIC400
> 
> The GICv2 architecture mandates that the two 4kB GIC regions are
> contiguous, and on two separate physical pages. This doesn't work
> very well when PAGE_SIZE is 64kB.
> 
> A relatively common hack to work around this is to alias each 4kB
> region over its own 64kB page. Of course in this case, the base
> address you want to use is not really the begining of the region,
> but base + 60kB (so that you get a contiguous 8kB region over two
> distinct pages).
> 
> Normally, this would be describe in DT with a new property, but
> some HW is already out there, and the firmware makes sure that
> it will override whatever you put in the GIC node. Duh. And of course,
> said firmware source code is not available, despite being based
> on u-boot.
> 
> The workaround is to detect the case where the CPU interface size
> is set to 128kB, and verify the aliasing by checking that the ID
> register for GIC400 (which is the only GIC wired this way so far)
> is the same at base and base + 0xF000. In this case, we update
> the GIC base address and let it roll.
> 
> And if you feel slightly sick by looking at this, rest assured that
> I do too...
> 
> Reported-by: Julien Grall 
> Signed-off-by: Marc Zyngier 
> ---
>  drivers/irqchip/irq-gic.c | 45 -
>  1 file changed, 40 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
> index e6b7ed5..b62f2b2 100644
> --- a/drivers/irqchip/irq-gic.c
> +++ b/drivers/irqchip/irq-gic.c
> @@ -1119,12 +1119,50 @@ void __init gic_init_bases(unsigned int gic_nr, int 
> irq_start,
>  #ifdef CONFIG_OF
>  static int gic_cnt __initdata;
>  
> +static bool gic_check_eoimode(struct device_node *node, void __iomem **base)
> +{
> + struct resource cpuif_res;
> +
> + of_address_to_resource(node, 1, _res);
> +
> + if (!is_hyp_mode_available())
> + return false;
> + if (resource_size(_res) < SZ_8K)
> + return false;
> + if (resource_size(_res) == SZ_128K) {
> + u32 val;
> +
> + /*
> +  * Verify that we have a GIC400 aliased over the first
> +  * 64kB by checking the GICC_IIDR register.
> +  */
> + val = readl_relaxed(*base + GIC_CPU_IDENT);
> + if (val != 0x0202043B)
> + return false;
> +
> + val = readl_relaxed(*base + GIC_CPU_IDENT + 0xF000);
> + if (val != 0x0202043B)
> + return false;
> +
> + /*
> +  * Move the base up by 60kB, so that we have a 8kB
> +  * contiguous region, which allows us to use GICC_DIR
> +  * at its normal offset.
> +  */
> + *base += 0xF000;
> + 

Re: [PATCH 0/1] virtio/s390: one bugfix

[Michael S. Tsirkin]

On Thu, Sep 10, 2015 at 04:35:07PM +0200, Cornelia Huck wrote:
> Michael,
> 
> here's a bugfix for the virtio-ccw driver.
> 
> Question: How would you like to get patches? This one is formatted
> against your current linux-next branch; I can prepare a branch for
> you to pull from as well.

No need, patches are fine.

> Pierre Morel (1):
>   virtio/s390: handle failures of READ_VQ_CONF ccw
> 
>  drivers/s390/virtio/virtio_ccw.c | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> -- 
> 2.3.8
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH kvm-unit-tests] x86: ioapic: test TMR behavior

[Paolo Bonzini]

Test that TMR works right even if the virtual-APIC page is modified
by another processor.  Either x2apic or xapic accesses are tested,
depending on whether x2apic is available.

With current KVM, four out of eight tests fail, and there is no difference
in behavior between self-injection (done from root mode even with posted
interrupts) and actual posted interrupt injection where the receiving CPU
is in non-root mode).  With the proposed TMR patch all eight tests pass,
and again there is no difference in behavior between self-injection and
non-root mode posted interrupts.

Cc: Yang Zhang 
Cc: Jun Nakajima 
Cc: Steve Rutherford 
Signed-off-by: Paolo Bonzini 
---
 lib/x86/apic.c |   7 
 lib/x86/apic.h |   1 +
 x86/ioapic.c   | 114 -
 3 files changed, 121 insertions(+), 1 deletion(-)

diff --git a/lib/x86/apic.c b/lib/x86/apic.c
index 80b96d8..2ceba39 100644
--- a/lib/x86/apic.c
+++ b/lib/x86/apic.c
@@ -95,6 +95,13 @@ void apic_write(unsigned reg, u32 val)
 apic_ops->reg_write(reg, val);
 }
 
+bool apic_read_bit(unsigned reg, int n)
+{
+reg += (n >> 5) << 4;
+n &= 31;
+return (apic_read(reg) & (1 << n)) != 0;
+}
+
 void apic_icr_write(u32 val, u32 dest)
 {
 apic_ops->icr_write(val, dest);
diff --git a/lib/x86/apic.h b/lib/x86/apic.h
index 216b98d..2d0504c 100644
--- a/lib/x86/apic.h
+++ b/lib/x86/apic.h
@@ -31,6 +31,7 @@ void set_mask(unsigned line, int mask);
 
 void enable_apic(void);
 uint32_t apic_read(unsigned reg);
+bool apic_read_bit(unsigned reg, int n);
 void apic_write(unsigned reg, uint32_t val);
 void apic_icr_write(uint32_t val, uint32_t dest);
 uint32_t apic_id(void);
diff --git a/x86/ioapic.c b/x86/ioapic.c
index 1fe1ccc..a554e43 100644
--- a/x86/ioapic.c
+++ b/x86/ioapic.c
@@ -147,6 +147,101 @@ static void test_ioapic_simultaneous(void)
   g_66 && g_78 && g_66_after_78 && g_66_rip == g_78_rip);
 }
 
+static volatile int g_tmr_79 = -1;
+
+static void ioapic_isr_79(isr_regs_t *regs)
+{
+   g_tmr_79 = apic_read_bit(APIC_TMR, 0x79);
+   set_irq_line(0x0e, 0);
+   eoi();
+}
+
+static void test_ioapic_edge_tmr(bool expected_tmr_before)
+{
+   int tmr_before;
+
+   handle_irq(0x79, ioapic_isr_79);
+   set_ioapic_redir(0x0e, 0x79, EDGE_TRIGGERED);
+   tmr_before = apic_read_bit(APIC_TMR, 0x79);
+   toggle_irq_line(0x0e);
+   asm volatile ("nop");
+   report("TMR for ioapic edge interrupts (expected %s)",
+  tmr_before == expected_tmr_before && !g_tmr_79,
+  expected_tmr_before ? "true" : "false");
+}
+
+static void test_ioapic_level_tmr(bool expected_tmr_before)
+{
+   int tmr_before;
+
+   handle_irq(0x79, ioapic_isr_79);
+   set_ioapic_redir(0x0e, 0x79, LEVEL_TRIGGERED);
+   tmr_before = apic_read_bit(APIC_TMR, 0x79);
+   set_irq_line(0x0e, 1);
+   asm volatile ("nop");
+   report("TMR for ioapic level interrupts (expected %s)",
+  tmr_before == expected_tmr_before && g_tmr_79,
+  expected_tmr_before ? "true" : "false");
+}
+
+#define IPI_DELAY 100
+
+static void delay(int count)
+{
+   while(count--) asm("");
+}
+
+static void toggle_irq_line_0x0e(void *data)
+{
+   irq_disable();
+   delay(IPI_DELAY);
+   toggle_irq_line(0x0e);
+   irq_enable();
+}
+
+static void test_ioapic_edge_tmr_smp(bool expected_tmr_before)
+{
+   int tmr_before;
+   int i;
+
+   g_tmr_79 = -1;
+   handle_irq(0x79, ioapic_isr_79);
+   set_ioapic_redir(0x0e, 0x79, EDGE_TRIGGERED);
+   tmr_before = apic_read_bit(APIC_TMR, 0x79);
+   on_cpu_async(1, toggle_irq_line_0x0e, 0);
+   i = 0;
+   while(g_tmr_79 == -1) i++;
+   printf("%d iterations before interrupt received\n", i);
+   report("TMR for ioapic edge interrupts (expected %s)",
+  tmr_before == expected_tmr_before && !g_tmr_79,
+  expected_tmr_before ? "true" : "false");
+}
+
+static void set_irq_line_0x0e(void *data)
+{
+   irq_disable();
+   delay(IPI_DELAY);
+   set_irq_line(0x0e, 1);
+   irq_enable();
+}
+
+static void test_ioapic_level_tmr_smp(bool expected_tmr_before)
+{
+   int i, tmr_before;
+
+   g_tmr_79 = -1;
+   handle_irq(0x79, ioapic_isr_79);
+   set_ioapic_redir(0x0e, 0x79, LEVEL_TRIGGERED);
+   tmr_before = apic_read_bit(APIC_TMR, 0x79);
+   on_cpu_async(1, set_irq_line_0x0e, 0);
+   i = 0;
+   while(g_tmr_79 == -1) i++;
+   printf("%d iterations before interrupt received\n", i);
+   report("TMR for ioapic level interrupts (expected %s)",
+  tmr_before == expected_tmr_before && g_tmr_79,
+  expected_tmr_before ? "true" : "false");
+}
+
 static int g_isr_98;
 
 static void ioapic_isr_98(isr_regs_t *regs)
@@ -306,7 +401,11 @@ int main(void)
setup_idt();
 
mask_pic_interrupts();
- 

[PATCH 0/1] virtio/s390: one bugfix

[Cornelia Huck]

Michael,

here's a bugfix for the virtio-ccw driver.

Question: How would you like to get patches? This one is formatted
against your current linux-next branch; I can prepare a branch for
you to pull from as well.

Pierre Morel (1):
  virtio/s390: handle failures of READ_VQ_CONF ccw

 drivers/s390/virtio/virtio_ccw.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

-- 
2.3.8

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/1] virtio/s390: handle failures of READ_VQ_CONF ccw

[Cornelia Huck]

From: Pierre Morel 

In virtio_ccw_read_vq_conf() the return value of ccw_io_helper()
was not checked.
If the configuration could not be read properly, we'd wrongly assume a
queue size of 0.

Let's propagate any I/O error to virtio_ccw_setup_vq() so it may
properly fail.

Signed-off-by: Pierre Morel 
Signed-off-by: Cornelia Huck 
---
 drivers/s390/virtio/virtio_ccw.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/s390/virtio/virtio_ccw.c b/drivers/s390/virtio/virtio_ccw.c
index f8d8fdb..e9fae30 100644
--- a/drivers/s390/virtio/virtio_ccw.c
+++ b/drivers/s390/virtio/virtio_ccw.c
@@ -400,12 +400,16 @@ static bool virtio_ccw_kvm_notify(struct virtqueue *vq)
 static int virtio_ccw_read_vq_conf(struct virtio_ccw_device *vcdev,
   struct ccw1 *ccw, int index)
 {
+   int ret;
+
vcdev->config_block->index = index;
ccw->cmd_code = CCW_CMD_READ_VQ_CONF;
ccw->flags = 0;
ccw->count = sizeof(struct vq_config_block);
ccw->cda = (__u32)(unsigned long)(vcdev->config_block);
-   ccw_io_helper(vcdev, ccw, VIRTIO_CCW_DOING_READ_VQ_CONF);
+   ret = ccw_io_helper(vcdev, ccw, VIRTIO_CCW_DOING_READ_VQ_CONF);
+   if (ret)
+   return ret;
return vcdev->config_block->num;
 }
 
@@ -503,6 +507,10 @@ static struct virtqueue *virtio_ccw_setup_vq(struct 
virtio_device *vdev,
goto out_err;
}
info->num = virtio_ccw_read_vq_conf(vcdev, ccw, i);
+   if (info->num < 0) {
+   err = info->num;
+   goto out_err;
+   }
size = PAGE_ALIGN(vring_size(info->num, KVM_VIRTIO_CCW_RING_ALIGN));
info->queue = alloc_pages_exact(size, GFP_KERNEL | __GFP_ZERO);
if (info->queue == NULL) {
-- 
2.3.8

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: A question about "CONFIG_KVM_DEVICE_ASSIGNMENT" configuration

[Alex Williamson]

On Thu, 2015-09-10 at 18:22 +0800, Nan Xiao wrote:
> Hi all,
> 
> When building kernel, it prompts "CONFIG_KVM_DEVICE_ASSIGNMENT" is 
> "deprecated".
> But it is still used in kernel code. E.g.:
> "kvm_vm_ioctl_check_extension" function:
> {
> ...
> #ifdef CONFIG_KVM_DEVICE_ASSIGNMENT
> case KVM_CAP_ASSIGN_DEV_IRQ:
> case KVM_CAP_PCI_2_3:
> #endif
> r = 1;
> break;
>...
> #ifdef CONFIG_KVM_DEVICE_ASSIGNMENT
> case KVM_CAP_IOMMU:
> r = iommu_present(_bus_type);
> break;
> #endif
>...
> }
> 
> If not configure this option, the following code will execute failed:
> 
> ret = ioctl(dev, KVM_CHECK_EXTENSION, KVM_CAP_IOMMU);
> 
> So does it mean to use KVM assigned device feature, the
> "CONFIG_KVM_DEVICE_ASSIGNMENT"
> is not "deprecated"?

Legacy KVM device assignment is deprecated, it is fully replaced by
VFIO-based device assignment.  The intention is to deprecate legacy KVM
device assignment now, so all users can transition away from it and at
some point remove it from the kernel.  When using QEMU and libvirt, the
default is already to use VFIO instead of legacy KVM device assignment.
Thanks,

Alex



--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 3/4] irqchip: GIC: Convert to EOImode == 1

[Julien Grall]

On 10/09/15 10:54, Marc Zyngier wrote:
> Hi Julian,

Hi Marc,

> On 09/09/15 20:23, Julien Grall wrote:
>> Hi,
>>
>> I've been trying the latest linus/master (a794b4f), which include this
>> patch, as baremetal kernel on X-gene. This is failing on early boot
>> without much log.
>>
>> After bisecting the tree, I found the error coming from this patch.
>> While this patch is valid, it made me remembered that X-Gene (at least
>> the first version) as an odd GICv2.
>>
>> The GICC is divided in 2 area of 4K, each one aligned at a 64KB address.
>> This means that, the address of GICC_DIR won't be 0x1000 but 0x1.
> 
> Not really. I already mentioned that one a while ago:
> 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/332249.html

Sorry I haven't seen this thread on the ML.

> The first page of GIC is aliased over the first 64kB, and the second 
> page aliased over the second 64kB. So you get a consistent mapping if 
> you use (base + 0xF000) to address GICC. Also, the DT that's in 
> mainline is showing a 4kB CPU interface, which doesn't enable 
> EOImode==1.
> You must be using a firmware that's newer than mine, since 
> I'm perfectly able to boot my Mustang with these patches.

My U-boot firmware is:

U-Boot 2013.04-mustang_sw_1.15.12 (May 20 2015 - 10:03:33)

The interrupt controller node looks like:

interrupt-controller@7809 {
reg = <0x0 0x7809 0x0 0x1 0x0 0x780a 0x0
0x2 0x0 0x780c 0x0 0x1 0x0 0x780e 0x0 0x2>;
interrupts = <0x1 0x9 0xf04>;
compatible = "arm,cortex-a15-gic";
#interrupt-cells = <0x3>;
phandle = <0x1>;
interrupt-controller;
linux,phandle = <0x1>;
};

Note that we have a recent firmware which correct the GICD region to use
the non-secure one rather than the secure. See [1] for more details.

> 
>> We had the same issue on Xen when we did the first port of X-gene [1].
>> Although, we choose to add a quirk in Xen for this platform in order to
>> map contiguously in the virtual memory the 2 part of GICC.
>>
>> Note that, back then, Ian suggested to extend the bindings to support a
>> such platform [2]. AFAICT, there was no follow-up on it.
> 
> The main problem here is not to update the binding, but the fact that 
> you *cannot* update the DT on x-gene (the firmware will replace your 
> GIC node with what it thinks it is), and the APM guys can't be bothered 
> to fix their stuff.
> 
> In the meantime, can you give the following patch a shot? My Mustang is 
> wired to a 4kB CPU interface, so I'll need your help to test it.

I applied the two patches on top of linus/master and I'm able to boot
correctly on X-gene. Thank you!

Regards,

[1] http://lists.xen.org/archives/html/xen-devel/2015-04/msg02816.html

-- 
Julien Grall
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [kvm-unit-tests RFC PATCH 0/2] try another approach for uapi headers

[Paolo Bonzini]

On 10/09/2015 13:31, Andrew Jones wrote:
> Rather than import uapi headers, just include them. I've put an RFC on
> this series because it will now require kernel headers to be installed on
> the build machine. I'm guessing that's not a big problem, but before we
> commit to it, it'd be good to hear opinions from others.
> 
> This change wouldn't be worth it just for psci.h, but we're looking at PCI
> support now, and thus we'll also want pci.h (and pci_regs.h). Although
> after pci.h I'm not sure what else we'll eventually want. If nothing, then
> maybe importing pci.h is also the right thing to do?

Sounds good, and it's a tiny bit easier to go include->import than
import->include.

Paolo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 3/4] irqchip: GIC: Convert to EOImode == 1

[Marc Zyngier]

On 10/09/15 17:23, Julien Grall wrote:
> On 10/09/15 10:54, Marc Zyngier wrote:

[...]

>> In the meantime, can you give the following patch a shot? My Mustang is 
>> wired to a 4kB CPU interface, so I'll need your help to test it.
> 
> I applied the two patches on top of linus/master and I'm able to boot
> correctly on X-gene. Thank you!

Thanks for testing. Can I put your Tested-by tag on the patch when I
send it to Thomas?

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 3/4] irqchip: GIC: Convert to EOImode == 1

[Julien Grall]

On 10/09/15 17:30, Marc Zyngier wrote:
> On 10/09/15 17:23, Julien Grall wrote:
>> On 10/09/15 10:54, Marc Zyngier wrote:
> 
> [...]
> 
>>> In the meantime, can you give the following patch a shot? My Mustang is 
>>> wired to a 4kB CPU interface, so I'll need your help to test it.
>>
>> I applied the two patches on top of linus/master and I'm able to boot
>> correctly on X-gene. Thank you!
> 
> Thanks for testing. Can I put your Tested-by tag on the patch when I
> send it to Thomas?

Sure:

Tested-by: Julien Grall 

Regards,

-- 
Julien Grall
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: linux-next: Tree for Sep 10

[Stephen Rothwell]

Hi Christian,

[cc'ing the current contacts]

On Thu, 10 Sep 2015 10:05:01 +0200 Christian Borntraeger 
 wrote:
>
> Can you add
> kvm@vger.kernel.org
> for build failures of the kernel tree?

Done.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: A question about "CONFIG_KVM_DEVICE_ASSIGNMENT" configuration

[Nan Xiao]

Hi Alex,

Thanks very much for your response! so for assigning PCI device in QEMU.
The following method is deprecated:

qemu-system-x86_64 ... -device pci-assign,host=:21:00.1

I should use this one instead:

qemu-system-x86_64 ... -device vfio-pci,host=:21:00.1

right?

Thanks in advance!
Best Regards
Nan Xiao


On Thu, Sep 10, 2015 at 11:08 PM, Alex Williamson
 wrote:
> On Thu, 2015-09-10 at 18:22 +0800, Nan Xiao wrote:
>> Hi all,
>>
>> When building kernel, it prompts "CONFIG_KVM_DEVICE_ASSIGNMENT" is 
>> "deprecated".
>> But it is still used in kernel code. E.g.:
>> "kvm_vm_ioctl_check_extension" function:
>> {
>> ...
>> #ifdef CONFIG_KVM_DEVICE_ASSIGNMENT
>> case KVM_CAP_ASSIGN_DEV_IRQ:
>> case KVM_CAP_PCI_2_3:
>> #endif
>> r = 1;
>> break;
>>...
>> #ifdef CONFIG_KVM_DEVICE_ASSIGNMENT
>> case KVM_CAP_IOMMU:
>> r = iommu_present(_bus_type);
>> break;
>> #endif
>>...
>> }
>>
>> If not configure this option, the following code will execute failed:
>>
>> ret = ioctl(dev, KVM_CHECK_EXTENSION, KVM_CAP_IOMMU);
>>
>> So does it mean to use KVM assigned device feature, the
>> "CONFIG_KVM_DEVICE_ASSIGNMENT"
>> is not "deprecated"?
>
> Legacy KVM device assignment is deprecated, it is fully replaced by
> VFIO-based device assignment.  The intention is to deprecate legacy KVM
> device assignment now, so all users can transition away from it and at
> some point remove it from the kernel.  When using QEMU and libvirt, the
> default is already to use VFIO instead of legacy KVM device assignment.
> Thanks,
>
> Alex
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: A question about "CONFIG_KVM_DEVICE_ASSIGNMENT" configuration

[Chen, Tiejun]

On 9/10/2015 11:08 PM, Alex Williamson wrote:

On Thu, 2015-09-10 at 18:22 +0800, Nan Xiao wrote:

Hi all,

When building kernel, it prompts "CONFIG_KVM_DEVICE_ASSIGNMENT" is "deprecated".
But it is still used in kernel code. E.g.:
"kvm_vm_ioctl_check_extension" function:
{
...
#ifdef CONFIG_KVM_DEVICE_ASSIGNMENT
case KVM_CAP_ASSIGN_DEV_IRQ:
case KVM_CAP_PCI_2_3:
#endif
r = 1;
break;
   ...
#ifdef CONFIG_KVM_DEVICE_ASSIGNMENT
case KVM_CAP_IOMMU:
r = iommu_present(_bus_type);
break;
#endif
   ...
}

If not configure this option, the following code will execute failed:

ret = ioctl(dev, KVM_CHECK_EXTENSION, KVM_CAP_IOMMU);

So does it mean to use KVM assigned device feature, the
"CONFIG_KVM_DEVICE_ASSIGNMENT"
is not "deprecated"?


Legacy KVM device assignment is deprecated, it is fully replaced by


Why do we remove this legacy assignment completely? Its always leading 
to this confusion :)


Thanks
Tiejun


VFIO-based device assignment.  The intention is to deprecate legacy KVM
device assignment now, so all users can transition away from it and at
some point remove it from the kernel.  When using QEMU and libvirt, the
default is already to use VFIO instead of legacy KVM device assignment.
Thanks,

Alex

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: A question about "CONFIG_KVM_DEVICE_ASSIGNMENT" configuration

[Alex Williamson]

On Fri, 2015-09-11 at 07:58 +0800, Nan Xiao wrote:
> Hi Alex,
> 
> Thanks very much for your response! so for assigning PCI device in QEMU.
> The following method is deprecated:
> 
> qemu-system-x86_64 ... -device pci-assign,host=:21:00.1
> 
> I should use this one instead:
> 
> qemu-system-x86_64 ... -device vfio-pci,host=:21:00.1
> 
> right?

Yes, and the device needs to be bound to the vfio_pci driver in the host
rather than pci-stub (and you may or may not need to care about IOMMU
groups[1]).  Thanks,

Alex

[1] http://vfio.blogspot.com/2014/08/iommu-groups-inside-and-out.html

> On Thu, Sep 10, 2015 at 11:08 PM, Alex Williamson
>  wrote:
> > On Thu, 2015-09-10 at 18:22 +0800, Nan Xiao wrote:
> >> Hi all,
> >>
> >> When building kernel, it prompts "CONFIG_KVM_DEVICE_ASSIGNMENT" is 
> >> "deprecated".
> >> But it is still used in kernel code. E.g.:
> >> "kvm_vm_ioctl_check_extension" function:
> >> {
> >> ...
> >> #ifdef CONFIG_KVM_DEVICE_ASSIGNMENT
> >> case KVM_CAP_ASSIGN_DEV_IRQ:
> >> case KVM_CAP_PCI_2_3:
> >> #endif
> >> r = 1;
> >> break;
> >>...
> >> #ifdef CONFIG_KVM_DEVICE_ASSIGNMENT
> >> case KVM_CAP_IOMMU:
> >> r = iommu_present(_bus_type);
> >> break;
> >> #endif
> >>...
> >> }
> >>
> >> If not configure this option, the following code will execute failed:
> >>
> >> ret = ioctl(dev, KVM_CHECK_EXTENSION, KVM_CAP_IOMMU);
> >>
> >> So does it mean to use KVM assigned device feature, the
> >> "CONFIG_KVM_DEVICE_ASSIGNMENT"
> >> is not "deprecated"?
> >
> > Legacy KVM device assignment is deprecated, it is fully replaced by
> > VFIO-based device assignment.  The intention is to deprecate legacy KVM
> > device assignment now, so all users can transition away from it and at
> > some point remove it from the kernel.  When using QEMU and libvirt, the
> > default is already to use VFIO instead of legacy KVM device assignment.
> > Thanks,
> >
> > Alex
> >
> >
> >
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: A question about "CONFIG_KVM_DEVICE_ASSIGNMENT" configuration

[Nan Xiao]

Hi Alex,

Thanks very much for your time and answer!
Best Regards
Nan Xiao


On Fri, Sep 11, 2015 at 8:18 AM, Alex Williamson
 wrote:
> On Fri, 2015-09-11 at 07:58 +0800, Nan Xiao wrote:
>> Hi Alex,
>>
>> Thanks very much for your response! so for assigning PCI device in QEMU.
>> The following method is deprecated:
>>
>> qemu-system-x86_64 ... -device pci-assign,host=:21:00.1
>>
>> I should use this one instead:
>>
>> qemu-system-x86_64 ... -device vfio-pci,host=:21:00.1
>>
>> right?
>
> Yes, and the device needs to be bound to the vfio_pci driver in the host
> rather than pci-stub (and you may or may not need to care about IOMMU
> groups[1]).  Thanks,
>
> Alex
>
> [1] http://vfio.blogspot.com/2014/08/iommu-groups-inside-and-out.html
>
>> On Thu, Sep 10, 2015 at 11:08 PM, Alex Williamson
>>  wrote:
>> > On Thu, 2015-09-10 at 18:22 +0800, Nan Xiao wrote:
>> >> Hi all,
>> >>
>> >> When building kernel, it prompts "CONFIG_KVM_DEVICE_ASSIGNMENT" is 
>> >> "deprecated".
>> >> But it is still used in kernel code. E.g.:
>> >> "kvm_vm_ioctl_check_extension" function:
>> >> {
>> >> ...
>> >> #ifdef CONFIG_KVM_DEVICE_ASSIGNMENT
>> >> case KVM_CAP_ASSIGN_DEV_IRQ:
>> >> case KVM_CAP_PCI_2_3:
>> >> #endif
>> >> r = 1;
>> >> break;
>> >>...
>> >> #ifdef CONFIG_KVM_DEVICE_ASSIGNMENT
>> >> case KVM_CAP_IOMMU:
>> >> r = iommu_present(_bus_type);
>> >> break;
>> >> #endif
>> >>...
>> >> }
>> >>
>> >> If not configure this option, the following code will execute failed:
>> >>
>> >> ret = ioctl(dev, KVM_CHECK_EXTENSION, KVM_CAP_IOMMU);
>> >>
>> >> So does it mean to use KVM assigned device feature, the
>> >> "CONFIG_KVM_DEVICE_ASSIGNMENT"
>> >> is not "deprecated"?
>> >
>> > Legacy KVM device assignment is deprecated, it is fully replaced by
>> > VFIO-based device assignment.  The intention is to deprecate legacy KVM
>> > device assignment now, so all users can transition away from it and at
>> > some point remove it from the kernel.  When using QEMU and libvirt, the
>> > default is already to use VFIO instead of legacy KVM device assignment.
>> > Thanks,
>> >
>> > Alex
>> >
>> >
>> >
>> --
>> To unsubscribe from this list: send the line "unsubscribe kvm" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V4 3/4] kvm: fix zero length mmio searching

[Jason Wang]

Currently, if we had a zero length mmio eventfd assigned on
KVM_MMIO_BUS. It will never found by kvm_io_bus_cmp() since it always
compare the kvm_io_range() with the length that guest wrote. This will
lead e.g for vhost, kick will be trapped by qemu userspace instead of
vhost. Fixing this by using zero length if an iodevice is zero length.

Cc: Gleb Natapov 
Cc: Paolo Bonzini 
Signed-off-by: Jason Wang 
---
 virt/kvm/kvm_main.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index d8db2f8f..d4c3b66 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -3071,9 +3071,11 @@ static void kvm_io_bus_destroy(struct kvm_io_bus *bus)
 static inline int kvm_io_bus_cmp(const struct kvm_io_range *r1,
 const struct kvm_io_range *r2)
 {
+   int len = r2->len ? r1->len : 0;
+
if (r1->addr < r2->addr)
return -1;
-   if (r1->addr + r1->len > r2->addr + r2->len)
+   if (r1->addr + len > r2->addr + r2->len)
return 1;
return 0;
 }
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V4 4/4] kvm: add tracepoint for fast mmio

[Jason Wang]

Cc: Gleb Natapov 
Cc: Paolo Bonzini 
Signed-off-by: Jason Wang 
---
 arch/x86/kvm/trace.h | 18 ++
 arch/x86/kvm/vmx.c   |  1 +
 arch/x86/kvm/x86.c   |  1 +
 3 files changed, 20 insertions(+)

diff --git a/arch/x86/kvm/trace.h b/arch/x86/kvm/trace.h
index 4eae7c3..ce4abe3 100644
--- a/arch/x86/kvm/trace.h
+++ b/arch/x86/kvm/trace.h
@@ -129,6 +129,24 @@ TRACE_EVENT(kvm_pio,
 );
 
 /*
+ * Tracepoint for fast mmio.
+ */
+TRACE_EVENT(kvm_fast_mmio,
+   TP_PROTO(u64 gpa),
+   TP_ARGS(gpa),
+
+   TP_STRUCT__entry(
+   __field(u64,gpa)
+   ),
+
+   TP_fast_assign(
+   __entry->gpa= gpa;
+   ),
+
+   TP_printk("fast mmio at gpa 0x%llx", __entry->gpa)
+);
+
+/*
  * Tracepoint for cpuid.
  */
 TRACE_EVENT(kvm_cpuid,
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 4a4eec30..cb505b9 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -5767,6 +5767,7 @@ static int handle_ept_misconfig(struct kvm_vcpu *vcpu)
gpa = vmcs_read64(GUEST_PHYSICAL_ADDRESS);
if (!kvm_io_bus_write(vcpu, KVM_FAST_MMIO_BUS, gpa, 0, NULL)) {
skip_emulated_instruction(vcpu);
+   trace_kvm_fast_mmio(gpa);
return 1;
}
 
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 1e7e76e..f7c4042 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -8013,6 +8013,7 @@ bool kvm_arch_has_noncoherent_dma(struct kvm *kvm)
 EXPORT_SYMBOL_GPL(kvm_arch_has_noncoherent_dma);
 
 EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_exit);
+EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_fast_mmio);
 EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_inj_virq);
 EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_page_fault);
 EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_msr);
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V4 2/4] kvm: fix double free for fast mmio eventfd

[Jason Wang]

We register wildcard mmio eventfd on two buses, one for KVM_MMIO_BUS
and another is KVM_FAST_MMIO_BUS but with a single iodev
instance. This will lead an issue: kvm_io_bus_destroy() knows nothing
about the devices on two buses points to a single dev. Which will lead
double free[1] during exit. Fixing this by using allocate two
instances of iodevs then register one on KVM_MMIO_BUS and another on
KVM_FAST_MMIO_BUS.

CPU: 1 PID: 2894 Comm: qemu-system-x86 Not tainted 3.19.0-26-generic #28-Ubuntu
Hardware name: LENOVO 2356BG6/2356BG6, BIOS G7ET96WW (2.56 ) 09/12/2013
task: 88009ae0c4b0 ti: 88020e7f task.ti: 88020e7f
RIP: 0010:[]  [] 
ioeventfd_release+0x28/0x60 [kvm]
RSP: 0018:88020e7f3bc8  EFLAGS: 00010292
RAX: dead00200200 RBX: 8801ec19c900 RCX: 00018200016d
RDX: 8801ec19cf80 RSI: ea0008bf1d40 RDI: 8801ec19c900
RBP: 88020e7f3bd8 R08: 2fc75a01 R09: 00018200016d
R10: c07df6ae R11: 88022fc75a98 R12: 88021e7cc000
R13: 88021e7cca48 R14: 88021e7cca50 R15: 8801ec19c880
FS:  7fc1ee3e6700() GS:88023e24() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7f8f389d8000 CR3: 00023dc13000 CR4: 001427e0
Stack:
88021e7cc000  88020e7f3be8 c07e2622
88020e7f3c38 c07df69a 880232524160 88020e792d80
  880219b78c00 0008 8802321686a8
Call Trace:
[] ioeventfd_destructor+0x12/0x20 [kvm]
[] kvm_put_kvm+0xca/0x210 [kvm]
[] kvm_vcpu_release+0x18/0x20 [kvm]
[] __fput+0xe7/0x250
[] fput+0xe/0x10
[] task_work_run+0xd4/0xf0
[] do_exit+0x368/0xa50
[] ? recalc_sigpending+0x1f/0x60
[] do_group_exit+0x45/0xb0
[] get_signal+0x291/0x750
[] do_signal+0x28/0xab0
[] ? do_futex+0xdb/0x5d0
[] ? __wake_up_locked_key+0x18/0x20
[] ? SyS_futex+0x76/0x170
[] do_notify_resume+0x69/0xb0
[] int_signal+0x12/0x17
Code: 5d c3 90 0f 1f 44 00 00 55 48 89 e5 53 48 89 fb 48 83 ec 08 48 8b 7f 20 
e8 06 d6 a5 c0 48 8b 43 08 48 8b 13 48 89 df 48 89 42 08 <48> 89 10 48 b8 00 01 
10 00 00
 RIP  [] ioeventfd_release+0x28/0x60 [kvm]
 RSP 

Cc: Gleb Natapov 
Cc: Paolo Bonzini 
Cc: Michael S. Tsirkin 
Signed-off-by: Jason Wang 
---
 virt/kvm/eventfd.c | 111 -
 1 file changed, 59 insertions(+), 52 deletions(-)

diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
index 163258d..1a023ac 100644
--- a/virt/kvm/eventfd.c
+++ b/virt/kvm/eventfd.c
@@ -817,16 +817,6 @@ static int kvm_assign_ioeventfd_idx(struct kvm *kvm,
if (ret < 0)
goto unlock_fail;
 
-   /* When length is ignored, MMIO is also put on a separate bus, for
-* faster lookups.
-*/
-   if (!args->len && !(args->flags & KVM_IOEVENTFD_FLAG_PIO)) {
-   ret = kvm_io_bus_register_dev(kvm, KVM_FAST_MMIO_BUS,
- p->addr, 0, >dev);
-   if (ret < 0)
-   goto register_fail;
-   }
-
kvm->buses[bus_idx]->ioeventfd_count++;
list_add_tail(>list, >ioeventfds);
 
@@ -834,8 +824,6 @@ static int kvm_assign_ioeventfd_idx(struct kvm *kvm,
 
return 0;
 
-register_fail:
-   kvm_io_bus_unregister_dev(kvm, bus_idx, >dev);
 unlock_fail:
mutex_unlock(>slots_lock);
 
@@ -847,41 +835,6 @@ fail:
 }
 
 static int
-kvm_assign_ioeventfd(struct kvm *kvm, struct kvm_ioeventfd *args)
-{
-   enum kvm_bus  bus_idx;
-
-   bus_idx = ioeventfd_bus_from_flags(args->flags);
-   /* must be natural-word sized, or 0 to ignore length */
-   switch (args->len) {
-   case 0:
-   case 1:
-   case 2:
-   case 4:
-   case 8:
-   break;
-   default:
-   return -EINVAL;
-   }
-
-   /* check for range overflow */
-   if (args->addr + args->len < args->addr)
-   return -EINVAL;
-
-   /* check for extra flags that we don't understand */
-   if (args->flags & ~KVM_IOEVENTFD_VALID_FLAG_MASK)
-   return -EINVAL;
-
-   /* ioeventfd with no length can't be combined with DATAMATCH */
-   if (!args->len &&
-   args->flags & (KVM_IOEVENTFD_FLAG_PIO |
-  KVM_IOEVENTFD_FLAG_DATAMATCH))
-   return -EINVAL;
-
-   return kvm_assign_ioeventfd_idx(kvm, bus_idx, args);
-}
-
-static int
 kvm_deassign_ioeventfd_idx(struct kvm *kvm, enum kvm_bus bus_idx,
   struct kvm_ioeventfd *args)
 {
@@ -909,10 +862,6 @@ kvm_deassign_ioeventfd_idx(struct kvm *kvm, enum kvm_bus 
bus_idx,
continue;
 
kvm_io_bus_unregister_dev(kvm, bus_idx, >dev);
-   if (!p->length) {
-   kvm_io_bus_unregister_dev(kvm, KVM_FAST_MMIO_BUS,
- >dev);
-   }
 

[PATCH V4 1/4] kvm: factor out core eventfd assign/deassign logic

[Jason Wang]

This patch factors out core eventfd assign/deassign logic and leave
the argument checking and bus index selection to callers.

Cc: Gleb Natapov 
Cc: Paolo Bonzini 
Signed-off-by: Jason Wang 
---
 virt/kvm/eventfd.c | 83 --
 1 file changed, 49 insertions(+), 34 deletions(-)

diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
index 9ff4193..163258d 100644
--- a/virt/kvm/eventfd.c
+++ b/virt/kvm/eventfd.c
@@ -771,40 +771,14 @@ static enum kvm_bus ioeventfd_bus_from_flags(__u32 flags)
return KVM_MMIO_BUS;
 }
 
-static int
-kvm_assign_ioeventfd(struct kvm *kvm, struct kvm_ioeventfd *args)
+static int kvm_assign_ioeventfd_idx(struct kvm *kvm,
+   enum kvm_bus bus_idx,
+   struct kvm_ioeventfd *args)
 {
-   enum kvm_bus  bus_idx;
-   struct _ioeventfd*p;
-   struct eventfd_ctx   *eventfd;
-   int   ret;
-
-   bus_idx = ioeventfd_bus_from_flags(args->flags);
-   /* must be natural-word sized, or 0 to ignore length */
-   switch (args->len) {
-   case 0:
-   case 1:
-   case 2:
-   case 4:
-   case 8:
-   break;
-   default:
-   return -EINVAL;
-   }
 
-   /* check for range overflow */
-   if (args->addr + args->len < args->addr)
-   return -EINVAL;
-
-   /* check for extra flags that we don't understand */
-   if (args->flags & ~KVM_IOEVENTFD_VALID_FLAG_MASK)
-   return -EINVAL;
-
-   /* ioeventfd with no length can't be combined with DATAMATCH */
-   if (!args->len &&
-   args->flags & (KVM_IOEVENTFD_FLAG_PIO |
-  KVM_IOEVENTFD_FLAG_DATAMATCH))
-   return -EINVAL;
+   struct eventfd_ctx *eventfd;
+   struct _ioeventfd *p;
+   int ret;
 
eventfd = eventfd_ctx_fdget(args->fd);
if (IS_ERR(eventfd))
@@ -873,14 +847,48 @@ fail:
 }
 
 static int
-kvm_deassign_ioeventfd(struct kvm *kvm, struct kvm_ioeventfd *args)
+kvm_assign_ioeventfd(struct kvm *kvm, struct kvm_ioeventfd *args)
 {
enum kvm_bus  bus_idx;
+
+   bus_idx = ioeventfd_bus_from_flags(args->flags);
+   /* must be natural-word sized, or 0 to ignore length */
+   switch (args->len) {
+   case 0:
+   case 1:
+   case 2:
+   case 4:
+   case 8:
+   break;
+   default:
+   return -EINVAL;
+   }
+
+   /* check for range overflow */
+   if (args->addr + args->len < args->addr)
+   return -EINVAL;
+
+   /* check for extra flags that we don't understand */
+   if (args->flags & ~KVM_IOEVENTFD_VALID_FLAG_MASK)
+   return -EINVAL;
+
+   /* ioeventfd with no length can't be combined with DATAMATCH */
+   if (!args->len &&
+   args->flags & (KVM_IOEVENTFD_FLAG_PIO |
+  KVM_IOEVENTFD_FLAG_DATAMATCH))
+   return -EINVAL;
+
+   return kvm_assign_ioeventfd_idx(kvm, bus_idx, args);
+}
+
+static int
+kvm_deassign_ioeventfd_idx(struct kvm *kvm, enum kvm_bus bus_idx,
+  struct kvm_ioeventfd *args)
+{
struct _ioeventfd*p, *tmp;
struct eventfd_ctx   *eventfd;
int   ret = -ENOENT;
 
-   bus_idx = ioeventfd_bus_from_flags(args->flags);
eventfd = eventfd_ctx_fdget(args->fd);
if (IS_ERR(eventfd))
return PTR_ERR(eventfd);
@@ -918,6 +926,13 @@ kvm_deassign_ioeventfd(struct kvm *kvm, struct 
kvm_ioeventfd *args)
return ret;
 }
 
+static int kvm_deassign_ioeventfd(struct kvm *kvm, struct kvm_ioeventfd *args)
+{
+   enum kvm_bus bus_idx = ioeventfd_bus_from_flags(args->flags);
+
+   return kvm_deassign_ioeventfd_idx(kvm, bus_idx, args);
+}
+
 int
 kvm_ioeventfd(struct kvm *kvm, struct kvm_ioeventfd *args)
 {
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V4 0/4] Fast MMIO eventfd fixes

[Jason Wang]

Hi:

This series fixes two issues of fast mmio eventfd:

1) A single iodev instance were registerd on two buses: KVM_MMIO_BUS
   and KVM_FAST_MMIO_BUS. This will cause double in
   ioeventfd_destructor()
2) A zero length iodev on KVM_MMIO_BUS will never be found but
   kvm_io_bus_cmp(). This will lead e.g the eventfd will be trapped by
   qemu instead of host.

1 is fixed by allocating two instances of iodev. 2 is fixed by ignore
the actual length if the length of iodev is zero in kvm_io_bus_cmp().

Please review.

Changes from V3:

- Don't do search on two buses when trying to do write on
  KVM_MMIO_BUS. This fixes a small regression found by vmexit.flat.
- Since we don't do search on two buses, change kvm_io_bus_cmp() to
  let it can find zero length iodevs.
- Fix the unnecessary lines in tracepoint patch.

Changes from V2:
- Tweak styles and comment suggested by Cornelia.

Changes from v1:
- change ioeventfd_bus_from_flags() to return KVM_FAST_MMIO_BUS when
  needed to save lots of unnecessary changes.

Jason Wang (4):
  kvm: factor out core eventfd assign/deassign logic
  kvm: fix double free for fast mmio eventfd
  kvm: fix zero length mmio searching
  kvm: add tracepoint for fast mmio

 arch/x86/kvm/trace.h |  18 
 arch/x86/kvm/vmx.c   |   1 +
 arch/x86/kvm/x86.c   |   1 +
 virt/kvm/eventfd.c   | 124 ++-
 virt/kvm/kvm_main.c  |   4 +-
 5 files changed, 96 insertions(+), 52 deletions(-)

-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/4] vhost: move features to core

[Sergei Shtylyov]

Hello.

On 09/10/2015 10:23 AM, Michael S. Tsirkin wrote:


virtio 1 and any layout are core features, move them
there. This fixes vhost test.

Signed-off-by: Michael S. Tsirkin 


[...]

diff --git a/drivers/vhost/test.c b/drivers/vhost/test.c
index d9c501e..f2882ac 100644
--- a/drivers/vhost/test.c
+++ b/drivers/vhost/test.c
@@ -277,10 +277,13 @@ static long vhost_test_ioctl(struct file *f, unsigned int 
ioctl,
return -EFAULT;
return 0;
case VHOST_SET_FEATURES:
+   printk(KERN_ERR "1\n");
if (copy_from_user(, featurep, sizeof features))
return -EFAULT;
+   printk(KERN_ERR "2\n");
if (features & ~VHOST_FEATURES)
return -EOPNOTSUPP;
+   printk(KERN_ERR "3\n");
return vhost_test_set_features(n, features);
case VHOST_RESET_OWNER:
return vhost_test_reset_owner(n);


   Debugging printk's remained?

MBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html