Re: [Xen-devel] [PATCH 3/4] x86/passthrough: put the x86 folder under x86 maintainership

[Jan Beulich]

>>> On 04.01.19 at 11:33,  wrote:
> passthrough/x86 is tied to the x86 code, and as such put it under x86
> maintainership.

It is tied to both, so at the very least I object to ...

> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -257,6 +257,7 @@ F:xen/drivers/passthrough/
>  X:   xen/drivers/passthrough/amd/
>  X:   xen/drivers/passthrough/arm/
>  X:   xen/drivers/passthrough/vtd/
> +X:   xen/drivers/passthrough/x86/

... this; the Arm entry here is questionable too, imo.

> @@ -445,6 +446,7 @@ R:Roger Pau Monné 
>  S:   Supported
>  L:   xen-devel@lists.xenproject.org 
>  F:   xen/arch/x86/
> +F:   xen/drivers/passthrough/x86/

This one's debatable.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2 2/2] x86/dom0: add verbose mode and print memory allocation stats

[Jan Beulich]

>>> On 28.12.18 at 12:18,  wrote:
> --- a/xen/arch/x86/hvm/dom0_build.c
> +++ b/xen/arch/x86/hvm/dom0_build.c
> @@ -60,6 +60,18 @@ static struct acpi_madt_interrupt_override __initdata 
> *intsrcovr;
>  static unsigned int __initdata acpi_nmi_sources;
>  static struct acpi_madt_nmi_source __initdata *nmisrc;
>  
> +static unsigned int __initdata order_stats[MAX_ORDER + 1] = { };

Pointless initializer.

> +static void __init print_order_stats(void)
> +{
> +unsigned int i;
> +
> +printk("Memory allocation stats:\n");

I think this wants prefixing with "Dom0".

> +for ( i = 0; i < ARRAY_SIZE(order_stats); i++ )
> +if ( order_stats[i] )
> +printk("order: %2u allocations: %u\n", i, order_stats[i]);

Why the first of the two colons?

Jan



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v5 3/4] xen/x86: use SYMBOL when required

[Jan Beulich]

>>> On 03.01.19 at 20:19,  wrote:
> --- a/xen/arch/x86/alternative.c
> +++ b/xen/arch/x86/alternative.c
> @@ -194,7 +194,7 @@ void init_or_livepatch apply_alternatives(struct 
> alt_instr *start,
>   * So be careful if you want to change the scan order to any other
>   * order.
>   */
> -for ( a = base = start; a < end; a++ )
> +for ( a = base = start; (unsigned long)a < SYMBOL(end); a++ )

As said before, imo SYMBOL() should only eve be applied _directly_
to one of the (commonly linker script generated) symbols listed above,
never to any derivatives.

> @@ -1382,7 +1383,8 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>  }
>  #endif
>  
> -xen_virt_end = ((unsigned long)_end + (1UL << L2_PAGETABLE_SHIFT) - 1) &
> +xen_virt_end = (SYMBOL(_end) +
> +(1UL << L2_PAGETABLE_SHIFT) - 1) &
> ~((1UL << L2_PAGETABLE_SHIFT) - 1);

No need for the extra line split.

Jan



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] xen/build-id: Fix xen_build_id_check() to be robust against malformed notes

[Jan Beulich]

>>> On 02.01.19 at 11:43,  wrote:
> On Mon, Dec 31, 2018 at 05:34:25PM +, Andrew Cooper wrote:
>>  /* Sanity check, name should be "GNU" for ld-generated build-id. */
>> -if ( strncmp(ELFNOTE_NAME(n), "GNU", n->namesz) != 0 )
>> +if ( memcmp(ELFNOTE_NAME(n), "GNU", 4) != 0 )
> 
> OOI what is the advantage of memcmp compared to strncmp?

memcmp() generally is more performant than strncmp(), due to it not
needing to look for nul terminators.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] 4.10.1 Xen crash and reboot

[Patrick Beckmann]

Hi,

I just joined this list and am referring to
  https://lists.xenproject.org/archives/html/xen-devel/2018-12/msg00938.html

We have experienced several crashes of a recent Debian 9 Dom0 on new
hardware with Xen version "4.8.4+xsa273+shim4.10.1+xsa273-1+deb9u10".
After reporting it within Debian bug #912975
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912975) it was
pointed out, that this would be the same error, and I was asked to join
discussion here.

Unfortunately we are unable to reliably reproduce the behaviour.
Currently we are running the Dom0 with Xen version
"4.8.3+xsa267+shim4.10.1+xsa267-1+deb9u9" to test the assumption, that a
bug was introduced between these versions. We have not yet tried setting
pcid=0. Please let me know, if you think, that this would be a more
reasonable test for now.

Best Regards,
Patrick Beckmann
[SOL Session operational.  Use ~? for help]
[   99.992731] xen-blkback: backend/vbd/19/51712: prepare for reconnect

[  101.634684] xen-blkback: backend/vbd/20/51712: prepare for reconnect

[  103.653671] xen-blkback: backend/vbd/19/51712: using 4 queues, protocol 1 
(x86_64-abi) persistent grants

[  103.827314] vif vif-19-0 vif19.0: Guest Rx ready

[  103.827427] IPv6: ADDRCONF(NETDEV_CHANGE): vif19.0: link becomes ready

[  103.827534] br02: port 15(vif19.0) entered blocking state

[  103.827541] br02: port 15(vif19.0) entered forwarding state

[  104.476998] xen-blkback: backend/vbd/20/51712: using 4 queues, protocol 1 
(x86_64-abi) persistent grants

[  104.660889] vif vif-20-0 vif20.0: Guest Rx ready

[  104.661018] IPv6: ADDRCONF(NETDEV_CHANGE): vif20.0: link becomes ready

[  104.661168] br026: port 2(vif20.0) entered blocking state

[  104.661184] br026: port 2(vif20.0) entered forwarding state

(XEN) d8 L1TF-vulnerable L1e 01a23320 - Shadowing
(XEN) d8 L1TF-vulnerable L1e 01a23320 - Shadowing
(XEN) d8 L1TF-vulnerable L1e 01a23320 - Shadowing
(XEN) d11 L1TF-vulnerable L1e 020c3320 - Shadowing
(XEN) d13 L1TF-vulnerable L1e 01a3b320 - Shadowing
(XEN) d15 L1TF-vulnerable L1e 01a23320 - Shadowing



Debian GNU/Linux 9 caribou hvc0



caribou login: 


Debian GNU/Linux 9 caribou hvc0



caribou login: [ 4676.600094] br02: port 14(vif17.0) entered disabled state

[ 4676.744064] br02: port 14(vif17.0) entered disabled state

[ 4676.745573] device vif17.0 left promiscuous mode

[ 4676.745618] br02: port 14(vif17.0) entered disabled state

[ 4683.146619] br02: port 14(vif21.0) entered blocking state

[ 4683.146678] br02: port 14(vif21.0) entered disabled state

[ 4683.146921] device vif21.0 entered promiscuous mode

[ 4683.153997] IPv6: ADDRCONF(NETDEV_UP): vif21.0: link is not ready

[ 4683.639331] xen-blkback: backend/vbd/21/51712: using 1 queues, protocol 1 
(x86_64-abi) 

[ 4684.544484] xen-blkback: backend/vbd/21/51712: prepare for reconnect

[ 4684.938636] xen-blkback: backend/vbd/21/51712: using 1 queues, protocol 1 
(x86_64-abi) 

[ 4692.235692] xen-blkback: backend/vbd/21/51712: prepare for reconnect

[ 4694.917436] vif vif-21-0 vif21.0: Guest Rx ready

[ 4694.917800] IPv6: ADDRCONF(NETDEV_CHANGE): vif21.0: link becomes ready

[ 4694.917918] br02: port 14(vif21.0) entered blocking state

[ 4694.917926] br02: port 14(vif21.0) entered forwarding state

[ 4694.921344] xen-blkback: backend/vbd/21/51712: using 2 queues, protocol 1 
(x86_64-abi) persistent grants




Debian GNU/Linux 9 caribou hvc0



caribou login: (XEN) [ Xen-4.8.5-pre  x86_64  debug=n   Not tainted ]
(XEN) CPU:32
(XEN) RIP:e008:[] 
guest_4.o#sh_page_fault__guest_4+0x75d/0x1e30
(XEN) RFLAGS: 00010202   CONTEXT: hypervisor (d8v0)
(XEN) rax: 7fb5797e6580   rbx: 8310f4372000   rcx: 81c0e060
(XEN) rdx:    rsi: 8310f4372000   rdi: 0001fed5
(XEN) rbp: 8310f4372000   rsp: 8340250e7c78   r8:  0001fed5
(XEN) r9:     r10:    r11: 
(XEN) r12: 81c0e06ff6a8   r13: 0407fad6   r14: 830078da7000
(XEN) r15: 8340250e7ef8   cr0: 80050033   cr4: 00372660
(XEN) cr3: 00407ec02001   cr2: 81c0e06ff6a8
(XEN) fsb: 7fb58fc26700   gsb:    gss: 8801fea0
(XEN) ds:    es:    fs:    gs:    ss:    cs: e008
(XEN) Xen code around  
(guest_4.o#sh_page_fault__guest_4+0x75d/0x1e30):
(XEN)  ff ff 03 00 4e 8d 24 c1 <49> 8b 0c 24 f6 c1 01 0f 84 b6 06 00 00 48 c1 e1
(XEN) Xen stack trace from rsp=8340250e7c78:
(XEN)7fb5797e6580 027372df 82d080323600 8310f4372648
(XEN)8310f43726a8 027372df 8340250e7d50 8340250e7d98
(XEN)0007fb5797e6 0090 82d080323618 07f8
(XEN)06a8 0e58 0f30 82d0
(XEN)000d 00510002 01e6 8340250e7d20
(XEN)00e0  0277f512 830078da7000

Re: [Xen-devel] [PATCH v4 1/2] xen/blkback: add stack variable 'blkif' in connect_ring()

[Roger Pau Monné]

On Mon, Jan 07, 2019 at 01:35:58PM +0800, Dongli Zhang wrote:
> As 'be->blkif' is used for many times in connect_ring(), the stack variable
> 'blkif' is added to substitute 'be-blkif'.
> 
> Suggested-by: Paul Durrant 
> Signed-off-by: Dongli Zhang 

Reviewed-by: Roger Pau Monné 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v4 2/2] xen/blkback: rework connect_ring() to avoid inconsistent xenstore 'ring-page-order' set by malicious blkfront

[Dongli Zhang]

On 01/07/2019 08:01 PM, Roger Pau Monné wrote:
> On Mon, Jan 07, 2019 at 01:35:59PM +0800, Dongli Zhang wrote:
>> The xenstore 'ring-page-order' is used globally for each blkback queue and
>> therefore should be read from xenstore only once. However, it is obtained
>> in read_per_ring_refs() which might be called multiple times during the
>> initialization of each blkback queue.
>>
>> If the blkfront is malicious and the 'ring-page-order' is set in different
>> value by blkfront every time before blkback reads it, this may end up at
>> the "WARN_ON(i != (XEN_BLKIF_REQS_PER_PAGE * blkif->nr_ring_pages));" in
>> xen_blkif_disconnect() when frontend is destroyed.
>>
>> This patch reworks connect_ring() to read xenstore 'ring-page-order' only
>> once.
>>
>> Signed-off-by: Dongli Zhang 
>> ---
>> Changed since v1:
>>   * change the order of xenstore read in read_per_ring_refs
>>   * use xenbus_read_unsigned() in connect_ring()
>>
>> Changed since v2:
>>   * simplify the condition check as "(err != 1 && nr_grefs > 1)"
>>   * avoid setting err as -EINVAL to remove extra one line of code
>>
>> Changed since v3:
>>   * exit at the beginning if !nr_grefs
>>   * change the if statements to avoid test (err != 1) twice
>>   * initialize a 'blkif' stack variable (refer to PATCH 1/2)
>>
>>  drivers/block/xen-blkback/xenbus.c | 76 
>> +-
>>  1 file changed, 43 insertions(+), 33 deletions(-)
>>
>> diff --git a/drivers/block/xen-blkback/xenbus.c 
>> b/drivers/block/xen-blkback/xenbus.c
>> index a4aadac..a2acbc9 100644
>> --- a/drivers/block/xen-blkback/xenbus.c
>> +++ b/drivers/block/xen-blkback/xenbus.c
>> @@ -926,7 +926,7 @@ static int read_per_ring_refs(struct xen_blkif_ring 
>> *ring, const char *dir)
>>  int err, i, j;
>>  struct xen_blkif *blkif = ring->blkif;
>>  struct xenbus_device *dev = blkif->be->dev;
>> -unsigned int ring_page_order, nr_grefs, evtchn;
>> +unsigned int nr_grefs, evtchn;
>>  
>>  err = xenbus_scanf(XBT_NIL, dir, "event-channel", "%u",
>>);
>> @@ -936,43 +936,38 @@ static int read_per_ring_refs(struct xen_blkif_ring 
>> *ring, const char *dir)
>>  return err;
>>  }
>>  
>> -err = xenbus_scanf(XBT_NIL, dev->otherend, "ring-page-order", "%u",
>> -  _page_order);
>> -if (err != 1) {
>> -err = xenbus_scanf(XBT_NIL, dir, "ring-ref", "%u", 
>> _ref[0]);
>> +nr_grefs = blkif->nr_ring_pages;
>> +
>> +if (unlikely(!nr_grefs))
>> +return -EINVAL;
> 
> Is this even possible? AFAICT read_per_ring_refs will always be called
> with blkif->nr_ring_pages != 0?
> 
> If so, I would consider turning this into a BUG_ON/WARN_ON.

It used to be "WARN_ON(!nr_grefs);" in the v3 of the patch.

I would turn it into WARN_ON if it is fine with both Paul and you.

I prefer WARN_ON because it would remind the developers in the future that
read_per_ring_refs() should be used only when blkif->nr_ring_pages != 0.

> 
>> +
>> +for (i = 0; i < nr_grefs; i++) {
>> +char ring_ref_name[RINGREF_NAME_LEN];
>> +
>> +snprintf(ring_ref_name, RINGREF_NAME_LEN, "ring-ref%u", i);
>> +err = xenbus_scanf(XBT_NIL, dir, ring_ref_name,
>> +   "%u", _ref[i]);
>> +
>>  if (err != 1) {
>> -err = -EINVAL;
>> -xenbus_dev_fatal(dev, err, "reading %s/ring-ref", dir);
>> -return err;
>> -}
>> -nr_grefs = 1;
>> -} else {
>> -unsigned int i;
>> -
>> -if (ring_page_order > xen_blkif_max_ring_order) {
>> -err = -EINVAL;
>> -xenbus_dev_fatal(dev, err, "%s/request %d ring page 
>> order exceed max:%d",
>> - dir, ring_page_order,
>> - xen_blkif_max_ring_order);
>> -return err;
>> +if (nr_grefs == 1)
>> +break;
>> +
> 
> You need to either set err to EINVAL before calling xenbus_dev_fatal,
> or call xenbus_dev_fatal with EINVAL as the second parameter.
> 
>> +xenbus_dev_fatal(dev, err, "reading %s/%s",
>> + dir, ring_ref_name);
>> +return -EINVAL;
>>  }
>> +}
>>  
>> -nr_grefs = 1 << ring_page_order;
>> -for (i = 0; i < nr_grefs; i++) {
>> -char ring_ref_name[RINGREF_NAME_LEN];
>> -
>> -snprintf(ring_ref_name, RINGREF_NAME_LEN, "ring-ref%u", 
>> i);
>> -err = xenbus_scanf(XBT_NIL, dir, ring_ref_name,
>> -   "%u", _ref[i]);
>> -if (err != 1) {
>> -err = -EINVAL;
>> -xenbus_dev_fatal(dev, err, "reading %s/%s",
>> - 

[Xen-devel] [PATCH v8 02/18] xen: introduce new 'XenBus' and 'XenDevice' object hierarchy

[Paul Durrant]

This patch adds the basic boilerplate for a 'XenBus' object that will act
as a parent to 'XenDevice' PV backends.
A new 'XenBridge' object is also added to connect XenBus to the system bus.

The XenBus object is instantiated by a new xen_bus_init() function called
from the same sites as the legacy xen_be_init() function.

Subsequent patches will flesh-out the functionality of these objects.

Signed-off-by: Paul Durrant 
Reviewed-by: Anthony Perard 
---
Cc: Stefano Stabellini 
Cc: "Michael S. Tsirkin" 
Cc: Marcel Apfelbaum 
Cc: Paolo Bonzini 
Cc: Richard Henderson 
Cc: Eduardo Habkost 

v3:
 - Don't use local_err unless it is needed

v2:
 - Fix boilerplate
 - Make xen-bus hotplug capable
---
 hw/i386/xen/xen-hvm.c |   3 +
 hw/xen/Makefile.objs  |   2 +-
 hw/xen/trace-events   |   6 ++
 hw/xen/xen-bus.c  | 127 ++
 hw/xenpv/xen_machine_pv.c |   3 +
 include/hw/xen/xen-bus.h  |  55 +
 6 files changed, 195 insertions(+), 1 deletion(-)
 create mode 100644 hw/xen/xen-bus.c
 create mode 100644 include/hw/xen/xen-bus.h

diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
index 6ef31571c8..497e685d40 100644
--- a/hw/i386/xen/xen-hvm.c
+++ b/hw/i386/xen/xen-hvm.c
@@ -17,6 +17,7 @@
 #include "hw/i386/apic-msidef.h"
 #include "hw/xen/xen_common.h"
 #include "hw/xen/xen-legacy-backend.h"
+#include "hw/xen/xen-bus.h"
 #include "qapi/error.h"
 #include "qapi/qapi-commands-misc.h"
 #include "qemu/error-report.h"
@@ -1484,6 +1485,8 @@ void xen_hvm_init(PCMachineState *pcms, MemoryRegion 
**ram_memory)
 QLIST_INIT(>dev_list);
 device_listener_register(>device_listener);
 
+xen_bus_init();
+
 /* Initialize backend core & drivers */
 if (xen_be_init() != 0) {
 error_report("xen backend core setup failed");
diff --git a/hw/xen/Makefile.objs b/hw/xen/Makefile.objs
index 3f64a44051..d9d6d7b4f9 100644
--- a/hw/xen/Makefile.objs
+++ b/hw/xen/Makefile.objs
@@ -1,5 +1,5 @@
 # xen backend driver support
-common-obj-$(CONFIG_XEN) += xen-legacy-backend.o xen_devconfig.o xen_pvdev.o 
xen-common.o
+common-obj-$(CONFIG_XEN) += xen-legacy-backend.o xen_devconfig.o xen_pvdev.o 
xen-common.o xen-bus.o
 
 obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
 obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o 
xen_pt_graphics.o xen_pt_msi.o
diff --git a/hw/xen/trace-events b/hw/xen/trace-events
index c7e7a3b523..0172cd4e26 100644
--- a/hw/xen/trace-events
+++ b/hw/xen/trace-events
@@ -12,3 +12,9 @@ xen_unmap_portio_range(uint32_t id, uint64_t start_addr, 
uint64_t end_addr) "id:
 xen_map_pcidev(uint32_t id, uint8_t bus, uint8_t dev, uint8_t func) "id: %u 
bdf: %02x.%02x.%02x"
 xen_unmap_pcidev(uint32_t id, uint8_t bus, uint8_t dev, uint8_t func) "id: %u 
bdf: %02x.%02x.%02x"
 xen_domid_restrict(int err) "err: %u"
+
+# include/hw/xen/xen-bus.c
+xen_bus_realize(void) ""
+xen_bus_unrealize(void) ""
+xen_device_realize(const char *type) "type: %s"
+xen_device_unrealize(const char *type) "type: %s"
diff --git a/hw/xen/xen-bus.c b/hw/xen/xen-bus.c
new file mode 100644
index 00..bc04da748b
--- /dev/null
+++ b/hw/xen/xen-bus.c
@@ -0,0 +1,127 @@
+/*
+ * Copyright (c) 2018  Citrix Systems Inc.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+#include "qemu/osdep.h"
+#include "hw/hw.h"
+#include "hw/sysbus.h"
+#include "hw/xen/xen-bus.h"
+#include "qapi/error.h"
+#include "trace.h"
+
+static void xen_bus_unrealize(BusState *bus, Error **errp)
+{
+trace_xen_bus_unrealize();
+}
+
+static void xen_bus_realize(BusState *bus, Error **errp)
+{
+trace_xen_bus_realize();
+}
+
+static void xen_bus_class_init(ObjectClass *class, void *data)
+{
+BusClass *bus_class = BUS_CLASS(class);
+
+bus_class->realize = xen_bus_realize;
+bus_class->unrealize = xen_bus_unrealize;
+}
+
+static const TypeInfo xen_bus_type_info = {
+.name = TYPE_XEN_BUS,
+.parent = TYPE_BUS,
+.instance_size = sizeof(XenBus),
+.class_size = sizeof(XenBusClass),
+.class_init = xen_bus_class_init,
+.interfaces = (InterfaceInfo[]) {
+{ TYPE_HOTPLUG_HANDLER },
+{ }
+},
+};
+
+static void xen_device_unrealize(DeviceState *dev, Error **errp)
+{
+XenDevice *xendev = XEN_DEVICE(dev);
+XenDeviceClass *xendev_class = XEN_DEVICE_GET_CLASS(xendev);
+const char *type = object_get_typename(OBJECT(xendev));
+
+trace_xen_device_unrealize(type);
+
+if (xendev_class->unrealize) {
+xendev_class->unrealize(xendev, errp);
+}
+}
+
+static void xen_device_realize(DeviceState *dev, Error **errp)
+{
+XenDevice *xendev = XEN_DEVICE(dev);
+XenDeviceClass *xendev_class = XEN_DEVICE_GET_CLASS(xendev);
+const char *type = object_get_typename(OBJECT(xendev));
+Error *local_err = NULL;
+
+trace_xen_device_realize(type);
+
+if (xendev_class->realize) {
+

[Xen-devel] [PATCH v8 07/18] xen: add event channel interface for XenDevice-s

[Paul Durrant]

The legacy PV backend infrastructure provides functions to bind, unbind
and send notifications to event channnels. Similar functionality will be
required by XenDevice implementations so this patch adds the necessary
support.

Signed-off-by: Paul Durrant 
Reviewed-by: Anthony Perard 
---
Cc: Stefano Stabellini 

v2:
 - Added error pointers to notify and unbind
---
 hw/xen/xen-bus.c | 101 +++
 include/hw/xen/xen-bus.h |  18 +++
 2 files changed, 119 insertions(+)

diff --git a/hw/xen/xen-bus.c b/hw/xen/xen-bus.c
index faa9fd3577..9443f27d44 100644
--- a/hw/xen/xen-bus.c
+++ b/hw/xen/xen-bus.c
@@ -617,6 +617,81 @@ done:
 g_free(xengnttab_segs);
 }
 
+struct XenEventChannel {
+unsigned int local_port;
+XenEventHandler handler;
+void *opaque;
+Notifier notifier;
+};
+
+static void event_notify(Notifier *n, void *data)
+{
+XenEventChannel *channel = container_of(n, XenEventChannel, notifier);
+unsigned long port = (unsigned long)data;
+
+if (port == channel->local_port) {
+channel->handler(channel->opaque);
+}
+}
+
+XenEventChannel *xen_device_bind_event_channel(XenDevice *xendev,
+   unsigned int port,
+   XenEventHandler handler,
+   void *opaque, Error **errp)
+{
+XenEventChannel *channel = g_new0(XenEventChannel, 1);
+
+channel->local_port = xenevtchn_bind_interdomain(xendev->xeh,
+ xendev->frontend_id,
+ port);
+if (xendev->local_port < 0) {
+error_setg_errno(errp, errno, "xenevtchn_bind_interdomain failed");
+
+g_free(channel);
+return NULL;
+}
+
+channel->handler = handler;
+channel->opaque = opaque;
+channel->notifier.notify = event_notify;
+
+notifier_list_add(>event_notifiers, >notifier);
+
+return channel;
+}
+
+void xen_device_notify_event_channel(XenDevice *xendev,
+ XenEventChannel *channel,
+ Error **errp)
+{
+if (!channel) {
+error_setg(errp, "bad channel");
+return;
+}
+
+if (xenevtchn_notify(xendev->xeh, channel->local_port) < 0) {
+error_setg_errno(errp, errno, "xenevtchn_notify failed");
+}
+}
+
+void xen_device_unbind_event_channel(XenDevice *xendev,
+ XenEventChannel *channel,
+ Error **errp)
+{
+if (!channel) {
+error_setg(errp, "bad channel");
+return;
+}
+
+notifier_remove(>notifier);
+
+if (xenevtchn_unbind(xendev->xeh, channel->local_port) < 0) {
+error_setg_errno(errp, errno, "xenevtchn_unbind failed");
+}
+
+g_free(channel);
+}
+
 static void xen_device_unrealize(DeviceState *dev, Error **errp)
 {
 XenDevice *xendev = XEN_DEVICE(dev);
@@ -641,6 +716,12 @@ static void xen_device_unrealize(DeviceState *dev, Error 
**errp)
 xen_device_frontend_destroy(xendev);
 xen_device_backend_destroy(xendev);
 
+if (xendev->xeh) {
+qemu_set_fd_handler(xenevtchn_fd(xendev->xeh), NULL, NULL, NULL);
+xenevtchn_close(xendev->xeh);
+xendev->xeh = NULL;
+}
+
 if (xendev->xgth) {
 xengnttab_close(xendev->xgth);
 xendev->xgth = NULL;
@@ -657,6 +738,16 @@ static void xen_device_exit(Notifier *n, void *data)
 xen_device_unrealize(DEVICE(xendev), _abort);
 }
 
+static void xen_device_event(void *opaque)
+{
+XenDevice *xendev = opaque;
+unsigned long port = xenevtchn_pending(xendev->xeh);
+
+notifier_list_notify(>event_notifiers, (void *)port);
+
+xenevtchn_unmask(xendev->xeh, port);
+}
+
 static void xen_device_realize(DeviceState *dev, Error **errp)
 {
 XenDevice *xendev = XEN_DEVICE(dev);
@@ -697,6 +788,16 @@ static void xen_device_realize(DeviceState *dev, Error 
**errp)
 xendev->feature_grant_copy =
 (xengnttab_grant_copy(xendev->xgth, 0, NULL) == 0);
 
+xendev->xeh = xenevtchn_open(NULL, 0);
+if (!xendev->xeh) {
+error_setg_errno(errp, errno, "failed xenevtchn_open");
+goto unrealize;
+}
+
+notifier_list_init(>event_notifiers);
+qemu_set_fd_handler(xenevtchn_fd(xendev->xeh), xen_device_event, NULL,
+xendev);
+
 xen_device_backend_create(xendev, _err);
 if (local_err) {
 error_propagate(errp, local_err);
diff --git a/include/hw/xen/xen-bus.h b/include/hw/xen/xen-bus.h
index 63a09b67ee..f83a95cebd 100644
--- a/include/hw/xen/xen-bus.h
+++ b/include/hw/xen/xen-bus.h
@@ -26,6 +26,9 @@ typedef struct XenDevice {
 XenWatch *frontend_state_watch;
 xengnttab_handle *xgth;
 bool feature_grant_copy;
+xenevtchn_handle *xeh;
+xenevtchn_port_or_error_t local_port;
+NotifierList event_notifiers;
 } XenDevice;
 
 

[Xen-devel] [PATCH v8 01/18] xen: re-name XenDevice to XenLegacyDevice...

[Paul Durrant]

...and xen_backend.h to xen-legacy-backend.h

Rather than attempting to convert the existing backend infrastructure to
be QOM compliant (which would be hard to do in an incremental fashion),
subsequent patches will introduce a completely new framework for Xen PV
backends. Hence it is necessary to re-name parts of existing code to avoid
name clashes. The re-named 'legacy' infrastructure will be removed once all
backends have been ported to the new framework.

This patch is purely cosmetic. No functional change.

Signed-off-by: Paul Durrant 
Acked-by: Anthony Perard 
---
Cc: Stefano Stabellini 
Cc: Greg Kurz 
Cc: Kevin Wolf 
Cc: Max Reitz 
Cc: "Marc-André Lureau" 
Cc: Paolo Bonzini 
Cc: Richard Henderson 
Cc: Eduardo Habkost 
Cc: "Michael S. Tsirkin" 
Cc: Marcel Apfelbaum 
Cc: Jason Wang 
Cc: Gerd Hoffmann 
---
 hw/9pfs/xen-9p-backend.c  | 16 ++--
 hw/block/xen_disk.c   | 24 +++---
 hw/char/xen_console.c | 12 +--
 hw/display/xenfb.c| 25 +++---
 hw/i386/xen/xen-hvm.c |  2 +-
 hw/i386/xen/xen-mapcache.c|  2 +-
 hw/i386/xen/xen_platform.c|  2 +-
 hw/net/xen_nic.c  | 14 ++--
 hw/usb/xen-usb.c  | 25 +++---
 hw/xen/Makefile.objs  |  2 +-
 hw/xen/xen-common.c   |  2 +-
 .../{xen_backend.c => xen-legacy-backend.c}   | 79 +++
 hw/xen/xen_devconfig.c|  2 +-
 hw/xen/xen_pt.c   |  2 +-
 hw/xen/xen_pt_config_init.c   |  2 +-
 hw/xen/xen_pt_graphics.c  |  2 +-
 hw/xen/xen_pt_msi.c   |  2 +-
 hw/xen/xen_pvdev.c| 20 ++---
 hw/xenpv/xen_domainbuild.c|  2 +-
 hw/xenpv/xen_machine_pv.c |  2 +-
 .../{xen_backend.h => xen-legacy-backend.h}   | 43 +-
 include/hw/xen/xen_pvdev.h| 38 -
 22 files changed, 169 insertions(+), 151 deletions(-)
 rename hw/xen/{xen_backend.c => xen-legacy-backend.c} (89%)
 rename include/hw/xen/{xen_backend.h => xen-legacy-backend.h} (61%)

diff --git a/hw/9pfs/xen-9p-backend.c b/hw/9pfs/xen-9p-backend.c
index 9015fe7773..25ab04d95a 100644
--- a/hw/9pfs/xen-9p-backend.c
+++ b/hw/9pfs/xen-9p-backend.c
@@ -12,7 +12,7 @@
 
 #include "hw/hw.h"
 #include "hw/9pfs/9p.h"
-#include "hw/xen/xen_backend.h"
+#include "hw/xen/xen-legacy-backend.h"
 #include "hw/9pfs/xen-9pfs.h"
 #include "qapi/error.h"
 #include "qemu/config-file.h"
@@ -45,7 +45,7 @@ typedef struct Xen9pfsRing {
 } Xen9pfsRing;
 
 typedef struct Xen9pfsDev {
-struct XenDevice xendev;  /* must be first */
+struct XenLegacyDevice xendev;  /* must be first */
 V9fsState state;
 char *path;
 char *security_model;
@@ -56,7 +56,7 @@ typedef struct Xen9pfsDev {
 Xen9pfsRing *rings;
 } Xen9pfsDev;
 
-static void xen_9pfs_disconnect(struct XenDevice *xendev);
+static void xen_9pfs_disconnect(struct XenLegacyDevice *xendev);
 
 static void xen_9pfs_in_sg(Xen9pfsRing *ring,
struct iovec *in_sg,
@@ -243,7 +243,7 @@ static const V9fsTransport xen_9p_transport = {
 .push_and_notify = xen_9pfs_push_and_notify,
 };
 
-static int xen_9pfs_init(struct XenDevice *xendev)
+static int xen_9pfs_init(struct XenLegacyDevice *xendev)
 {
 return 0;
 }
@@ -305,7 +305,7 @@ static void xen_9pfs_evtchn_event(void *opaque)
 qemu_bh_schedule(ring->bh);
 }
 
-static void xen_9pfs_disconnect(struct XenDevice *xendev)
+static void xen_9pfs_disconnect(struct XenLegacyDevice *xendev)
 {
 Xen9pfsDev *xen_9pdev = container_of(xendev, Xen9pfsDev, xendev);
 int i;
@@ -321,7 +321,7 @@ static void xen_9pfs_disconnect(struct XenDevice *xendev)
 }
 }
 
-static int xen_9pfs_free(struct XenDevice *xendev)
+static int xen_9pfs_free(struct XenLegacyDevice *xendev)
 {
 Xen9pfsDev *xen_9pdev = container_of(xendev, Xen9pfsDev, xendev);
 int i;
@@ -354,7 +354,7 @@ static int xen_9pfs_free(struct XenDevice *xendev)
 return 0;
 }
 
-static int xen_9pfs_connect(struct XenDevice *xendev)
+static int xen_9pfs_connect(struct XenLegacyDevice *xendev)
 {
 Error *err = NULL;
 int i;
@@ -467,7 +467,7 @@ out:
 return -1;
 }
 
-static void xen_9pfs_alloc(struct XenDevice *xendev)
+static void xen_9pfs_alloc(struct XenLegacyDevice *xendev)
 {
 xenstore_write_be_str(xendev, "versions", VERSIONS);
 xenstore_write_be_int(xendev, "max-rings", MAX_RINGS);
diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
index 36eff94f84..75fe55f2ae 100644
--- a/hw/block/xen_disk.c
+++ b/hw/block/xen_disk.c
@@ -25,7 +25,7 @@
 #include 
 
 #include "hw/hw.h"
-#include "hw/xen/xen_backend.h"
+#include "hw/xen/xen-legacy-backend.h"
 #include "xen_blkif.h"
 #include "sysemu/blockdev.h"
 #include "sysemu/iothread.h"
@@ -63,7 +63,7 @@ struct 

[Xen-devel] [PATCH v8 06/18] xen: add grant table interface for XenDevice-s

[Paul Durrant]

The legacy PV backend infrastructure provides functions to map, unmap and
copy pages granted by frontends. Similar functionality will be required
by XenDevice implementations so this patch adds the necessary support.

Signed-off-by: Paul Durrant 
Reviewed-by: Anthony Perard 
---
Cc: Stefano Stabellini 
---
 hw/xen/xen-bus.c | 146 +++
 include/hw/xen/xen-bus.h |  25 +++
 2 files changed, 171 insertions(+)

diff --git a/hw/xen/xen-bus.c b/hw/xen/xen-bus.c
index 5e19592190..faa9fd3577 100644
--- a/hw/xen/xen-bus.c
+++ b/hw/xen/xen-bus.c
@@ -485,6 +485,138 @@ static void xen_device_frontend_destroy(XenDevice *xendev)
 }
 }
 
+void xen_device_set_max_grant_refs(XenDevice *xendev, unsigned int nr_refs,
+   Error **errp)
+{
+if (xengnttab_set_max_grants(xendev->xgth, nr_refs)) {
+error_setg_errno(errp, errno, "xengnttab_set_max_grants failed");
+}
+}
+
+void *xen_device_map_grant_refs(XenDevice *xendev, uint32_t *refs,
+unsigned int nr_refs, int prot,
+Error **errp)
+{
+void *map = xengnttab_map_domain_grant_refs(xendev->xgth, nr_refs,
+xendev->frontend_id, refs,
+prot);
+
+if (!map) {
+error_setg_errno(errp, errno,
+ "xengnttab_map_domain_grant_refs failed");
+}
+
+return map;
+}
+
+void xen_device_unmap_grant_refs(XenDevice *xendev, void *map,
+ unsigned int nr_refs, Error **errp)
+{
+if (xengnttab_unmap(xendev->xgth, map, nr_refs)) {
+error_setg_errno(errp, errno, "xengnttab_unmap failed");
+}
+}
+
+static void compat_copy_grant_refs(XenDevice *xendev, bool to_domain,
+   XenDeviceGrantCopySegment segs[],
+   unsigned int nr_segs, Error **errp)
+{
+uint32_t *refs = g_new(uint32_t, nr_segs);
+int prot = to_domain ? PROT_WRITE : PROT_READ;
+void *map;
+unsigned int i;
+
+for (i = 0; i < nr_segs; i++) {
+XenDeviceGrantCopySegment *seg = [i];
+
+refs[i] = to_domain ? seg->dest.foreign.ref :
+seg->source.foreign.ref;
+}
+
+map = xengnttab_map_domain_grant_refs(xendev->xgth, nr_segs,
+  xendev->frontend_id, refs,
+  prot);
+if (!map) {
+error_setg_errno(errp, errno,
+ "xengnttab_map_domain_grant_refs failed");
+goto done;
+}
+
+for (i = 0; i < nr_segs; i++) {
+XenDeviceGrantCopySegment *seg = [i];
+void *page = map + (i * XC_PAGE_SIZE);
+
+if (to_domain) {
+memcpy(page + seg->dest.foreign.offset, seg->source.virt,
+   seg->len);
+} else {
+memcpy(seg->dest.virt, page + seg->source.foreign.offset,
+   seg->len);
+}
+}
+
+if (xengnttab_unmap(xendev->xgth, map, nr_segs)) {
+error_setg_errno(errp, errno, "xengnttab_unmap failed");
+}
+
+done:
+g_free(refs);
+}
+
+void xen_device_copy_grant_refs(XenDevice *xendev, bool to_domain,
+XenDeviceGrantCopySegment segs[],
+unsigned int nr_segs, Error **errp)
+{
+xengnttab_grant_copy_segment_t *xengnttab_segs;
+unsigned int i;
+
+if (!xendev->feature_grant_copy) {
+compat_copy_grant_refs(xendev, to_domain, segs, nr_segs, errp);
+return;
+}
+
+xengnttab_segs = g_new0(xengnttab_grant_copy_segment_t, nr_segs);
+
+for (i = 0; i < nr_segs; i++) {
+XenDeviceGrantCopySegment *seg = [i];
+xengnttab_grant_copy_segment_t *xengnttab_seg = _segs[i];
+
+if (to_domain) {
+xengnttab_seg->flags = GNTCOPY_dest_gref;
+xengnttab_seg->dest.foreign.domid = xendev->frontend_id;
+xengnttab_seg->dest.foreign.ref = seg->dest.foreign.ref;
+xengnttab_seg->dest.foreign.offset = seg->dest.foreign.offset;
+xengnttab_seg->source.virt = seg->source.virt;
+} else {
+xengnttab_seg->flags = GNTCOPY_source_gref;
+xengnttab_seg->source.foreign.domid = xendev->frontend_id;
+xengnttab_seg->source.foreign.ref = seg->source.foreign.ref;
+xengnttab_seg->source.foreign.offset =
+seg->source.foreign.offset;
+xengnttab_seg->dest.virt = seg->dest.virt;
+}
+
+xengnttab_seg->len = seg->len;
+}
+
+if (xengnttab_grant_copy(xendev->xgth, nr_segs, xengnttab_segs)) {
+error_setg_errno(errp, errno, "xengnttab_grant_copy failed");
+goto done;
+}
+
+for (i = 0; i < nr_segs; i++) {
+xengnttab_grant_copy_segment_t *xengnttab_seg = _segs[i];
+
+if (xengnttab_seg->status != GNTST_okay) {
+  

[Xen-devel] [PATCH v8 03/18] xen: introduce 'xen-block', 'xen-disk' and 'xen-cdrom'

[Paul Durrant]

This patch adds new XenDevice-s: 'xen-disk' and 'xen-cdrom', both derived
from a common 'xen-block' parent type. These will eventually replace the
'xen_disk' (note the underscore rather than hyphen) legacy PV backend but
it is illustrative to build up the implementation incrementally, along with
the XenBus/XenDevice framework. Subsequent patches will therefore add to
these devices' implementation as new features are added to the framework.

After this patch has been applied it is possible to instantiate new
'xen-disk' or 'xen-cdrom' devices with a single 'vdev' parameter, which
accepts values adhering to the Xen VBD naming scheme [1]. For example, a
command-line instantiation of a xen-disk can be done with an argument
similar to the following:

-device xen-disk,vdev=hda

The implementation of the vdev parameter formulates the appropriate VBD
number for use in the PV protocol.

[1] https://xenbits.xen.org/docs/unstable/man/xen-vbd-interface.7.html

Signed-off-by: Paul Durrant 
Reviewed-by: Anthony Perard 
---
Cc: Kevin Wolf 
Cc: Max Reitz 
Cc: Stefano Stabellini 

v5:
 - Introduce properties sub-structure (which will be useful later)
 - Keeping Anthony's R-b from v4 since change is trivial

v3:
 - Fix vdev parsing again, and vdev formatting this time
 - Remove an unnecessary local_err

v2:
 - Fix boilerplate
 - Fix vdev parsing
 - Change name from 'xen-qdisk' to 'xen-block', make abstract, and split
   off 'xen-disk' and 'xen-cdrom' as concrete sub-types
---
 MAINTAINERS|   2 +-
 hw/block/Makefile.objs |   1 +
 hw/block/trace-events  |   8 +
 hw/block/xen-block.c   | 343 +
 include/hw/xen/xen-block.h |  73 
 5 files changed, 426 insertions(+), 1 deletion(-)
 create mode 100644 hw/block/xen-block.c
 create mode 100644 include/hw/xen/xen-block.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 19792cfb2d..38d6c3b973 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -414,7 +414,7 @@ F: hw/9pfs/xen-9p-backend.c
 F: hw/char/xen_console.c
 F: hw/display/xenfb.c
 F: hw/net/xen_nic.c
-F: hw/block/xen_*
+F: hw/block/xen*
 F: hw/xen/
 F: hw/xenpv/
 F: hw/i386/xen/
diff --git a/hw/block/Makefile.objs b/hw/block/Makefile.objs
index 53ce5751ae..f34813a377 100644
--- a/hw/block/Makefile.objs
+++ b/hw/block/Makefile.objs
@@ -4,6 +4,7 @@ common-obj-$(CONFIG_SSI_M25P80) += m25p80.o
 common-obj-$(CONFIG_NAND) += nand.o
 common-obj-$(CONFIG_PFLASH_CFI01) += pflash_cfi01.o
 common-obj-$(CONFIG_PFLASH_CFI02) += pflash_cfi02.o
+common-obj-$(CONFIG_XEN) += xen-block.o
 common-obj-$(CONFIG_XEN) += xen_disk.o
 common-obj-$(CONFIG_ECC) += ecc.o
 common-obj-$(CONFIG_ONENAND) += onenand.o
diff --git a/hw/block/trace-events b/hw/block/trace-events
index 335c092450..4afbd62a88 100644
--- a/hw/block/trace-events
+++ b/hw/block/trace-events
@@ -127,3 +127,11 @@ xen_disk_init(char *name) "%s"
 xen_disk_connect(char *name) "%s"
 xen_disk_disconnect(char *name) "%s"
 xen_disk_free(char *name) "%s"
+
+# hw/block/xen-block.c
+xen_block_realize(const char *type, uint32_t disk, uint32_t partition) "%s 
d%up%u"
+xen_block_unrealize(const char *type, uint32_t disk, uint32_t partition) "%s 
d%up%u"
+xen_disk_realize(void) ""
+xen_disk_unrealize(void) ""
+xen_cdrom_realize(void) ""
+xen_cdrom_unrealize(void) ""
diff --git a/hw/block/xen-block.c b/hw/block/xen-block.c
new file mode 100644
index 00..8e78b6a034
--- /dev/null
+++ b/hw/block/xen-block.c
@@ -0,0 +1,343 @@
+/*
+ * Copyright (c) 2018  Citrix Systems Inc.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+#include "qemu/osdep.h"
+#include "qemu/cutils.h"
+#include "qapi/error.h"
+#include "qapi/visitor.h"
+#include "hw/hw.h"
+#include "hw/xen/xen-block.h"
+#include "trace.h"
+
+static void xen_block_unrealize(XenDevice *xendev, Error **errp)
+{
+XenBlockDevice *blockdev = XEN_BLOCK_DEVICE(xendev);
+XenBlockDeviceClass *blockdev_class =
+XEN_BLOCK_DEVICE_GET_CLASS(xendev);
+const char *type = object_get_typename(OBJECT(blockdev));
+XenBlockVdev *vdev = >props.vdev;
+
+if (vdev->type == XEN_BLOCK_VDEV_TYPE_INVALID) {
+return;
+}
+
+trace_xen_block_unrealize(type, vdev->disk, vdev->partition);
+
+if (blockdev_class->unrealize) {
+blockdev_class->unrealize(blockdev, errp);
+}
+}
+
+static void xen_block_realize(XenDevice *xendev, Error **errp)
+{
+XenBlockDevice *blockdev = XEN_BLOCK_DEVICE(xendev);
+XenBlockDeviceClass *blockdev_class =
+XEN_BLOCK_DEVICE_GET_CLASS(xendev);
+const char *type = object_get_typename(OBJECT(blockdev));
+XenBlockVdev *vdev = >props.vdev;
+Error *local_err = NULL;
+
+if (vdev->type == XEN_BLOCK_VDEV_TYPE_INVALID) {
+error_setg(errp, "vdev property not set");
+return;
+}
+
+trace_xen_block_realize(type, vdev->disk, vdev->partition);
+
+if (blockdev_class->realize) {
+

[Xen-devel] [PATCH v8 04/18] xen: create xenstore areas for XenDevice-s

[Paul Durrant]

This patch adds a new source module, xen-bus-helper.c, which builds on
basic libxenstore primitives to provide functions to create (setting
permissions appropriately) and destroy xenstore areas, and functions to
'printf' and 'scanf' nodes therein. The main xen-bus code then uses
these primitives [1] to initialize and destroy the frontend and backend
areas for a XenDevice during realize and unrealize respectively.

The 'xen-block' implementation is extended with a 'get_name' method that
returns the VBD number. This number is required to 'name' the xenstore
areas.

NOTE: An exit handler is also added to make sure the xenstore areas are
  cleaned up if QEMU terminates without devices being unrealized.

[1] The 'scanf' functions are actually not yet needed, but they will be
needed by code delivered in subsequent patches.

Signed-off-by: Paul Durrant 
Reviewed-by: Anthony Perard 
---
Cc: Stefano Stabellini 
Cc: Kevin Wolf 
Cc: Max Reitz 

v5:
 - Re-base

v3:
 - Add transaction id parameters to xen-bus-helper functions
 - Not added Anthony's R-b because of change

v2:
 - Fix boilerplate
 - Add error pointers to all xs_node... helpers
 - Add GCC_FMT_ATTR to declarations of printf-like helpers
---
 hw/block/xen-block.c|   9 +
 hw/xen/Makefile.objs|   2 +-
 hw/xen/trace-events |  12 +-
 hw/xen/xen-bus-helper.c | 150 +++
 hw/xen/xen-bus.c| 321 +++-
 include/hw/xen/xen-bus-helper.h |  39 
 include/hw/xen/xen-bus.h|  12 ++
 7 files changed, 540 insertions(+), 5 deletions(-)
 create mode 100644 hw/xen/xen-bus-helper.c
 create mode 100644 include/hw/xen/xen-bus-helper.h

diff --git a/hw/block/xen-block.c b/hw/block/xen-block.c
index 8e78b6a034..d27a2865bc 100644
--- a/hw/block/xen-block.c
+++ b/hw/block/xen-block.c
@@ -13,6 +13,14 @@
 #include "hw/xen/xen-block.h"
 #include "trace.h"
 
+static char *xen_block_get_name(XenDevice *xendev, Error **errp)
+{
+XenBlockDevice *blockdev = XEN_BLOCK_DEVICE(xendev);
+XenBlockVdev *vdev = >props.vdev;
+
+return g_strdup_printf("%lu", vdev->number);
+}
+
 static void xen_block_unrealize(XenDevice *xendev, Error **errp)
 {
 XenBlockDevice *blockdev = XEN_BLOCK_DEVICE(xendev);
@@ -262,6 +270,7 @@ static void xen_block_class_init(ObjectClass *class, void 
*data)
 DeviceClass *dev_class = DEVICE_CLASS(class);
 XenDeviceClass *xendev_class = XEN_DEVICE_CLASS(class);
 
+xendev_class->get_name = xen_block_get_name;
 xendev_class->realize = xen_block_realize;
 xendev_class->unrealize = xen_block_unrealize;
 
diff --git a/hw/xen/Makefile.objs b/hw/xen/Makefile.objs
index d9d6d7b4f9..77c0868190 100644
--- a/hw/xen/Makefile.objs
+++ b/hw/xen/Makefile.objs
@@ -1,5 +1,5 @@
 # xen backend driver support
-common-obj-$(CONFIG_XEN) += xen-legacy-backend.o xen_devconfig.o xen_pvdev.o 
xen-common.o xen-bus.o
+common-obj-$(CONFIG_XEN) += xen-legacy-backend.o xen_devconfig.o xen_pvdev.o 
xen-common.o xen-bus.o xen-bus-helper.o
 
 obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
 obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o 
xen_pt_graphics.o xen_pt_msi.o
diff --git a/hw/xen/trace-events b/hw/xen/trace-events
index 0172cd4e26..75dc226d75 100644
--- a/hw/xen/trace-events
+++ b/hw/xen/trace-events
@@ -16,5 +16,13 @@ xen_domid_restrict(int err) "err: %u"
 # include/hw/xen/xen-bus.c
 xen_bus_realize(void) ""
 xen_bus_unrealize(void) ""
-xen_device_realize(const char *type) "type: %s"
-xen_device_unrealize(const char *type) "type: %s"
+xen_device_realize(const char *type, char *name) "type: %s name: %s"
+xen_device_unrealize(const char *type, char *name) "type: %s name: %s"
+xen_device_backend_state(const char *type, char *name, const char *state) 
"type: %s name: %s -> %s"
+xen_device_frontend_state(const char *type, char *name, const char *state) 
"type: %s name: %s -> %s"
+
+# include/hw/xen/xen-bus-helper.c
+xs_node_create(const char *node) "%s"
+xs_node_destroy(const char *node) "%s"
+xs_node_vprintf(char *path, char *value) "%s %s"
+xs_node_vscanf(char *path, char *value) "%s %s"
diff --git a/hw/xen/xen-bus-helper.c b/hw/xen/xen-bus-helper.c
new file mode 100644
index 00..15b3ad8d78
--- /dev/null
+++ b/hw/xen/xen-bus-helper.c
@@ -0,0 +1,150 @@
+/*
+ * Copyright (c) 2018  Citrix Systems Inc.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+#include "qemu/osdep.h"
+#include "hw/hw.h"
+#include "hw/sysbus.h"
+#include "hw/xen/xen.h"
+#include "hw/xen/xen-bus.h"
+#include "hw/xen/xen-bus-helper.h"
+#include "qapi/error.h"
+
+#include 
+
+struct xs_state {
+enum xenbus_state statenum;
+const char *statestr;
+};
+#define XS_STATE(state) { state, #state }
+
+static struct xs_state xs_state[] = {
+XS_STATE(XenbusStateUnknown),
+XS_STATE(XenbusStateInitialising),
+XS_STATE(XenbusStateInitWait),
+

[Xen-devel] [PATCH v8 09/18] xen: remove unnecessary code from dataplane/xen-block.c

[Paul Durrant]

Not all of the code duplicated from xen_disk.c is required as the basis for
the new dataplane implementation so this patch removes extraneous code,
along with the legacy #includes and calls to the legacy xen_pv_printf()
function. Error messages are changed to be reported using error_report().

NOTE: The code is still not yet built. Further transformations will be
  required to make it correctly interface to the new XenBus/XenDevice
  framework. They will be delivered in a subsequent patch.

Signed-off-by: Paul Durrant 
Acked-by: Anthony Perard 
---
Cc: Stefano Stabellini 
Cc: Stefan Hajnoczi 
Cc: Kevin Wolf 
Cc: Max Reitz 

v6:
 - v5 was messed up so fix the boilerplate again
 - Drop Anthony's R-b so he can check it

v2:
 - Leave existing boilerplate alone, other than removing the now-incorrect
   description
---
 hw/block/dataplane/xen-block.c | 429 ++---
 1 file changed, 23 insertions(+), 406 deletions(-)

diff --git a/hw/block/dataplane/xen-block.c b/hw/block/dataplane/xen-block.c
index 9fae50534e..228472320a 100644
--- a/hw/block/dataplane/xen-block.c
+++ b/hw/block/dataplane/xen-block.c
@@ -1,45 +1,23 @@
 /*
- *  xen paravirt block device backend
+ * Copyright (c) 2018  Citrix Systems Inc.
+ * (c) Gerd Hoffmann 
  *
- *  (c) Gerd Hoffmann 
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; under version 2 of the License.
  *
- *  This program is free software; you can redistribute it and/or modify
- *  it under the terms of the GNU General Public License as published by
- *  the Free Software Foundation; under version 2 of the License.
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
  *
- *  This program is distributed in the hope that it will be useful,
- *  but WITHOUT ANY WARRANTY; without even the implied warranty of
- *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *  GNU General Public License for more details.
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see .
  *
- *  You should have received a copy of the GNU General Public License along
- *  with this program; if not, see .
- *
- *  Contributions after 2012-01-13 are licensed under the terms of the
- *  GNU GPL, version 2 or (at your option) any later version.
+ * Contributions after 2012-01-13 are licensed under the terms of the
+ * GNU GPL, version 2 or (at your option) any later version.
  */
 
-#include "qemu/osdep.h"
-#include "qemu/units.h"
-#include 
-#include 
-
-#include "hw/hw.h"
-#include "hw/xen/xen_backend.h"
-#include "xen_blkif.h"
-#include "sysemu/blockdev.h"
-#include "sysemu/iothread.h"
-#include "sysemu/block-backend.h"
-#include "qapi/error.h"
-#include "qapi/qmp/qdict.h"
-#include "qapi/qmp/qstring.h"
-#include "trace.h"
-
-/* - */
-
-#define BLOCK_SIZE  512
-#define IOCB_COUNT  (BLKIF_MAX_SEGMENTS_PER_REQUEST + 2)
-
 struct ioreq {
 blkif_request_t req;
 int16_t status;
@@ -101,8 +79,6 @@ struct XenBlkDev {
 AioContext  *ctx;
 };
 
-/* - */
-
 static void ioreq_reset(struct ioreq *ioreq)
 {
 memset(>req, 0, sizeof(ioreq->req));
@@ -183,11 +159,6 @@ static int ioreq_parse(struct ioreq *ioreq)
 size_t len;
 int i;
 
-xen_pv_printf(
-xendev, 3,
-"op %d, nr %d, handle %d, id %" PRId64 ", sector %" PRId64 "\n",
-ioreq->req.operation, ioreq->req.nr_segments,
-ioreq->req.handle, ioreq->req.id, ioreq->req.sector_number);
 switch (ioreq->req.operation) {
 case BLKIF_OP_READ:
 break;
@@ -202,28 +173,27 @@ static int ioreq_parse(struct ioreq *ioreq)
 case BLKIF_OP_DISCARD:
 return 0;
 default:
-xen_pv_printf(xendev, 0, "error: unknown operation (%d)\n",
-  ioreq->req.operation);
+error_report("error: unknown operation (%d)", ioreq->req.operation);
 goto err;
 };
 
 if (ioreq->req.operation != BLKIF_OP_READ && blkdev->mode[0] != 'w') {
-xen_pv_printf(xendev, 0, "error: write req for ro device\n");
+error_report("error: write req for ro device");
 goto err;
 }
 
 ioreq->start = ioreq->req.sector_number * blkdev->file_blk;
 for (i = 0; i < ioreq->req.nr_segments; i++) {
 if (i == BLKIF_MAX_SEGMENTS_PER_REQUEST) {
-xen_pv_printf(xendev, 0, "error: nr_segments too big\n");
+error_report("error: nr_segments too big");
 goto err;
 }
 if 

[Xen-devel] [PATCH v8 08/18] xen: duplicate xen_disk.c as basis of dataplane/xen-block.c

[Paul Durrant]

The new xen-block XenDevice implementation requires the same core
dataplane as the legacy xen_disk implementation it will eventually replace.
This patch therefore copies the legacy xen_disk.c source module into a new
dataplane/xen-block.c source module as the basis for the new dataplane and
adjusts the MAINTAINERS file accordingly.

NOTE: The duplicated code is not yet built. It is simply put into place by
  this patch (just fixing style violations) such that the
  modifications that will need to be made to the code are not
  conflated with code movement, thus making review harder.

Signed-off-by: Paul Durrant 
Acked-by: Anthony Perard 
---
Cc: Stefano Stabellini 
Cc: Stefan Hajnoczi 
Cc: Kevin Wolf 
Cc: Max Reitz 
---
 MAINTAINERS|1 +
 hw/block/dataplane/xen-block.c | 1019 
 2 files changed, 1020 insertions(+)
 create mode 100644 hw/block/dataplane/xen-block.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 38d6c3b973..f730d6c3cc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -415,6 +415,7 @@ F: hw/char/xen_console.c
 F: hw/display/xenfb.c
 F: hw/net/xen_nic.c
 F: hw/block/xen*
+F: hw/block/dataplane/xen*
 F: hw/xen/
 F: hw/xenpv/
 F: hw/i386/xen/
diff --git a/hw/block/dataplane/xen-block.c b/hw/block/dataplane/xen-block.c
new file mode 100644
index 00..9fae50534e
--- /dev/null
+++ b/hw/block/dataplane/xen-block.c
@@ -0,0 +1,1019 @@
+/*
+ *  xen paravirt block device backend
+ *
+ *  (c) Gerd Hoffmann 
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; under version 2 of the License.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License along
+ *  with this program; if not, see .
+ *
+ *  Contributions after 2012-01-13 are licensed under the terms of the
+ *  GNU GPL, version 2 or (at your option) any later version.
+ */
+
+#include "qemu/osdep.h"
+#include "qemu/units.h"
+#include 
+#include 
+
+#include "hw/hw.h"
+#include "hw/xen/xen_backend.h"
+#include "xen_blkif.h"
+#include "sysemu/blockdev.h"
+#include "sysemu/iothread.h"
+#include "sysemu/block-backend.h"
+#include "qapi/error.h"
+#include "qapi/qmp/qdict.h"
+#include "qapi/qmp/qstring.h"
+#include "trace.h"
+
+/* - */
+
+#define BLOCK_SIZE  512
+#define IOCB_COUNT  (BLKIF_MAX_SEGMENTS_PER_REQUEST + 2)
+
+struct ioreq {
+blkif_request_t req;
+int16_t status;
+
+/* parsed request */
+off_t   start;
+QEMUIOVectorv;
+void*buf;
+size_t  size;
+int presync;
+
+/* aio status */
+int aio_inflight;
+int aio_errors;
+
+struct XenBlkDev*blkdev;
+QLIST_ENTRY(ioreq)   list;
+BlockAcctCookie acct;
+};
+
+#define MAX_RING_PAGE_ORDER 4
+
+struct XenBlkDev {
+struct XenLegacyDevicexendev;  /* must be first */
+char*params;
+char*mode;
+char*type;
+char*dev;
+char*devtype;
+booldirectiosafe;
+const char  *fileproto;
+const char  *filename;
+unsigned intring_ref[1 << MAX_RING_PAGE_ORDER];
+unsigned intnr_ring_ref;
+void*sring;
+int64_t file_blk;
+int64_t file_size;
+int protocol;
+blkif_back_rings_t  rings;
+int more_work;
+
+/* request lists */
+QLIST_HEAD(inflight_head, ioreq) inflight;
+QLIST_HEAD(finished_head, ioreq) finished;
+QLIST_HEAD(freelist_head, ioreq) freelist;
+int requests_total;
+int requests_inflight;
+int requests_finished;
+unsigned intmax_requests;
+
+gbooleanfeature_discard;
+
+/* qemu block driver */
+DriveInfo   *dinfo;
+BlockBackend*blk;
+QEMUBH  *bh;
+
+IOThread*iothread;
+AioContext  *ctx;
+};
+
+/* - */
+
+static void ioreq_reset(struct ioreq *ioreq)
+{
+memset(>req, 0, sizeof(ioreq->req));
+ioreq->status = 0;
+ioreq->start = 0;
+ioreq->buf = NULL;
+ioreq->size = 0;
+ioreq->presync = 0;
+
+ioreq->aio_inflight = 0;
+ioreq->aio_errors = 0;
+
+ioreq->blkdev = NULL;
+memset(>list, 0, sizeof(ioreq->list));
+memset(>acct, 0, sizeof(ioreq->acct));
+
+

[Xen-devel] [PATCH v8 00/18] Xen PV backend 'qdevification'

[Paul Durrant]

This series introduces a new QOM compliant framework for Xen PV backends.
This is achieved by first moving the current non-compliant framework aside,
before building up a new framework incrementally.

This series was prompted by a thread [1] started by Kevin Wolf in response
to patches against xen_disk.c posted by Tim Smith. Therefore, alongside
the patches introducing the new framework, other patches build up a QOM
compliant replacement for 'xen_disk', called 'xen-qdisk'. Patch #16 swaps
this new device into place (having establisheda mechanism to auto-
instantiate devices that is compliant with existing Xen toolstacks in
patch #15) and patch #18 then removes the old xen_disk code.

Subsequent series will port other Xen PV backends across to the new
framework.

The series is also available as a repository branch [2] on xenbits.xen.org.

[1] https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg00259.html
[2] 
http://xenbits.xen.org/gitweb/?p=people/pauldu/qemu.git;a=shortlog;h=refs/heads/qom33

Paul Durrant (18):
  xen: re-name XenDevice to XenLegacyDevice...
  xen: introduce new 'XenBus' and 'XenDevice' object hierarchy
  xen: introduce 'xen-block', 'xen-disk' and 'xen-cdrom'
  xen: create xenstore areas for XenDevice-s
  xen: add xenstore watcher infrastructure
  xen: add grant table interface for XenDevice-s
  xen: add event channel interface for XenDevice-s
  xen: duplicate xen_disk.c as basis of dataplane/xen-block.c
  xen: remove unnecessary code from dataplane/xen-block.c
  xen: add header and build dataplane/xen-block.c
  xen: remove 'XenBlkDev' and 'blkdev' names from dataplane/xen-block
  xen: remove 'ioreq' struct/varable/field names from
dataplane/xen-block.c
  xen: purge 'blk' and 'ioreq' from function names in
dataplane/xen-block.c
  xen: add implementations of xen-block connect and disconnect
functions...
  xen: add a mechanism to automatically create XenDevice-s...
  xen: automatically create XenBlockDevice-s
  MAINTAINERS: add myself as a Xen maintainer
  xen: remove the legacy 'xen_disk' backend

 MAINTAINERS   |5 +-
 hw/9pfs/xen-9p-backend.c  |   16 +-
 hw/block/Makefile.objs|2 +-
 hw/block/dataplane/Makefile.objs  |1 +
 hw/block/dataplane/xen-block.c|  808 +++
 hw/block/dataplane/xen-block.h|   29 +
 hw/block/trace-events |   14 +
 hw/block/xen-block.c  |  987 ++
 hw/block/xen_disk.c   | 1011 --
 hw/char/xen_console.c |   12 +-
 hw/display/xenfb.c|   25 +-
 hw/i386/xen/xen-hvm.c |5 +-
 hw/i386/xen/xen-mapcache.c|2 +-
 hw/i386/xen/xen_platform.c|2 +-
 hw/net/xen_nic.c  |   14 +-
 hw/usb/xen-usb.c  |   25 +-
 hw/xen/Makefile.objs  |2 +-
 hw/xen/trace-events   |   26 +
 hw/xen/xen-backend.c  |  165 +++
 hw/xen/xen-bus-helper.c   |  184 +++
 hw/xen/xen-bus.c  | 1197 +
 hw/xen/xen-common.c   |2 +-
 .../{xen_backend.c => xen-legacy-backend.c}   |   80 +-
 hw/xen/xen_devconfig.c|2 +-
 hw/xen/xen_pt.c   |2 +-
 hw/xen/xen_pt_config_init.c   |2 +-
 hw/xen/xen_pt_graphics.c  |2 +-
 hw/xen/xen_pt_msi.c   |2 +-
 hw/xen/xen_pvdev.c|   20 +-
 hw/xenpv/xen_domainbuild.c|2 +-
 hw/xenpv/xen_machine_pv.c |5 +-
 include/hw/xen/xen-backend.h  |   39 +
 include/hw/xen/xen-block.h|   95 ++
 include/hw/xen/xen-bus-helper.h   |   45 +
 include/hw/xen/xen-bus.h  |  138 ++
 .../{xen_backend.h => xen-legacy-backend.h}   |   43 +-
 include/hw/xen/xen_pvdev.h|   38 +-
 include/qemu/module.h |3 +
 38 files changed, 3899 insertions(+), 1153 deletions(-)
 create mode 100644 hw/block/dataplane/xen-block.c
 create mode 100644 hw/block/dataplane/xen-block.h
 create mode 100644 hw/block/xen-block.c
 delete mode 100644 hw/block/xen_disk.c
 create mode 100644 hw/xen/xen-backend.c
 create mode 100644 hw/xen/xen-bus-helper.c
 create mode 100644 hw/xen/xen-bus.c
 rename hw/xen/{xen_backend.c => xen-legacy-backend.c} (89%)
 create mode 100644 include/hw/xen/xen-backend.h
 create mode 100644 include/hw/xen/xen-block.h
 create mode 100644 include/hw/xen/xen-bus-helper.h
 create mode 100644 include/hw/xen/xen-bus.h
 rename include/hw/xen/{xen_backend.h => xen-legacy-backend.h} (61%)
---
Cc: Anthony Perard 
Cc: Eduardo 

Re: [Xen-devel] [PATCH 5/8] viridian: use viridian_map/unmap_guest_page() for reference tsc page

[Paul Durrant]

> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: 07 January 2019 15:48
> To: Paul Durrant 
> Cc: Wei Liu ; xen-devel@lists.xenproject.org; Roger
> Pau Monne ; Jan Beulich ; Andrew
> Cooper 
> Subject: Re: [PATCH 5/8] viridian: use viridian_map/unmap_guest_page() for
> reference tsc page
> 
> On Mon, Jan 07, 2019 at 03:35:41PM +, Paul Durrant wrote:
> [...]
> > > > >const struct viridian_page *vp);
> > > > > -void viridian_map_guest_page(struct vcpu *v, struct viridian_page
> > > *vp);
> > > > > +void viridian_map_guest_page(struct domain *d, struct
> viridian_page
> > > > *vp);
> > > >
> > > > Since you modify this anyway, can you constify struct domain?
> > > >
> > >
> > > Yes, I guess that should be do-able now that the viridian_page is in a
> > > separate allocation unit.
> >
> > Alas, no. The call to get_page_from_gfn() takes a non-const struct
> domain pointer, and I'm not opening that can of worms. Does your R-b still
> stand?
> 
> Yes.

Cool. Thanks :-)

  Paul

> 
> Wei.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v3] x86/dom0: add verbose mode and print memory allocation stats

[Roger Pau Monne]

Add a verbose option to the dom0 command line, so that dom0 builder
can print extra debug information when required.

Use this new verbose mode to print statistics about memory allocations
when populating dom0 p2m.

Signed-off-by: Roger Pau Monné 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Julien Grall 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
Changes since v2:
 - Remove pointless initialization.
 - Print domain id.
 - Change print format.
---
 docs/misc/xen-command-line.pandoc |  8 +++-
 xen/arch/x86/dom0_build.c |  3 +++
 xen/arch/x86/hvm/dom0_build.c | 16 
 xen/include/asm-x86/setup.h   |  1 +
 4 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/docs/misc/xen-command-line.pandoc 
b/docs/misc/xen-command-line.pandoc
index a755a67127..99c283cb10 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -637,7 +637,7 @@ trace feature is only enabled in debugging builds of Xen.
 Specify the bit width of the DMA heap.
 
 ### dom0 (x86)
-> `= List of [ pvh | shadow ]`
+> `= List of [ pvh | shadow | verbose ]`
 
 > Sub-options:
 
@@ -654,6 +654,12 @@ Flag that makes a dom0 boot in PVHv2 mode.
 Flag that makes a dom0 use shadow paging. Only works when "pvh" is
 enabled.
 
+> `verbose`
+
+> Default: `false`
+
+Print debug information during dom0 build.
+
 ### dom0-iommu
 > `= List of [ passthrough | strict | map-inclusive ]`
 
diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
index 54737daf6a..c0bc022a83 100644
--- a/xen/arch/x86/dom0_build.c
+++ b/xen/arch/x86/dom0_build.c
@@ -281,6 +281,7 @@ struct vcpu *__init alloc_dom0_vcpu0(struct domain *dom0)
 bool __initdata opt_dom0_shadow;
 #endif
 bool __initdata dom0_pvh;
+bool __initdata dom0_verbose;
 
 /*
  * List of parameters that affect Dom0 creation:
@@ -306,6 +307,8 @@ static int __init parse_dom0_param(const char *s)
 else if ( (val = parse_boolean("shadow", s, ss)) >= 0 )
 opt_dom0_shadow = val;
 #endif
+else if ( (val = parse_boolean("verbose", s, ss)) >= 0 )
+dom0_verbose = val;
 else
 rc = -EINVAL;
 
diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index 5ae3a32060..303c44b5d9 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -60,6 +60,18 @@ static struct acpi_madt_interrupt_override __initdata 
*intsrcovr;
 static unsigned int __initdata acpi_nmi_sources;
 static struct acpi_madt_nmi_source __initdata *nmisrc;
 
+static unsigned int __initdata order_stats[MAX_ORDER + 1];
+
+static void __init print_order_stats(const struct domain *d)
+{
+unsigned int i;
+
+printk("Dom%u memory allocation stats:\n", d->domain_id);
+for ( i = 0; i < ARRAY_SIZE(order_stats); i++ )
+if ( order_stats[i] )
+printk("order %2u allocations: %u\n", i, order_stats[i]);
+}
+
 static int __init modify_identity_mmio(struct domain *d, unsigned long pfn,
unsigned long nr_pages, const bool map)
 {
@@ -169,6 +181,7 @@ static int __init pvh_populate_memory_range(struct domain 
*d,
 }
 start += 1UL << order;
 nr_pages -= 1UL << order;
+order_stats[order]++;
 if ( (++i % MAP_MAX_ITER) == 0 )
 process_pending_softirqs();
 }
@@ -465,6 +478,9 @@ static int __init pvh_setup_p2m(struct domain *d)
 return rc;
 }
 
+if ( dom0_verbose )
+print_order_stats(d);
+
 return 0;
 #undef MB1_PAGES
 }
diff --git a/xen/include/asm-x86/setup.h b/xen/include/asm-x86/setup.h
index 1c8078340d..bb4c38567c 100644
--- a/xen/include/asm-x86/setup.h
+++ b/xen/include/asm-x86/setup.h
@@ -65,6 +65,7 @@ extern bool opt_dom0_shadow;
 #define opt_dom0_shadow false
 #endif
 extern bool dom0_pvh;
+extern bool dom0_verbose;
 
 #define max_init_domid (0)
 
-- 
2.17.2 (Apple Git-113)


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2 2/4] x86/e820: do not fixup memmap in copy_e820_map

[Jan Beulich]

>>> On 28.12.18 at 13:04,  wrote:
> @@ -510,6 +496,12 @@ static void __init reserve_dmi_region(void)
>  }
>  }
>  
> +static void __init reserve_vga_region(void)
> +{
> +/* Remove any RAM regions from the VGA hole. */
> +e820_remove_range(, KB(640), MB(1) - 1, E820_RAM, true);

From looking at patch 1 I got the impression that the "end" parameter
is exclusive. If that's not intended to be that way, then there may
be further issues with the use of < / <= / > / >= .

I'm also unconvinced of this getting put in a separate function.

Jan



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2 2/2] x86/dom0: add verbose mode and print memory allocation stats

[Roger Pau Monné]

On Mon, Jan 07, 2019 at 03:01:54AM -0700, Jan Beulich wrote:
> >>> On 28.12.18 at 12:18,  wrote:
> > --- a/xen/arch/x86/hvm/dom0_build.c
> > +++ b/xen/arch/x86/hvm/dom0_build.c
> > @@ -60,6 +60,18 @@ static struct acpi_madt_interrupt_override __initdata 
> > *intsrcovr;
> >  static unsigned int __initdata acpi_nmi_sources;
> >  static struct acpi_madt_nmi_source __initdata *nmisrc;
> >  
> > +static unsigned int __initdata order_stats[MAX_ORDER + 1] = { };
> 
> Pointless initializer.
> 
> > +static void __init print_order_stats(void)
> > +{
> > +unsigned int i;
> > +
> > +printk("Memory allocation stats:\n");
> 
> I think this wants prefixing with "Dom0".

I will use Dom%u and d->domain_id.

> > +for ( i = 0; i < ARRAY_SIZE(order_stats); i++ )
> > +if ( order_stats[i] )
> > +printk("order: %2u allocations: %u\n", i, order_stats[i]);
> 
> Why the first of the two colons?

Because it's printing the order, I will remove it in the next version.

Thanks, Roger.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2 1/4] x86/e820: introduce a function to remove ranges from e820

[Jan Beulich]

>>> On 28.12.18 at 13:04,  wrote:
> --- a/xen/arch/x86/e820.c
> +++ b/xen/arch/x86/e820.c
> @@ -599,6 +599,63 @@ int __init e820_add_range(
>  return 1;
>  }
>  
> +uint64_t __init e820_remove_range(struct e820map *e820, uint64_t start,
> +  uint64_t end, uint32_t type, bool 
> check_type)
> +{
> +unsigned int i;
> +uint64_t real_removed_size = 0;
> +
> +ASSERT(end > start);
> +
> +for ( i = 0; i < e820->nr_map; i++ )
> +{
> +struct e820entry *entry = >map[i];
> +uint64_t final_start, final_end, entry_end;
> +
> +if ( check_type && entry->type != type )
> +continue;
> +
> +entry_end = entry->addr + entry->size;
> +
> +/* Completely covered? */
> +if ( entry->addr >= start && entry_end <= end )
> +{
> +real_removed_size += entry->size;
> +memset(entry, 0, sizeof(*entry));

This will break assumptions by other functions, e.g. the
neighboring e820_add_range().

> +continue;
> +}
> +
> +/* Is the new range completely covered? */
> +if ( entry->addr < start && entry_end > end )

Why < and > instead of <= and >= ? At the very least this is
not in line with the comment.

> +{
> +e820_add_range(e820, end, entry_end, entry->type);
> +entry->size = start - entry->addr;
> +real_removed_size += end - start;
> +continue;
> +}
> +
> +/* Partially covered: */
> +final_start = max(start, entry->addr);
> +final_end = min(end, entry_end);
> +if ( final_start >= final_end )
> +continue;

Isn't this supposed to be unreachable?

Jan



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [freebsd-master test] 131783: all pass - PUSHED

[osstest service owner]

flight 131783 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131783/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 freebsd  2a52bc55467e95f92e1024cd558df3930df99594
baseline version:
 freebsd  b65ae50c2b44f3e341ab70a5aa9c658630877191

Last test of basis   131682  2019-01-02 09:19:17 Z5 days
Failing since131733  2019-01-04 09:19:12 Z3 days2 attempts
Testing same since   131783  2019-01-07 09:19:04 Z0 days1 attempts


People who touched revisions under test:
  allanjude 
  avos 
  cem 
  chuck 
  cy 
  dab 
  delphij 
  emaste 
  gallatin 
  gjb 
  hselasky 
  imp 
  jhibbits 
  jilles 
  joerg 
  kevans 
  kib 
  kp 
  markj 
  mmacy 
  np 
  romain 
  trasz 
  tsoome 
  vmaffione 

jobs:
 build-amd64-freebsd-againpass
 build-amd64-freebsd  pass
 build-amd64-xen-freebsd  pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/freebsd.git
   b65ae50c2b4..2a52bc55467  2a52bc55467e95f92e1024cd558df3930df99594 -> 
tested/master

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v8 15/18] xen: add a mechanism to automatically create XenDevice-s...

[Paul Durrant]

...that maintains compatibility with existing Xen toolstacks.

Xen toolstacks instantiate PV backends by simply writing information into
xenstore and expecting a backend implementation to be watching for this.

This patch adds a new 'xen-backend' module to allow individual XenDevice
implementations to register create and destroy functions. The creator
will be called when a tool-stack instantiates a new backend in this way,
and the destructor will then be called after the resulting XenDevice
object is unrealized.

To support this it is also necessary to add new watchers into the XenBus
implementation to handle enumeration of new backends and also destruction
of XenDevice-s when the toolstack sets the backend 'online' key to 0.

NOTE: This patch only adds the framework. A subsequent patch will add a
  creator function for xen-block devices.

Signed-off-by: Paul Durrant 
Reviewed-by: Anthony Perard 
---
Cc: Stefano Stabellini 

v5:
 - Added destructor function, therefore Anthony's R-b is not carried
   from v4

v3:
 - Use a xenstore transaction in enumeration code to ensure consistent
   parameters
 - Not adding Anthony's R-b because of change

v2:
 - Sort out error paths and error reporting
---
 hw/xen/Makefile.objs |   2 +-
 hw/xen/trace-events  |   3 +
 hw/xen/xen-backend.c | 165 +++
 hw/xen/xen-bus.c | 164 +-
 include/hw/xen/xen-backend.h |  39 +
 include/hw/xen/xen-bus.h |   1 +
 include/qemu/module.h|   3 +
 7 files changed, 375 insertions(+), 2 deletions(-)
 create mode 100644 hw/xen/xen-backend.c
 create mode 100644 include/hw/xen/xen-backend.h

diff --git a/hw/xen/Makefile.objs b/hw/xen/Makefile.objs
index 77c0868190..84df60a928 100644
--- a/hw/xen/Makefile.objs
+++ b/hw/xen/Makefile.objs
@@ -1,5 +1,5 @@
 # xen backend driver support
-common-obj-$(CONFIG_XEN) += xen-legacy-backend.o xen_devconfig.o xen_pvdev.o 
xen-common.o xen-bus.o xen-bus-helper.o
+common-obj-$(CONFIG_XEN) += xen-legacy-backend.o xen_devconfig.o xen_pvdev.o 
xen-common.o xen-bus.o xen-bus-helper.o xen-backend.o
 
 obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
 obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o 
xen_pt_graphics.o xen_pt_msi.o
diff --git a/hw/xen/trace-events b/hw/xen/trace-events
index d4651bdb30..f6944624b2 100644
--- a/hw/xen/trace-events
+++ b/hw/xen/trace-events
@@ -16,6 +16,9 @@ xen_domid_restrict(int err) "err: %u"
 # include/hw/xen/xen-bus.c
 xen_bus_realize(void) ""
 xen_bus_unrealize(void) ""
+xen_bus_enumerate(void) ""
+xen_bus_type_enumerate(const char *type) "type: %s"
+xen_bus_backend_create(const char *type, const char *path) "type: %s path: %s"
 xen_bus_add_watch(const char *node, const char *key, char *token) "node: %s 
key: %s token: %s"
 xen_bus_remove_watch(const char *node, const char *key, char *token) "node: %s 
key: %s token: %s"
 xen_bus_watch(const char *token) "token: %s"
diff --git a/hw/xen/xen-backend.c b/hw/xen/xen-backend.c
new file mode 100644
index 00..da065f81b7
--- /dev/null
+++ b/hw/xen/xen-backend.c
@@ -0,0 +1,165 @@
+/*
+ * Copyright (c) 2018  Citrix Systems Inc.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+#include "qemu/osdep.h"
+#include "qemu/error-report.h"
+#include "qapi/error.h"
+#include "hw/xen/xen-backend.h"
+#include "hw/xen/xen-bus.h"
+
+typedef struct XenBackendImpl {
+const char *type;
+XenBackendDeviceCreate create;
+XenBackendDeviceDestroy destroy;
+} XenBackendImpl;
+
+struct XenBackendInstance {
+QLIST_ENTRY(XenBackendInstance) entry;
+const XenBackendImpl *impl;
+XenBus *xenbus;
+char *name;
+XenDevice *xendev;
+};
+
+static GHashTable *xen_backend_table_get(void)
+{
+static GHashTable *table;
+
+if (table == NULL) {
+table = g_hash_table_new(g_str_hash, g_str_equal);
+}
+
+return table;
+}
+
+static void xen_backend_table_add(XenBackendImpl *impl)
+{
+g_hash_table_insert(xen_backend_table_get(), (void *)impl->type, impl);
+}
+
+static const XenBackendImpl *xen_backend_table_lookup(const char *type)
+{
+return g_hash_table_lookup(xen_backend_table_get(), type);
+}
+
+void xen_backend_register(const XenBackendInfo *info)
+{
+XenBackendImpl *impl = g_new0(XenBackendImpl, 1);
+
+g_assert(info->type);
+
+if (xen_backend_table_lookup(info->type)) {
+error_report("attempt to register duplicate Xen backend type '%s'",
+ info->type);
+abort();
+}
+
+if (!info->create) {
+error_report("backend type '%s' has no creator", info->type);
+abort();
+}
+
+impl->type = info->type;
+impl->create = info->create;
+impl->destroy = info->destroy;
+
+xen_backend_table_add(impl);
+}
+
+static QLIST_HEAD(, XenBackendInstance) backend_list;
+
+static void 

Re: [Xen-devel] [PATCH] x86/dom0: change align type to int

[Roger Pau Monné]

On Fri, Jan 04, 2019 at 08:35:38AM -0700, Jan Beulich wrote:
> >>> On 04.01.19 at 16:14,  wrote:
> > There's no reason to use long to store the alignment, since the bigger
> 
> biggest?
> 
> > page size is 1GB, and the alignment is stored as a frame number.
> > 
> > Reported-by: Jan Beulich 
> > Signed-off-by: Roger Pau Monné 
> > ---
> > Cc: Jan Beulich 
> > Cc: Andrew Cooper 
> > Cc: Wei Liu 
> > ---
> >  xen/arch/x86/hvm/dom0_build.c | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> > 
> > diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
> > index 5ae3a32060..b696100043 100644
> > --- a/xen/arch/x86/hvm/dom0_build.c
> > +++ b/xen/arch/x86/hvm/dom0_build.c
> > @@ -92,8 +92,7 @@ static int __init pvh_populate_memory_range(struct domain 
> > *d,
> >  unsigned long nr_pages)
> >  {
> >  struct {
> > -unsigned long align;
> > -unsigned int order;
> > +unsigned int align, order;
> >  } static const __initconst orders[] = {
> >  /* NB: must be sorted by decreasing size. */
> >  { .align = PFN_DOWN(GB(1)), .order = PAGE_ORDER_1G },
> 
> That's not enough afaict, you also need to use 1UL in
> 
> end = (start + nr_pages) & ~(orders[0].align - 1);

Right, I'm afraid I prefer to keep align as unsigned long in order to
avoid such mistakes.

Thanks, Roger.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v8 10/18] xen: add header and build dataplane/xen-block.c

[Paul Durrant]

This patch adds the transformations necessary to get dataplane/xen-block.c
to build against the new XenBus/XenDevice framework. MAINTAINERS is also
updated due to the introduction of dataplane/xen-block.h.

NOTE: Existing data structure names are retained for the moment. These will
  be modified by subsequent patches. A typedef for XenBlockDataPlane
  has been added to the header (based on the old struct XenBlkDev name
  for the moment) so that the old names don't need to leak out of the
  dataplane code.

Signed-off-by: Paul Durrant 
Reviewed-by: Anthony Perard 
---
Cc: Stefan Hajnoczi 
Cc: Kevin Wolf 
Cc: Max Reitz 
Cc: Stefano Stabellini 

v2:
 - Tidy up header inclusions
 - Get rid of error_fatal
---
 MAINTAINERS  |   1 +
 hw/block/dataplane/Makefile.objs |   1 +
 hw/block/dataplane/xen-block.c   | 356 ++-
 hw/block/dataplane/xen-block.h   |  29 +++
 4 files changed, 287 insertions(+), 100 deletions(-)
 create mode 100644 hw/block/dataplane/xen-block.h

diff --git a/MAINTAINERS b/MAINTAINERS
index f730d6c3cc..aeac96401d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -419,6 +419,7 @@ F: hw/block/dataplane/xen*
 F: hw/xen/
 F: hw/xenpv/
 F: hw/i386/xen/
+F: include/hw/block/dataplane/xen*
 F: include/hw/xen/
 F: include/sysemu/xen-mapcache.h
 
diff --git a/hw/block/dataplane/Makefile.objs b/hw/block/dataplane/Makefile.objs
index e786f66421..c6c68dbc00 100644
--- a/hw/block/dataplane/Makefile.objs
+++ b/hw/block/dataplane/Makefile.objs
@@ -1 +1,2 @@
 obj-y += virtio-blk.o
+obj-$(CONFIG_XEN) += xen-block.o
diff --git a/hw/block/dataplane/xen-block.c b/hw/block/dataplane/xen-block.c
index 228472320a..ed2b91 100644
--- a/hw/block/dataplane/xen-block.c
+++ b/hw/block/dataplane/xen-block.c
@@ -18,65 +18,53 @@
  * GNU GPL, version 2 or (at your option) any later version.
  */
 
+#include "qemu/osdep.h"
+#include "qemu/error-report.h"
+#include "qapi/error.h"
+#include "hw/hw.h"
+#include "hw/xen/xen_common.h"
+#include "hw/block/xen_blkif.h"
+#include "sysemu/block-backend.h"
+#include "sysemu/iothread.h"
+#include "xen-block.h"
+
 struct ioreq {
-blkif_request_t req;
-int16_t status;
-
-/* parsed request */
-off_t   start;
-QEMUIOVectorv;
-void*buf;
-size_t  size;
-int presync;
-
-/* aio status */
-int aio_inflight;
-int aio_errors;
-
-struct XenBlkDev*blkdev;
-QLIST_ENTRY(ioreq)   list;
-BlockAcctCookie acct;
+blkif_request_t req;
+int16_t status;
+off_t start;
+QEMUIOVector v;
+void *buf;
+size_t size;
+int presync;
+int aio_inflight;
+int aio_errors;
+struct XenBlkDev *blkdev;
+QLIST_ENTRY(ioreq) list;
+BlockAcctCookie acct;
 };
 
-#define MAX_RING_PAGE_ORDER 4
-
 struct XenBlkDev {
-struct XenLegacyDevicexendev;  /* must be first */
-char*params;
-char*mode;
-char*type;
-char*dev;
-char*devtype;
-booldirectiosafe;
-const char  *fileproto;
-const char  *filename;
-unsigned intring_ref[1 << MAX_RING_PAGE_ORDER];
-unsigned intnr_ring_ref;
-void*sring;
-int64_t file_blk;
-int64_t file_size;
-int protocol;
-blkif_back_rings_t  rings;
-int more_work;
-
-/* request lists */
+XenDevice *xendev;
+XenEventChannel *event_channel;
+unsigned int *ring_ref;
+unsigned int nr_ring_ref;
+void *sring;
+int64_t file_blk;
+int64_t file_size;
+int protocol;
+blkif_back_rings_t rings;
+int more_work;
 QLIST_HEAD(inflight_head, ioreq) inflight;
 QLIST_HEAD(finished_head, ioreq) finished;
 QLIST_HEAD(freelist_head, ioreq) freelist;
-int requests_total;
-int requests_inflight;
-int requests_finished;
-unsigned intmax_requests;
-
-gbooleanfeature_discard;
-
-/* qemu block driver */
-DriveInfo   *dinfo;
-BlockBackend*blk;
-QEMUBH  *bh;
-
-IOThread*iothread;
-AioContext  *ctx;
+int requests_total;
+int requests_inflight;
+int requests_finished;
+unsigned int max_requests;
+BlockBackend *blk;
+QEMUBH *bh;
+IOThread *iothread;
+AioContext *ctx;
 };
 
 static void ioreq_reset(struct ioreq *ioreq)
@@ -155,7 +143,6 @@ static void ioreq_release(struct ioreq *ioreq, bool finish)
 static int ioreq_parse(struct ioreq *ioreq)
 {
 struct XenBlkDev *blkdev = ioreq->blkdev;
-struct XenLegacyDevice *xendev = >xendev;
 size_t len;
 int i;
 
@@ -177,7 +164,8 @@ static int ioreq_parse(struct ioreq *ioreq)
 goto err;
 };
 
-

[Xen-devel] [PATCH v8 11/18] xen: remove 'XenBlkDev' and 'blkdev' names from dataplane/xen-block

[Paul Durrant]

This is a purely cosmetic patch that substitutes the old 'struct XenBlkDev'
name with 'XenBlockDataPlane' and 'blkdev' field/variable names with
'dataplane', and then does necessary fix-up to adhere to coding style.

No functional change.

Signed-off-by: Paul Durrant 
Acked-by: Anthony Perard 
---
Cc: Stefano Stabellini 
Cc: Stefan Hajnoczi 
Cc: Kevin Wolf 
Cc: Max Reitz 
---
 hw/block/dataplane/xen-block.c | 352 +
 hw/block/dataplane/xen-block.h |   2 +-
 2 files changed, 183 insertions(+), 171 deletions(-)

diff --git a/hw/block/dataplane/xen-block.c b/hw/block/dataplane/xen-block.c
index ed2b91..1ff464973c 100644
--- a/hw/block/dataplane/xen-block.c
+++ b/hw/block/dataplane/xen-block.c
@@ -38,12 +38,12 @@ struct ioreq {
 int presync;
 int aio_inflight;
 int aio_errors;
-struct XenBlkDev *blkdev;
+XenBlockDataPlane *dataplane;
 QLIST_ENTRY(ioreq) list;
 BlockAcctCookie acct;
 };
 
-struct XenBlkDev {
+struct XenBlockDataPlane {
 XenDevice *xendev;
 XenEventChannel *event_channel;
 unsigned int *ring_ref;
@@ -79,33 +79,33 @@ static void ioreq_reset(struct ioreq *ioreq)
 ioreq->aio_inflight = 0;
 ioreq->aio_errors = 0;
 
-ioreq->blkdev = NULL;
+ioreq->dataplane = NULL;
 memset(>list, 0, sizeof(ioreq->list));
 memset(>acct, 0, sizeof(ioreq->acct));
 
 qemu_iovec_reset(>v);
 }
 
-static struct ioreq *ioreq_start(struct XenBlkDev *blkdev)
+static struct ioreq *ioreq_start(XenBlockDataPlane *dataplane)
 {
 struct ioreq *ioreq = NULL;
 
-if (QLIST_EMPTY(>freelist)) {
-if (blkdev->requests_total >= blkdev->max_requests) {
+if (QLIST_EMPTY(>freelist)) {
+if (dataplane->requests_total >= dataplane->max_requests) {
 goto out;
 }
 /* allocate new struct */
 ioreq = g_malloc0(sizeof(*ioreq));
-ioreq->blkdev = blkdev;
-blkdev->requests_total++;
+ioreq->dataplane = dataplane;
+dataplane->requests_total++;
 qemu_iovec_init(>v, 1);
 } else {
 /* get one from freelist */
-ioreq = QLIST_FIRST(>freelist);
+ioreq = QLIST_FIRST(>freelist);
 QLIST_REMOVE(ioreq, list);
 }
-QLIST_INSERT_HEAD(>inflight, ioreq, list);
-blkdev->requests_inflight++;
+QLIST_INSERT_HEAD(>inflight, ioreq, list);
+dataplane->requests_inflight++;
 
 out:
 return ioreq;
@@ -113,26 +113,26 @@ out:
 
 static void ioreq_finish(struct ioreq *ioreq)
 {
-struct XenBlkDev *blkdev = ioreq->blkdev;
+XenBlockDataPlane *dataplane = ioreq->dataplane;
 
 QLIST_REMOVE(ioreq, list);
-QLIST_INSERT_HEAD(>finished, ioreq, list);
-blkdev->requests_inflight--;
-blkdev->requests_finished++;
+QLIST_INSERT_HEAD(>finished, ioreq, list);
+dataplane->requests_inflight--;
+dataplane->requests_finished++;
 }
 
 static void ioreq_release(struct ioreq *ioreq, bool finish)
 {
-struct XenBlkDev *blkdev = ioreq->blkdev;
+XenBlockDataPlane *dataplane = ioreq->dataplane;
 
 QLIST_REMOVE(ioreq, list);
 ioreq_reset(ioreq);
-ioreq->blkdev = blkdev;
-QLIST_INSERT_HEAD(>freelist, ioreq, list);
+ioreq->dataplane = dataplane;
+QLIST_INSERT_HEAD(>freelist, ioreq, list);
 if (finish) {
-blkdev->requests_finished--;
+dataplane->requests_finished--;
 } else {
-blkdev->requests_inflight--;
+dataplane->requests_inflight--;
 }
 }
 
@@ -142,7 +142,7 @@ static void ioreq_release(struct ioreq *ioreq, bool finish)
  */
 static int ioreq_parse(struct ioreq *ioreq)
 {
-struct XenBlkDev *blkdev = ioreq->blkdev;
+XenBlockDataPlane *dataplane = ioreq->dataplane;
 size_t len;
 int i;
 
@@ -165,12 +165,12 @@ static int ioreq_parse(struct ioreq *ioreq)
 };
 
 if (ioreq->req.operation != BLKIF_OP_READ &&
-blk_is_read_only(blkdev->blk)) {
+blk_is_read_only(dataplane->blk)) {
 error_report("error: write req for ro device");
 goto err;
 }
 
-ioreq->start = ioreq->req.sector_number * blkdev->file_blk;
+ioreq->start = ioreq->req.sector_number * dataplane->file_blk;
 for (i = 0; i < ioreq->req.nr_segments; i++) {
 if (i == BLKIF_MAX_SEGMENTS_PER_REQUEST) {
 error_report("error: nr_segments too big");
@@ -180,16 +180,16 @@ static int ioreq_parse(struct ioreq *ioreq)
 error_report("error: first > last sector");
 goto err;
 }
-if (ioreq->req.seg[i].last_sect * blkdev->file_blk >= XC_PAGE_SIZE) {
+if (ioreq->req.seg[i].last_sect * dataplane->file_blk >= XC_PAGE_SIZE) 
{
 error_report("error: page crossing");
 goto err;
 }
 
 len = (ioreq->req.seg[i].last_sect -
-   ioreq->req.seg[i].first_sect + 1) * blkdev->file_blk;
+   ioreq->req.seg[i].first_sect + 1) * dataplane->file_blk;
 ioreq->size += len;
 }
-if (ioreq->start + ioreq->size > 

[Xen-devel] [PATCH v8 12/18] xen: remove 'ioreq' struct/varable/field names from dataplane/xen-block.c

[Paul Durrant]

This is a purely cosmetic patch that purges the name 'ioreq' from struct,
variable and field names. (This name has been problematic for a long time
as 'ioreq' is the name used for generic I/O requests coming from Xen).
The patch replaces 'struct ioreq' with a new 'XenBlockRequest' type and
'ioreq' field/variable names with 'request', and then does necessary
fix-up to adhere to coding style.

Function names are not modified by this patch. They will be dealt with in
a subsequent patch.

No functional change.

Signed-off-by: Paul Durrant 
Acked-by: Anthony Perard 
---
Cc: Stefan Hajnoczi 
Cc: Stefano Stabellini 
Cc: Kevin Wolf 
Cc: Max Reitz 
---
 hw/block/dataplane/xen-block.c | 310 +
 1 file changed, 156 insertions(+), 154 deletions(-)

diff --git a/hw/block/dataplane/xen-block.c b/hw/block/dataplane/xen-block.c
index 1ff464973c..6788bbf338 100644
--- a/hw/block/dataplane/xen-block.c
+++ b/hw/block/dataplane/xen-block.c
@@ -28,7 +28,7 @@
 #include "sysemu/iothread.h"
 #include "xen-block.h"
 
-struct ioreq {
+typedef struct XenBlockRequest {
 blkif_request_t req;
 int16_t status;
 off_t start;
@@ -39,9 +39,9 @@ struct ioreq {
 int aio_inflight;
 int aio_errors;
 XenBlockDataPlane *dataplane;
-QLIST_ENTRY(ioreq) list;
+QLIST_ENTRY(XenBlockRequest) list;
 BlockAcctCookie acct;
-};
+} XenBlockRequest;
 
 struct XenBlockDataPlane {
 XenDevice *xendev;
@@ -54,9 +54,9 @@ struct XenBlockDataPlane {
 int protocol;
 blkif_back_rings_t rings;
 int more_work;
-QLIST_HEAD(inflight_head, ioreq) inflight;
-QLIST_HEAD(finished_head, ioreq) finished;
-QLIST_HEAD(freelist_head, ioreq) freelist;
+QLIST_HEAD(inflight_head, XenBlockRequest) inflight;
+QLIST_HEAD(finished_head, XenBlockRequest) finished;
+QLIST_HEAD(freelist_head, XenBlockRequest) freelist;
 int requests_total;
 int requests_inflight;
 int requests_finished;
@@ -67,68 +67,68 @@ struct XenBlockDataPlane {
 AioContext *ctx;
 };
 
-static void ioreq_reset(struct ioreq *ioreq)
+static void ioreq_reset(XenBlockRequest *request)
 {
-memset(>req, 0, sizeof(ioreq->req));
-ioreq->status = 0;
-ioreq->start = 0;
-ioreq->buf = NULL;
-ioreq->size = 0;
-ioreq->presync = 0;
+memset(>req, 0, sizeof(request->req));
+request->status = 0;
+request->start = 0;
+request->buf = NULL;
+request->size = 0;
+request->presync = 0;
 
-ioreq->aio_inflight = 0;
-ioreq->aio_errors = 0;
+request->aio_inflight = 0;
+request->aio_errors = 0;
 
-ioreq->dataplane = NULL;
-memset(>list, 0, sizeof(ioreq->list));
-memset(>acct, 0, sizeof(ioreq->acct));
+request->dataplane = NULL;
+memset(>list, 0, sizeof(request->list));
+memset(>acct, 0, sizeof(request->acct));
 
-qemu_iovec_reset(>v);
+qemu_iovec_reset(>v);
 }
 
-static struct ioreq *ioreq_start(XenBlockDataPlane *dataplane)
+static XenBlockRequest *ioreq_start(XenBlockDataPlane *dataplane)
 {
-struct ioreq *ioreq = NULL;
+XenBlockRequest *request = NULL;
 
 if (QLIST_EMPTY(>freelist)) {
 if (dataplane->requests_total >= dataplane->max_requests) {
 goto out;
 }
 /* allocate new struct */
-ioreq = g_malloc0(sizeof(*ioreq));
-ioreq->dataplane = dataplane;
+request = g_malloc0(sizeof(*request));
+request->dataplane = dataplane;
 dataplane->requests_total++;
-qemu_iovec_init(>v, 1);
+qemu_iovec_init(>v, 1);
 } else {
 /* get one from freelist */
-ioreq = QLIST_FIRST(>freelist);
-QLIST_REMOVE(ioreq, list);
+request = QLIST_FIRST(>freelist);
+QLIST_REMOVE(request, list);
 }
-QLIST_INSERT_HEAD(>inflight, ioreq, list);
+QLIST_INSERT_HEAD(>inflight, request, list);
 dataplane->requests_inflight++;
 
 out:
-return ioreq;
+return request;
 }
 
-static void ioreq_finish(struct ioreq *ioreq)
+static void ioreq_finish(XenBlockRequest *request)
 {
-XenBlockDataPlane *dataplane = ioreq->dataplane;
+XenBlockDataPlane *dataplane = request->dataplane;
 
-QLIST_REMOVE(ioreq, list);
-QLIST_INSERT_HEAD(>finished, ioreq, list);
+QLIST_REMOVE(request, list);
+QLIST_INSERT_HEAD(>finished, request, list);
 dataplane->requests_inflight--;
 dataplane->requests_finished++;
 }
 
-static void ioreq_release(struct ioreq *ioreq, bool finish)
+static void ioreq_release(XenBlockRequest *request, bool finish)
 {
-XenBlockDataPlane *dataplane = ioreq->dataplane;
+XenBlockDataPlane *dataplane = request->dataplane;
 
-QLIST_REMOVE(ioreq, list);
-ioreq_reset(ioreq);
-ioreq->dataplane = dataplane;
-QLIST_INSERT_HEAD(>freelist, ioreq, list);
+QLIST_REMOVE(request, list);
+ioreq_reset(request);
+request->dataplane = dataplane;
+QLIST_INSERT_HEAD(>freelist, request, list);
 if (finish) {
 dataplane->requests_finished--;
   

[Xen-devel] [PATCH v8 17/18] MAINTAINERS: add myself as a Xen maintainer

[Paul Durrant]

I have made many significant contributions to the Xen code in QEMU,
particularly the recent patches introducing a new PV device framework.
I intend to make further significant contributions, porting other PV back-
ends to the new framework with the intent of eventually removing the
legacy code. It therefore seems reasonable that I become a maintainer of
the Xen code.

Signed-off-by: Paul Durrant 
Acked-by: Anthony Perard 
Acked-by: Stefano Stabellini 
---
Cc: Paolo Bonzini 

v2:
 - Fix typo
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index aeac96401d..02df9765df 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -407,6 +407,7 @@ Guest CPU Cores (Xen):
 X86
 M: Stefano Stabellini 
 M: Anthony Perard 
+M: Paul Durrant 
 L: xen-devel@lists.xenproject.org
 S: Supported
 F: */xen*
-- 
2.20.1.2.gb21ebb6


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v8 13/18] xen: purge 'blk' and 'ioreq' from function names in dataplane/xen-block.c

[Paul Durrant]

This is a purely cosmetic patch that purges remaining use of 'blk' and
'ioreq' in local function names, and then makes sure all functions are
prefixed with 'xen_block_'.

No functional change.

Signed-off-by: Paul Durrant 
Acked-by: Anthony Perard 
---
Cc: Stefano Stabellini 
Cc: Stefan Hajnoczi 
Cc: Kevin Wolf 
Cc: Max Reitz 

v2:
 - Add 'xen_block_' prefix
---
 hw/block/dataplane/xen-block.c | 90 +-
 1 file changed, 46 insertions(+), 44 deletions(-)

diff --git a/hw/block/dataplane/xen-block.c b/hw/block/dataplane/xen-block.c
index 6788bbf338..8e3965e171 100644
--- a/hw/block/dataplane/xen-block.c
+++ b/hw/block/dataplane/xen-block.c
@@ -67,7 +67,7 @@ struct XenBlockDataPlane {
 AioContext *ctx;
 };
 
-static void ioreq_reset(XenBlockRequest *request)
+static void reset_request(XenBlockRequest *request)
 {
 memset(>req, 0, sizeof(request->req));
 request->status = 0;
@@ -86,7 +86,7 @@ static void ioreq_reset(XenBlockRequest *request)
 qemu_iovec_reset(>v);
 }
 
-static XenBlockRequest *ioreq_start(XenBlockDataPlane *dataplane)
+static XenBlockRequest *xen_block_start_request(XenBlockDataPlane *dataplane)
 {
 XenBlockRequest *request = NULL;
 
@@ -111,7 +111,7 @@ out:
 return request;
 }
 
-static void ioreq_finish(XenBlockRequest *request)
+static void xen_block_finish_request(XenBlockRequest *request)
 {
 XenBlockDataPlane *dataplane = request->dataplane;
 
@@ -121,12 +121,12 @@ static void ioreq_finish(XenBlockRequest *request)
 dataplane->requests_finished++;
 }
 
-static void ioreq_release(XenBlockRequest *request, bool finish)
+static void xen_block_release_request(XenBlockRequest *request, bool finish)
 {
 XenBlockDataPlane *dataplane = request->dataplane;
 
 QLIST_REMOVE(request, list);
-ioreq_reset(request);
+reset_request(request);
 request->dataplane = dataplane;
 QLIST_INSERT_HEAD(>freelist, request, list);
 if (finish) {
@@ -140,7 +140,7 @@ static void ioreq_release(XenBlockRequest *request, bool 
finish)
  * translate request into iovec + start offset
  * do sanity checks along the way
  */
-static int ioreq_parse(XenBlockRequest *request)
+static int xen_block_parse_request(XenBlockRequest *request)
 {
 XenBlockDataPlane *dataplane = request->dataplane;
 size_t len;
@@ -201,7 +201,7 @@ err:
 return -1;
 }
 
-static int ioreq_grant_copy(XenBlockRequest *request)
+static int xen_block_copy_request(XenBlockRequest *request)
 {
 XenBlockDataPlane *dataplane = request->dataplane;
 XenDevice *xendev = dataplane->xendev;
@@ -247,9 +247,9 @@ static int ioreq_grant_copy(XenBlockRequest *request)
 return 0;
 }
 
-static int ioreq_runio_qemu_aio(XenBlockRequest *request);
+static int xen_block_do_aio(XenBlockRequest *request);
 
-static void qemu_aio_complete(void *opaque, int ret)
+static void xen_block_complete_aio(void *opaque, int ret)
 {
 XenBlockRequest *request = opaque;
 XenBlockDataPlane *dataplane = request->dataplane;
@@ -266,7 +266,7 @@ static void qemu_aio_complete(void *opaque, int ret)
 request->aio_inflight--;
 if (request->presync) {
 request->presync = 0;
-ioreq_runio_qemu_aio(request);
+xen_block_do_aio(request);
 goto done;
 }
 if (request->aio_inflight > 0) {
@@ -277,7 +277,7 @@ static void qemu_aio_complete(void *opaque, int ret)
 case BLKIF_OP_READ:
 /* in case of failure request->aio_errors is increased */
 if (ret == 0) {
-ioreq_grant_copy(request);
+xen_block_copy_request(request);
 }
 qemu_vfree(request->buf);
 break;
@@ -293,7 +293,7 @@ static void qemu_aio_complete(void *opaque, int ret)
 }
 
 request->status = request->aio_errors ? BLKIF_RSP_ERROR : BLKIF_RSP_OKAY;
-ioreq_finish(request);
+xen_block_finish_request(request);
 
 switch (request->req.operation) {
 case BLKIF_OP_WRITE:
@@ -318,9 +318,9 @@ done:
 aio_context_release(dataplane->ctx);
 }
 
-static bool blk_split_discard(XenBlockRequest *request,
-  blkif_sector_t sector_number,
-  uint64_t nr_sectors)
+static bool xen_block_split_discard(XenBlockRequest *request,
+blkif_sector_t sector_number,
+uint64_t nr_sectors)
 {
 XenBlockDataPlane *dataplane = request->dataplane;
 int64_t byte_offset;
@@ -343,7 +343,7 @@ static bool blk_split_discard(XenBlockRequest *request,
 byte_chunk = byte_remaining > limit ? limit : byte_remaining;
 request->aio_inflight++;
 blk_aio_pdiscard(dataplane->blk, byte_offset, byte_chunk,
- qemu_aio_complete, request);
+ xen_block_complete_aio, request);
 byte_remaining -= byte_chunk;
 byte_offset += byte_chunk;
 } while (byte_remaining > 0);
@@ -351,7 +351,7 @@ static bool 

[Xen-devel] [PATCH v8 14/18] xen: add implementations of xen-block connect and disconnect functions...

[Paul Durrant]

...and wire in the dataplane.

This patch adds the remaining code to make the xen-block XenDevice
functional. The parameters that a block frontend expects to find are
populated in the backend xenstore area, and the 'ring-ref' and
'event-channel' values specified in the frontend xenstore area are
mapped/bound and used to set up the dataplane.

Signed-off-by: Paul Durrant 
Reviewed-by: Anthony Perard 
---
Cc: Stefano Stabellini 
Cc: Kevin Wolf 
Cc: Max Reitz 

v5:
 - Re-base

v3:
 - Add missing return statement to xen_block_realize()
 - Set device name to 'vbd' now the backend is functional
 - Add an unplug handler
 - Move backend watch code from subsequent patch since it's now needed
   to handle unplug

v2:
 - Tidy up header inclusions
 - Stop leaking ring_ref on error
 - Auto-create drive for CDRom devices
---
 hw/block/xen-block.c   | 166 
 hw/xen/trace-events|   3 +
 hw/xen/xen-bus.c   | 187 -
 include/hw/xen/xen-block.h |   9 ++
 include/hw/xen/xen-bus.h   |  14 ++-
 5 files changed, 353 insertions(+), 26 deletions(-)

diff --git a/hw/block/xen-block.c b/hw/block/xen-block.c
index 3a963b0383..a7c37c185a 100644
--- a/hw/block/xen-block.c
+++ b/hw/block/xen-block.c
@@ -10,7 +10,13 @@
 #include "qapi/error.h"
 #include "qapi/visitor.h"
 #include "hw/hw.h"
+#include "hw/xen/xen_common.h"
+#include "hw/block/xen_blkif.h"
 #include "hw/xen/xen-block.h"
+#include "sysemu/blockdev.h"
+#include "sysemu/block-backend.h"
+#include "sysemu/iothread.h"
+#include "dataplane/xen-block.h"
 #include "trace.h"
 
 static char *xen_block_get_name(XenDevice *xendev, Error **errp)
@@ -28,6 +34,8 @@ static void xen_block_disconnect(XenDevice *xendev, Error 
**errp)
 XenBlockVdev *vdev = >props.vdev;
 
 trace_xen_block_disconnect(type, vdev->disk, vdev->partition);
+
+xen_block_dataplane_stop(blockdev->dataplane);
 }
 
 static void xen_block_connect(XenDevice *xendev, Error **errp)
@@ -35,8 +43,72 @@ static void xen_block_connect(XenDevice *xendev, Error 
**errp)
 XenBlockDevice *blockdev = XEN_BLOCK_DEVICE(xendev);
 const char *type = object_get_typename(OBJECT(blockdev));
 XenBlockVdev *vdev = >props.vdev;
+unsigned int order, nr_ring_ref, *ring_ref, event_channel, protocol;
+char *str;
 
 trace_xen_block_connect(type, vdev->disk, vdev->partition);
+
+if (xen_device_frontend_scanf(xendev, "ring-page-order", "%u",
+  ) != 1) {
+nr_ring_ref = 1;
+ring_ref = g_new(unsigned int, nr_ring_ref);
+
+if (xen_device_frontend_scanf(xendev, "ring-ref", "%u",
+  _ref[0]) != 1) {
+error_setg(errp, "failed to read ring-ref");
+g_free(ring_ref);
+return;
+}
+} else if (order <= blockdev->props.max_ring_page_order) {
+unsigned int i;
+
+nr_ring_ref = 1 << order;
+ring_ref = g_new(unsigned int, nr_ring_ref);
+
+for (i = 0; i < nr_ring_ref; i++) {
+const char *key = g_strdup_printf("ring-ref%u", i);
+
+if (xen_device_frontend_scanf(xendev, key, "%u",
+  _ref[i]) != 1) {
+error_setg(errp, "failed to read %s", key);
+g_free((gpointer)key);
+g_free(ring_ref);
+return;
+}
+
+g_free((gpointer)key);
+}
+} else {
+error_setg(errp, "invalid ring-page-order (%d)", order);
+return;
+}
+
+if (xen_device_frontend_scanf(xendev, "event-channel", "%u",
+  _channel) != 1) {
+error_setg(errp, "failed to read event-channel");
+g_free(ring_ref);
+return;
+}
+
+if (xen_device_frontend_scanf(xendev, "protocol", "%ms",
+  ) != 1) {
+protocol = BLKIF_PROTOCOL_NATIVE;
+} else {
+if (strcmp(str, XEN_IO_PROTO_ABI_X86_32) == 0) {
+protocol = BLKIF_PROTOCOL_X86_32;
+} else if (strcmp(str, XEN_IO_PROTO_ABI_X86_64) == 0) {
+protocol = BLKIF_PROTOCOL_X86_64;
+} else {
+protocol = BLKIF_PROTOCOL_NATIVE;
+}
+
+free(str);
+}
+
+xen_block_dataplane_start(blockdev->dataplane, ring_ref, nr_ring_ref,
+  event_channel, protocol, errp);
+
+g_free(ring_ref);
 }
 
 static void xen_block_unrealize(XenDevice *xendev, Error **errp)
@@ -56,6 +128,9 @@ static void xen_block_unrealize(XenDevice *xendev, Error 
**errp)
 /* Disconnect from the frontend in case this has not already happened */
 xen_block_disconnect(xendev, NULL);
 
+xen_block_dataplane_destroy(blockdev->dataplane);
+blockdev->dataplane = NULL;
+
 if (blockdev_class->unrealize) {
 blockdev_class->unrealize(blockdev, errp);
 }
@@ -68,6 +143,7 @@ static void xen_block_realize(XenDevice *xendev, 

[Xen-devel] [PATCH v8 16/18] xen: automatically create XenBlockDevice-s

[Paul Durrant]

This patch adds create and destroy function for XenBlockDevice-s so that
they can be created automatically when the Xen toolstack instantiates a new
PV backend via xenstore. When the XenBlockDevice is created this way it is
also necessary to create a 'drive' which matches the configuration that the
Xen toolstack has written into xenstore. This is done by formulating the
parameters necessary for each 'blockdev' layer of the drive and then using
qmp_blockdev_add() to create the layers. Also, for compatibility with the
legacy 'xen_disk' implementation, an iothread is automatically created for
the new XenBlockDevice. This, like the driver layers, will be destroyed
after the XenBlockDevice is unrealized.

The legacy backend scan for 'qdisk' is removed by this patch, which makes
the 'xen_disk' code is redundant. The code will be removed by a subsequent
patch.

Signed-off-by: Paul Durrant 
---
Cc: Anthony Perard 
Cc: Kevin Wolf 
Cc: Max Reitz 
Cc: Stefano Stabellini 

v8:
 - Add 'raw' image layer for raw images

v7:
 - Don't use qobject_input_visitor_new_flat_confused()

v5:
 - Extensively re-worked to avoid using drive_new() and use
   qmp_blockdev_add() instead
 - Also use qmp_object_add() for IOThread
 - Dropped Anthony's R-b because of the code changes

v2:
 - Get rid of error_abort
 - Don't use qdev_init_nofail()
 - Explain why file locking needs to be off
---
 hw/block/trace-events   |   4 +
 hw/block/xen-block.c| 399 
 hw/xen/xen-legacy-backend.c |   1 -
 include/hw/xen/xen-block.h  |  13 ++
 4 files changed, 416 insertions(+), 1 deletion(-)

diff --git a/hw/block/trace-events b/hw/block/trace-events
index 89e258319c..55e5a5500c 100644
--- a/hw/block/trace-events
+++ b/hw/block/trace-events
@@ -137,3 +137,7 @@ xen_disk_realize(void) ""
 xen_disk_unrealize(void) ""
 xen_cdrom_realize(void) ""
 xen_cdrom_unrealize(void) ""
+xen_block_blockdev_add(char *str) "%s"
+xen_block_blockdev_del(const char *node_name) "%s"
+xen_block_device_create(unsigned int number) "%u"
+xen_block_device_destroy(unsigned int number) "%u"
diff --git a/hw/block/xen-block.c b/hw/block/xen-block.c
index a7c37c185a..91f5b58993 100644
--- a/hw/block/xen-block.c
+++ b/hw/block/xen-block.c
@@ -7,12 +7,20 @@
 
 #include "qemu/osdep.h"
 #include "qemu/cutils.h"
+#include "qemu/option.h"
 #include "qapi/error.h"
+#include "qapi/qapi-commands-block-core.h"
+#include "qapi/qapi-commands-misc.h"
+#include "qapi/qapi-visit-block-core.h"
+#include "qapi/qobject-input-visitor.h"
 #include "qapi/visitor.h"
+#include "qapi/qmp/qdict.h"
+#include "qapi/qmp/qstring.h"
 #include "hw/hw.h"
 #include "hw/xen/xen_common.h"
 #include "hw/block/xen_blkif.h"
 #include "hw/xen/xen-block.h"
+#include "hw/xen/xen-backend.h"
 #include "sysemu/blockdev.h"
 #include "sysemu/block-backend.h"
 #include "sysemu/iothread.h"
@@ -474,6 +482,7 @@ static void xen_block_class_init(ObjectClass *class, void 
*data)
 DeviceClass *dev_class = DEVICE_CLASS(class);
 XenDeviceClass *xendev_class = XEN_DEVICE_CLASS(class);
 
+xendev_class->backend = "qdisk";
 xendev_class->device = "vbd";
 xendev_class->get_name = xen_block_get_name;
 xendev_class->realize = xen_block_realize;
@@ -586,3 +595,393 @@ static void xen_block_register_types(void)
 }
 
 type_init(xen_block_register_types)
+
+static void xen_block_blockdev_del(const char *node_name, Error **errp)
+{
+trace_xen_block_blockdev_del(node_name);
+
+qmp_blockdev_del(node_name, errp);
+}
+
+static char *xen_block_blockdev_add(const char *id, QDict *qdict,
+Error **errp)
+{
+const char *driver = qdict_get_try_str(qdict, "driver");
+BlockdevOptions *options = NULL;
+Error *local_err = NULL;
+char *node_name;
+Visitor *v;
+
+if (!driver) {
+error_setg(errp, "no 'driver' parameter");
+return NULL;
+}
+
+node_name = g_strdup_printf("%s-%s", id, driver);
+qdict_put_str(qdict, "node-name", node_name);
+
+trace_xen_block_blockdev_add(node_name);
+
+v = qobject_input_visitor_new(QOBJECT(qdict));
+visit_type_BlockdevOptions(v, NULL, , _err);
+visit_free(v);
+
+if (local_err) {
+error_propagate(errp, local_err);
+goto fail;
+}
+
+qmp_blockdev_add(options, _err);
+
+if (local_err) {
+error_propagate(errp, local_err);
+goto fail;
+}
+
+qapi_free_BlockdevOptions(options);
+
+return node_name;
+
+fail:
+if (options) {
+qapi_free_BlockdevOptions(options);
+}
+g_free(node_name);
+
+return NULL;
+}
+
+static void xen_block_drive_destroy(XenBlockDrive *drive, Error **errp)
+{
+while (drive->layers-- != 0) {
+char *node_name = drive->node_name[drive->layers];
+Error *local_err = NULL;
+
+xen_block_blockdev_del(node_name, _err);
+if (local_err) {
+error_propagate(errp, local_err);
+drive->layers++;
+return;
+

[Xen-devel] [PATCH v8 18/18] xen: remove the legacy 'xen_disk' backend

[Paul Durrant]

This backend has now been replaced by the 'xen-qdisk' XenDevice.

Signed-off-by: Paul Durrant 
Acked-by: Anthony Perard 
---
Cc: Kevin Wolf 
Cc: Max Reitz 
Cc: Stefano Stabellini 
---
 hw/block/Makefile.objs |1 -
 hw/block/xen_disk.c| 1011 
 2 files changed, 1012 deletions(-)
 delete mode 100644 hw/block/xen_disk.c

diff --git a/hw/block/Makefile.objs b/hw/block/Makefile.objs
index f34813a377..e206b8e712 100644
--- a/hw/block/Makefile.objs
+++ b/hw/block/Makefile.objs
@@ -5,7 +5,6 @@ common-obj-$(CONFIG_NAND) += nand.o
 common-obj-$(CONFIG_PFLASH_CFI01) += pflash_cfi01.o
 common-obj-$(CONFIG_PFLASH_CFI02) += pflash_cfi02.o
 common-obj-$(CONFIG_XEN) += xen-block.o
-common-obj-$(CONFIG_XEN) += xen_disk.o
 common-obj-$(CONFIG_ECC) += ecc.o
 common-obj-$(CONFIG_ONENAND) += onenand.o
 common-obj-$(CONFIG_NVME_PCI) += nvme.o
diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
deleted file mode 100644
index 75fe55f2ae..00
--- a/hw/block/xen_disk.c
+++ /dev/null
@@ -1,1011 +0,0 @@
-/*
- *  xen paravirt block device backend
- *
- *  (c) Gerd Hoffmann 
- *
- *  This program is free software; you can redistribute it and/or modify
- *  it under the terms of the GNU General Public License as published by
- *  the Free Software Foundation; under version 2 of the License.
- *
- *  This program is distributed in the hope that it will be useful,
- *  but WITHOUT ANY WARRANTY; without even the implied warranty of
- *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *  GNU General Public License for more details.
- *
- *  You should have received a copy of the GNU General Public License along
- *  with this program; if not, see .
- *
- *  Contributions after 2012-01-13 are licensed under the terms of the
- *  GNU GPL, version 2 or (at your option) any later version.
- */
-
-#include "qemu/osdep.h"
-#include "qemu/units.h"
-#include 
-#include 
-
-#include "hw/hw.h"
-#include "hw/xen/xen-legacy-backend.h"
-#include "xen_blkif.h"
-#include "sysemu/blockdev.h"
-#include "sysemu/iothread.h"
-#include "sysemu/block-backend.h"
-#include "qapi/error.h"
-#include "qapi/qmp/qdict.h"
-#include "qapi/qmp/qstring.h"
-#include "trace.h"
-
-/* - */
-
-#define BLOCK_SIZE  512
-#define IOCB_COUNT  (BLKIF_MAX_SEGMENTS_PER_REQUEST + 2)
-
-struct ioreq {
-blkif_request_t req;
-int16_t status;
-
-/* parsed request */
-off_t   start;
-QEMUIOVectorv;
-void*buf;
-size_t  size;
-int presync;
-
-/* aio status */
-int aio_inflight;
-int aio_errors;
-
-struct XenBlkDev*blkdev;
-QLIST_ENTRY(ioreq)   list;
-BlockAcctCookie acct;
-};
-
-#define MAX_RING_PAGE_ORDER 4
-
-struct XenBlkDev {
-struct XenLegacyDevicexendev;  /* must be first */
-char*params;
-char*mode;
-char*type;
-char*dev;
-char*devtype;
-booldirectiosafe;
-const char  *fileproto;
-const char  *filename;
-unsigned intring_ref[1 << MAX_RING_PAGE_ORDER];
-unsigned intnr_ring_ref;
-void*sring;
-int64_t file_blk;
-int64_t file_size;
-int protocol;
-blkif_back_rings_t  rings;
-int more_work;
-
-/* request lists */
-QLIST_HEAD(inflight_head, ioreq) inflight;
-QLIST_HEAD(finished_head, ioreq) finished;
-QLIST_HEAD(freelist_head, ioreq) freelist;
-int requests_total;
-int requests_inflight;
-int requests_finished;
-unsigned intmax_requests;
-
-gbooleanfeature_discard;
-
-/* qemu block driver */
-DriveInfo   *dinfo;
-BlockBackend*blk;
-QEMUBH  *bh;
-
-IOThread*iothread;
-AioContext  *ctx;
-};
-
-/* - */
-
-static void ioreq_reset(struct ioreq *ioreq)
-{
-memset(>req, 0, sizeof(ioreq->req));
-ioreq->status = 0;
-ioreq->start = 0;
-ioreq->buf = NULL;
-ioreq->size = 0;
-ioreq->presync = 0;
-
-ioreq->aio_inflight = 0;
-ioreq->aio_errors = 0;
-
-ioreq->blkdev = NULL;
-memset(>list, 0, sizeof(ioreq->list));
-memset(>acct, 0, sizeof(ioreq->acct));
-
-qemu_iovec_reset(>v);
-}
-
-static struct ioreq *ioreq_start(struct XenBlkDev *blkdev)
-{
-struct ioreq *ioreq = NULL;
-
-if (QLIST_EMPTY(>freelist)) {
-if (blkdev->requests_total >= blkdev->max_requests) {
-goto out;
-}
-/* allocate new struct */
-ioreq = g_malloc0(sizeof(*ioreq));
-ioreq->blkdev = blkdev;
-

Re: [Xen-devel] Xen (both x86 and Arm) Community Call: Jan 9 - 16:00 - 17:00 UTC - Call for Agenda Items

[Razvan Cojocaru]

On 1/7/19 4:26 PM, Tamas K Lengyel wrote:

Fix VGA logdirty with altp2m (v11)   Razvan Cojocaru?


This has been merged already.


Indeed, sorry for only seeing this now - I've had a small technical 
SNAFU I had to take care of today and missed some emails.



Thanks,
Razvan

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen (both x86 and Arm) Community Call: Jan 9 - 16:00 - 17:00 UTC - Call for Agenda Items

[Tamas K Lengyel]

> Fix VGA logdirty with altp2m (v11)   Razvan Cojocaru?

This has been merged already.

Tamas

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v4 2/2] xen/blkback: rework connect_ring() to avoid inconsistent xenstore 'ring-page-order' set by malicious blkfront

[Roger Pau Monné]

On Mon, Jan 07, 2019 at 10:07:34PM +0800, Dongli Zhang wrote:
> 
> 
> On 01/07/2019 10:05 PM, Dongli Zhang wrote:
> > 
> > 
> > On 01/07/2019 08:01 PM, Roger Pau Monné wrote:
> >> On Mon, Jan 07, 2019 at 01:35:59PM +0800, Dongli Zhang wrote:
> >>> The xenstore 'ring-page-order' is used globally for each blkback queue and
> >>> therefore should be read from xenstore only once. However, it is obtained
> >>> in read_per_ring_refs() which might be called multiple times during the
> >>> initialization of each blkback queue.
> >>>
> >>> If the blkfront is malicious and the 'ring-page-order' is set in different
> >>> value by blkfront every time before blkback reads it, this may end up at
> >>> the "WARN_ON(i != (XEN_BLKIF_REQS_PER_PAGE * blkif->nr_ring_pages));" in
> >>> xen_blkif_disconnect() when frontend is destroyed.
> >>>
> >>> This patch reworks connect_ring() to read xenstore 'ring-page-order' only
> >>> once.
> >>>
> >>> Signed-off-by: Dongli Zhang 
> >>> ---
> >>> Changed since v1:
> >>>   * change the order of xenstore read in read_per_ring_refs
> >>>   * use xenbus_read_unsigned() in connect_ring()
> >>>
> >>> Changed since v2:
> >>>   * simplify the condition check as "(err != 1 && nr_grefs > 1)"
> >>>   * avoid setting err as -EINVAL to remove extra one line of code
> >>>
> >>> Changed since v3:
> >>>   * exit at the beginning if !nr_grefs
> >>>   * change the if statements to avoid test (err != 1) twice
> >>>   * initialize a 'blkif' stack variable (refer to PATCH 1/2)
> >>>
> >>>  drivers/block/xen-blkback/xenbus.c | 76 
> >>> +-
> >>>  1 file changed, 43 insertions(+), 33 deletions(-)
> >>>
> >>> diff --git a/drivers/block/xen-blkback/xenbus.c 
> >>> b/drivers/block/xen-blkback/xenbus.c
> >>> index a4aadac..a2acbc9 100644
> >>> --- a/drivers/block/xen-blkback/xenbus.c
> >>> +++ b/drivers/block/xen-blkback/xenbus.c
> >>> @@ -926,7 +926,7 @@ static int read_per_ring_refs(struct xen_blkif_ring 
> >>> *ring, const char *dir)
> >>>   int err, i, j;
> >>>   struct xen_blkif *blkif = ring->blkif;
> >>>   struct xenbus_device *dev = blkif->be->dev;
> >>> - unsigned int ring_page_order, nr_grefs, evtchn;
> >>> + unsigned int nr_grefs, evtchn;
> >>>  
> >>>   err = xenbus_scanf(XBT_NIL, dir, "event-channel", "%u",
> >>> );
> >>> @@ -936,43 +936,38 @@ static int read_per_ring_refs(struct xen_blkif_ring 
> >>> *ring, const char *dir)
> >>>   return err;
> >>>   }
> >>>  
> >>> - err = xenbus_scanf(XBT_NIL, dev->otherend, "ring-page-order", "%u",
> >>> -   _page_order);
> >>> - if (err != 1) {
> >>> - err = xenbus_scanf(XBT_NIL, dir, "ring-ref", "%u", 
> >>> _ref[0]);
> >>> + nr_grefs = blkif->nr_ring_pages;
> >>> +
> >>> + if (unlikely(!nr_grefs))
> >>> + return -EINVAL;
> >>
> >> Is this even possible? AFAICT read_per_ring_refs will always be called
> >> with blkif->nr_ring_pages != 0?
> >>
> >> If so, I would consider turning this into a BUG_ON/WARN_ON.
> > 
> > It used to be "WARN_ON(!nr_grefs);" in the v3 of the patch.
> > 
> > I would turn it into WARN_ON if it is fine with both Paul and you.
> 
> To clarify, I would use WARN_ON() before exit with -EINVAL (when
> blkif->nr_ring_pages is 0).

Given that this function will never be called with nr_ring_pages == 0
I would be fine with just using a BUG_ON, getting here with
nr_ring_pages == 0 would imply memory corruption or some other severe
issue has happened, and there's no possible recovery.

If you want to instead keep the return, please use plain WARN instead
of WARN_ON.

Thanks, Roger.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 5/8] viridian: use viridian_map/unmap_guest_page() for reference tsc page

[Paul Durrant]

> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Paul Durrant
> Sent: 03 January 2019 09:20
> To: Wei Liu 
> Cc: xen-devel@lists.xenproject.org; Roger Pau Monne
> ; Wei Liu ; Jan Beulich
> ; Andrew Cooper 
> Subject: Re: [Xen-devel] [PATCH 5/8] viridian: use
> viridian_map/unmap_guest_page() for reference tsc page
> 
> > -Original Message-
> > From: Wei Liu [mailto:wei.l...@citrix.com]
> > Sent: 02 January 2019 15:55
> > To: Paul Durrant 
> > Cc: xen-devel@lists.xenproject.org; Jan Beulich ;
> > Andrew Cooper ; Wei Liu
> ;
> > Roger Pau Monne 
> > Subject: Re: [PATCH 5/8] viridian: use viridian_map/unmap_guest_page()
> for
> > reference tsc page
> >
> > On Thu, Dec 20, 2018 at 04:33:42PM +, Paul Durrant wrote:
> > > Whilst the reference tsc page does not currently need to be kept
> mapped
> > > after it is initially set up (or updated after migrate), the code can
> > > be simplified by using the common guest page map/unmap and dump
> > functions.
> > > New functionality added by a subsequent patch will also require the
> page
> > to
> > > kept mapped for the lifetime of the domain.
> > >
> > > NOTE: Because the reference tsc page is per-domain rather than per-
> vcpu
> > >   this patch also changes viridian_map_guest_page() to take a
> domain
> > >   pointer rather than a vcpu pointer.
> > >
> > > Signed-off-by: Paul Durrant 
> > > ---
> > > Cc: Jan Beulich 
> > > Cc: Andrew Cooper 
> > > Cc: Wei Liu 
> > > Cc: "Roger Pau Monné" 
> > > ---
> > >  xen/arch/x86/hvm/viridian/private.h  |  2 +-
> > >  xen/arch/x86/hvm/viridian/synic.c|  8 +++-
> > >  xen/arch/x86/hvm/viridian/time.c | 57 ++-
> -
> > >  xen/arch/x86/hvm/viridian/viridian.c |  3 +-
> > >  xen/include/asm-x86/hvm/viridian.h   |  2 +-
> > >  5 files changed, 28 insertions(+), 44 deletions(-)
> > >
> > > diff --git a/xen/arch/x86/hvm/viridian/private.h
> > b/xen/arch/x86/hvm/viridian/private.h
> > > index 1864bab3d5..0bf34eefe0 100644
> > > --- a/xen/arch/x86/hvm/viridian/private.h
> > > +++ b/xen/arch/x86/hvm/viridian/private.h
> > > @@ -111,7 +111,7 @@ void viridian_time_load_domain_ctxt(
> > >
> > >  void viridian_dump_guest_page(const struct vcpu *v, const char *name,
> > >const struct viridian_page *vp);
> > > -void viridian_map_guest_page(struct vcpu *v, struct viridian_page
> *vp);
> > > +void viridian_map_guest_page(struct domain *d, struct viridian_page
> > *vp);
> >
> > Since you modify this anyway, can you constify struct domain?
> >
> 
> Yes, I guess that should be do-able now that the viridian_page is in a
> separate allocation unit.

Alas, no. The call to get_page_from_gfn() takes a non-const struct domain 
pointer, and I'm not opening that can of worms. Does your R-b still stand?

  Paul

> 
> > With that:
> >
> > Reviewed-by: Wei Liu 
> 
> Thanks,
> 
>   Paul
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 5/8] viridian: use viridian_map/unmap_guest_page() for reference tsc page

[Wei Liu]

On Mon, Jan 07, 2019 at 03:35:41PM +, Paul Durrant wrote:
[...]
> > > >const struct viridian_page *vp);
> > > > -void viridian_map_guest_page(struct vcpu *v, struct viridian_page
> > *vp);
> > > > +void viridian_map_guest_page(struct domain *d, struct viridian_page
> > > *vp);
> > >
> > > Since you modify this anyway, can you constify struct domain?
> > >
> > 
> > Yes, I guess that should be do-able now that the viridian_page is in a
> > separate allocation unit.
> 
> Alas, no. The call to get_page_from_gfn() takes a non-const struct domain 
> pointer, and I'm not opening that can of worms. Does your R-b still stand?

Yes.

Wei.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v3] x86/dom0: add verbose mode and print memory allocation stats

[Jan Beulich]

>>> On 07.01.19 at 17:22,  wrote:
> Add a verbose option to the dom0 command line, so that dom0 builder
> can print extra debug information when required.
> 
> Use this new verbose mode to print statistics about memory allocations
> when populating dom0 p2m.
> 
> Signed-off-by: Roger Pau Monné 

Acked-by: Jan Beulich 


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v1] mm/page_alloc: fix MEMF_no_dma allocations for single NUMA

[Sergey Dyasli]

Currently dma_bitsize is zero by default on single NUMA node machines.
This makes all alloc_domheap_pages() calls with MEMF_no_dma return NULL.

There is only 1 user of MEMF_no_dma: dom0_memflags, which are used
during memory allocation for Dom0. Failing allocation with default
dom0_memflags is especially severe for the PV Dom0 case: it makes
alloc_chunk() to use suboptimal 2MB allocation algorithm with a search
for higher memory addresses.

This can lead to the NMI watchdog timeout during PV Dom0 construction
on some machines, which can be worked around by specifying "dma_bits"
in Xen's cmdline manually.

Fix the issue by initialising dma_bitsize even on single NUMA machines.

Signed-off-by: Sergey Dyasli 
---
CC: Andrew Cooper 
CC: Jan Beulich 
CC: Julien Grall 
CC: Wei Liu 
CC: Boris Ostrovsky 
CC: George Dunlap 
CC: Roger Pau Monné 
---
 xen/common/page_alloc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index e591601f9c..4515282c27 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -1863,7 +1863,7 @@ void __init end_boot_allocator(void)
 nr_bootmem_regions = 0;
 init_heap_pages(virt_to_page(bootmem_region_list), 1);
 
-if ( !dma_bitsize && (num_online_nodes() > 1) )
+if ( !dma_bitsize )
 dma_bitsize = arch_get_dma_bitsize();
 
 printk("Domain heap initialised");
-- 
2.17.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 4/4] pci: add a pci section to the maintainers file

[Roger Pau Monné]

On Mon, Jan 07, 2019 at 02:56:23AM -0700, Jan Beulich wrote:
> >>> On 04.01.19 at 11:33,  wrote:
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -259,6 +259,7 @@ X:  xen/drivers/passthrough/arm/
> >  X: xen/drivers/passthrough/vtd/
> >  X: xen/drivers/passthrough/x86/
> >  X: xen/drivers/passthrough/device_tree.c
> > +X: xen/drivers/passthrough/pci.c
> 
> Much like for patch 3, I'm not convinced this is appropriate.
> 
> > @@ -312,6 +313,14 @@ M: Wei Liu 
> >  S: Supported
> >  T: git https://xenbits.xenproject.org/git-http/ovmf.git 
> >  
> > +PCI
> > +M: Jan Beulich 
> > +R: Roger Pau Monné 
> > +S: Supported
> > +F: xen/drivers/passthrough/pci.c
> > +F: xen/drivers/pci/
> > +F: xen/include/xen/pci*
> 
> I'm fine with the last two, but I think truly IOMMU-independent
> code would better be moved from the file named first to a file in
> the directory named second.

Let me see if I can find a way to do such movement, I'm not sure how
entangled the code is.

Thanks, Roger.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 4/4] pci: add a pci section to the maintainers file

[Jan Beulich]

>>> On 04.01.19 at 11:33,  wrote:
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -259,6 +259,7 @@ X:xen/drivers/passthrough/arm/
>  X:   xen/drivers/passthrough/vtd/
>  X:   xen/drivers/passthrough/x86/
>  X:   xen/drivers/passthrough/device_tree.c
> +X:   xen/drivers/passthrough/pci.c

Much like for patch 3, I'm not convinced this is appropriate.

> @@ -312,6 +313,14 @@ M:   Wei Liu 
>  S:   Supported
>  T:   git https://xenbits.xenproject.org/git-http/ovmf.git 
>  
> +PCI
> +M:   Jan Beulich 
> +R:   Roger Pau Monné 
> +S:   Supported
> +F:   xen/drivers/passthrough/pci.c
> +F:   xen/drivers/pci/
> +F:   xen/include/xen/pci*

I'm fine with the last two, but I think truly IOMMU-independent
code would better be moved from the file named first to a file in
the directory named second.

The whole situation arises from the origin of this code, which
back then was needed solely for the purposes of IOMMU
management.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 1/3] libx86: Introduce a helper to deserialise cpuid_policy objects

[Jan Beulich]

>>> On 04.01.19 at 16:33,  wrote:
> --- a/xen/include/xen/lib/x86/cpuid.h
> +++ b/xen/include/xen/lib/x86/cpuid.h
> @@ -319,6 +319,27 @@ typedef xen_cpuid_leaf_t cpuid_leaf_buffer_t[];
>  int x86_cpuid_copy_to_buffer(const struct cpuid_policy *policy,
>   cpuid_leaf_buffer_t leaves, uint32_t 
> *nr_entries);
>  
> +/**
> + * Unserialise a cpuid_policy object from an array of cpuid leaves.
> + *
> + * @param policy  The cpuid_policy to unserialise into.
> + * @param leaves  The array of leaves to unserialise from.
> + * @param nr_entries  The number of entries in 'leaves'.
> + * @param err_leafOptional hint filled on error.
> + * @param err_subleaf Optional hint filled on error.
> + * @returns -errno
> + *
> + * Reads at most CPUID_MAX_SERIALISED_LEAVES.  May return -ERANGE if an
> + * incoming leaf is out of range of cpuid_policy, in which case the optional
> + * err_* pointers are filled to aid diagnostics.
> + *
> + * No content validation of in-range leaves is performed.
> + */
> +int x86_cpuid_copy_from_buffer(struct cpuid_policy *policy,
> +   const cpuid_leaf_buffer_t leaves,
> +   uint32_t nr_entries, uint32_t *err_leaf,
> +   uint32_t *err_subleaf);
> +
>  #endif /* !XEN_LIB_X86_CPUID_H */
>  
>  /*
> diff --git a/xen/lib/x86/cpuid.c b/xen/lib/x86/cpuid.c
> index 5a3159b..7fc4148 100644
> --- a/xen/lib/x86/cpuid.c
> +++ b/xen/lib/x86/cpuid.c
> @@ -233,6 +233,112 @@ int x86_cpuid_copy_to_buffer(const struct cpuid_policy 
> *p,
>  return 0;
>  }
>  
> +int x86_cpuid_copy_from_buffer(struct cpuid_policy *p,
> +   const cpuid_leaf_buffer_t leaves,
> +   uint32_t nr_entries, uint32_t *err_leaf,
> +   uint32_t *err_subleaf)
> +{
> +unsigned int i;
> +xen_cpuid_leaf_t data;
> +struct cpuid_leaf *l = (void *)

I'd find this cast a little less worrying if you used container_of(). But
even then I dislike this well hidden assumption of similar layouts
of struct cpuid_leaf and the latter parts of struct xen_cpuid_leaf.

Also it looks as if this could be a pointer to const.

> +/*
> + * A well formed caller is expected pass an array with leaves in order,

... expected to pass ...

> + * and without any repetitions.  However, due to per-vendor differences,
> + * and in the case of upgrade or levelled scenarios, we typically expect
> + * fewer than MAX leaves to be passed.
> + *
> + * Detecting repeated entries is prohibitively complicated, so we don't
> + * bother.  That said, one way or another if more than MAX leaves are
> + * passed, something is wrong.
> + */
> +if ( nr_entries > CPUID_MAX_SERIALISED_LEAVES )
> +return -E2BIG;
> +
> +for ( i = 0; i < nr_entries; ++i )
> +{
> +if ( copy_from_buffer_offset(, leaves, i, 1) )
> +return -EFAULT;
> +
> +switch ( data.leaf )
> +{
> +case 0 ... ARRAY_SIZE(p->basic.raw) - 1:
> +switch ( data.leaf )
> +{
> +case 0x4:
> +if ( data.subleaf >= ARRAY_SIZE(p->cache.raw) )
> +goto out_of_range;
> +
> +p->cache.raw[data.subleaf] = *l;

Do you not want to use array_index_nospec() here and below?

> +break;
> +
> +case 0x7:
> +if ( data.subleaf >= ARRAY_SIZE(p->feat.raw) )
> +goto out_of_range;
> +
> +p->feat.raw[data.subleaf] = *l;
> +break;
> +
> +case 0xb:
> +if ( data.subleaf >= ARRAY_SIZE(p->topo.raw) )
> +goto out_of_range;
> +
> +p->topo.raw[data.subleaf] = *l;
> +break;
> +
> +case 0xd:
> +if ( data.subleaf >= ARRAY_SIZE(p->xstate.raw) )
> +goto out_of_range;
> +
> +p->xstate.raw[data.subleaf] = *l;
> +break;
> +
> +default:
> +if ( data.subleaf != XEN_CPUID_NO_SUBLEAF )
> +goto out_of_range;
> +
> +p->basic.raw[data.leaf] = *l;
> +break;
> +}
> +break;
> +
> +case 0x4000:
> +if ( data.subleaf != XEN_CPUID_NO_SUBLEAF )
> +goto out_of_range;
> +
> +p->hv_limit = l->a;
> +break;
> +
> +case 0x4100:
> +if ( data.subleaf != XEN_CPUID_NO_SUBLEAF )
> +goto out_of_range;
> +
> +p->hv2_limit = l->a;
> +break;
> +
> +case 0x8000 ... 0x8000 + ARRAY_SIZE(p->extd.raw) - 1:
> +if ( data.subleaf != XEN_CPUID_NO_SUBLEAF )
> +goto out_of_range;
> +
> +p->extd.raw[data.leaf & 0x] = *l;
> +break;
> +
> +default:
> +  

Re: [Xen-devel] [PATCH 3/3] tools/cpu-policy: Add unit tests and a fuzzing harness

[Jan Beulich]

>>> On 04.01.19 at 16:33,  wrote:
> The AFL harness currently notices that there are cases where we optimse the
> serialised stream by omitting data beyond the various maximum leaves.
> 
> Both sets of tests will be extended with further libx86 work.
> 
> Fix the sorting of the CPUID_GUEST_NR_* constants, noticed while writing the
> unit tests.
> 
> Signed-off-by: Andrew Cooper 
> ---
> CC: Jan Beulich 
> CC: Wei Liu 
> CC: Roger Pau Monné 
> CC: Sergey Dyasli 
> ---
>  tools/fuzz/cpu-policy/.gitignore  |   1 +
>  tools/fuzz/cpu-policy/Makefile|  27 
>  tools/fuzz/cpu-policy/afl-policy-fuzzer.c | 117 ++
>  tools/tests/Makefile  |   1 +
>  tools/tests/cpu-policy/.gitignore |   1 +

Did we somehow come to the conclusion that the central .gitignore
at the root of the tree is not the way to go in the future?

> --- /dev/null
> +++ b/tools/tests/cpu-policy/test-cpu-policy.c
> @@ -0,0 +1,247 @@
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static void test_cpuid_serialise_success(void)
> +{
> +static const struct test {
> +struct cpuid_policy p;
> +const char *name;
> +unsigned int nr_leaves;
> +} tests[] = {
> +{
> +.name = "empty policy",
> +.nr_leaves = 4,
> +},
> +};
> +unsigned int i;
> +
> +printf("Testing CPUID serialise success:\n");
> +
> +for ( i = 0; i < ARRAY_SIZE(tests); ++i )
> +{
> +const struct test *t = [i];
> +unsigned int nr = t->nr_leaves;
> +xen_cpuid_leaf_t *leaves = malloc(nr * sizeof(*leaves));
> +int rc;
> +
> +if ( !leaves )
> +goto test_done;

Shouldn't you leave some indication of the test not having got run?

> +static void test_cpuid_deserialise_failure(void)
> +{
> +static const struct test {
> +const char *name;
> +xen_cpuid_leaf_t leaf;
> +} tests[] = {
> +{
> +.name = "incorrect basic subleaf",
> +.leaf = { .leaf = 0, .subleaf = 0 },
> +},
> +{
> +.name = "incorrect hv1 subleaf",
> +.leaf = { .leaf = 0x4000, .subleaf = 0 },
> +},
> +{
> +.name = "incorrect hv2 subleaf",
> +.leaf = { .leaf = 0x4100, .subleaf = 0 },
> +},
> +{
> +.name = "incorrect extd subleaf",
> +.leaf = { .leaf = 0x8000, .subleaf = 0 },
> +},
> +{
> +.name = "OoB basic leaf",
> +.leaf = { .leaf = CPUID_GUEST_NR_BASIC },
> +},
> +{
> +.name = "OoB cache leaf",
> +.leaf = { .leaf = 0x4, .subleaf = CPUID_GUEST_NR_CACHE },
> +},
> +{
> +.name = "OoB feat leaf",
> +.leaf = { .leaf = 0x7, .subleaf = CPUID_GUEST_NR_FEAT },
> +},
> +{
> +.name = "OoB topo leaf",
> +.leaf = { .leaf = 0xb, .subleaf = CPUID_GUEST_NR_TOPO },
> +},
> +{
> +.name = "OoB xstate leaf",
> +.leaf = { .leaf = 0xd, .subleaf = CPUID_GUEST_NR_XSTATE },
> +},
> +{
> +.name = "OoB extd leaf",
> +.leaf = { .leaf = 0x8000 | CPUID_GUEST_NR_EXTD },
> +},
> +};
> +unsigned int i;
> +
> +printf("Testing CPUID deserialise failure:\n");
> +
> +for ( i = 0; i < ARRAY_SIZE(tests); ++i )
> +{
> +const struct test *t = [i];
> +uint32_t err_leaf = ~0u, err_subleaf = ~0u;
> +int rc;
> +
> +rc = x86_cpuid_copy_from_buffer(NULL, >leaf, 1,
> +_leaf, _subleaf);
> +
> +if ( rc != -ERANGE )
> +{
> +printf("  Test %s, expected rc %d, got %d\n",
> +   t->name, -ERANGE, rc);
> +continue;

Perhaps drop this? The subsequent test ought to apply regardless
of error code.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH 3/3] string: fix type use in strstr()

[Jan Beulich]

Using plain int for string lengths, while okay for all practical
purposes, is undesirable in a generic library function.

Take the opportunity and also move the function from being in the middle
of mem*() ones to the set of str*() ones, convert its loop from while()
to for(), and correct style.

Signed-off-by: Jan Beulich 

--- a/xen/common/string.c
+++ b/xen/common/string.c
@@ -290,6 +290,27 @@ char * strsep(char **s, const char *ct)
 }
 #endif
 
+#ifndef __HAVE_ARCH_STRSTR
+/**
+ * strstr - Find the first substring in a %NUL terminated string
+ * @s1: The string to be searched
+ * @s2: The string to search for
+ */
+char *(strstr)(const char *s1, const char *s2)
+{
+   size_t l1, l2 = strlen(s2);
+
+   if (!l2)
+   return (char *)s1;
+
+   for (l1 = strlen(s1); l1 >= l2; --l1, ++s1)
+   if (!memcmp(s1, s2, l2))
+   return (char *)s1;
+
+   return NULL;
+}
+#endif
+
 #ifndef __HAVE_ARCH_MEMSET
 /**
  * memset - Fill a region of memory with the given value
@@ -380,30 +401,6 @@ int (memcmp)(const void *cs, const void
 }
 #endif
 
-#ifndef __HAVE_ARCH_STRSTR
-/**
- * strstr - Find the first substring in a %NUL terminated string
- * @s1: The string to be searched
- * @s2: The string to search for
- */
-char *(strstr)(const char *s1, const char *s2)
-{
-   int l1, l2;
-
-   l2 = strlen(s2);
-   if (!l2)
-   return (char *) s1;
-   l1 = strlen(s1);
-   while (l1 >= l2) {
-   l1--;
-   if (!memcmp(s1,s2,l2))
-   return (char *) s1;
-   s1++;
-   }
-   return NULL;
-}
-#endif
-
 #ifndef __HAVE_ARCH_MEMCHR
 /**
  * memchr - Find a character in an area of memory.





___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v5 4/4] xen/common: use SYMBOL when required

[Jan Beulich]

>>> On 03.01.19 at 20:19,  wrote:
> --- a/xen/common/kernel.c
> +++ b/xen/common/kernel.c
> @@ -312,14 +312,18 @@ extern const initcall_t __initcall_start[], 
> __presmp_initcall_end[],
>  void __init do_presmp_initcalls(void)
>  {
>  const initcall_t *call;
> -for ( call = __initcall_start; call < __presmp_initcall_end; call++ )
> +for ( call = __initcall_start;
> +   (unsigned long)call < SYMBOL(__presmp_initcall_end);
> +   call++ )

Hard tabs here and ...

>  (*call)();
>  }
>  
>  void __init do_initcalls(void)
>  {
>  const initcall_t *call;
> -for ( call = __presmp_initcall_end; call < __initcall_end; call++ )
> +for ( call = __presmp_initcall_end;
> +   (unsigned long)call < SYMBOL(__initcall_end);
> +   call++ )

... here.

> --- a/xen/common/lib.c
> +++ b/xen/common/lib.c
> @@ -497,7 +497,7 @@ extern const ctor_func_t __ctors_start[], __ctors_end[];
>  void __init init_constructors(void)
>  {
>  const ctor_func_t *f;
> -for ( f = __ctors_start; f < __ctors_end; ++f )
> +for ( f = __ctors_start; (unsigned long)f < SYMBOL(__ctors_end); ++f )
>  (*f)();

One of the best examples where SYMBOL() retaining the original type
would help.

Also please take the opportunity and add the missing blank line.

> --- a/xen/common/schedule.c
> +++ b/xen/common/schedule.c
> @@ -68,7 +68,7 @@ DEFINE_PER_CPU(struct scheduler *, scheduler);
>  DEFINE_PER_CPU(cpumask_t, cpumask_scratch);
>  
>  extern const struct scheduler *__start_schedulers_array[], 
> *__end_schedulers_array[];
> -#define NUM_SCHEDULERS (__end_schedulers_array - __start_schedulers_array)
> +#define NUM_SCHEDULERS (SYMBOL(__end_schedulers_array) - 
> SYMBOL(__start_schedulers_array))

Long line.

> --- a/xen/common/spinlock.c
> +++ b/xen/common/spinlock.c
> @@ -474,7 +474,9 @@ static int __init lock_prof_init(void)
>  {
>  struct lock_profile **q;
>  
> -for ( q = &__lock_profile_start; q < &__lock_profile_end; q++ )
> +for ( q = &__lock_profile_start;
> +   (unsigned long)q < SYMBOL(&__lock_profile_end);
> +   q++ )

Hard tabs again.

> --- a/xen/common/virtual_region.c
> +++ b/xen/common/virtual_region.c
> @@ -119,7 +119,11 @@ void __init setup_virtual_regions(const struct 
> exception_table_entry *start,
>  const struct bug_frame *s;
>  
>  s = bug_frames[i - 1];
> -sz = bug_frames[i] - s;
> +/*
> + * Cast to unsigned long to calculate the size to avoid
> + * subtractions between pointers pointing to different objects.
> + */
> +sz = (unsigned long)bug_frames[i] - (unsigned long)s;

Perhaps better to use SYMBOL() in the definition of bug_frames[]?

> --- a/xen/include/xen/kernel.h
> +++ b/xen/include/xen/kernel.h
> @@ -66,27 +66,27 @@
>  })
>  
>  extern char _start[], _end[], start[];
> -#define is_kernel(p) ({ \
> -char *__p = (char *)(unsigned long)(p); \
> -(__p >= _start) && (__p < _end);\
> +#define is_kernel(p) ({ \
> +const unsigned long __p = (unsigned long)(p);   \
> +(__p >= SYMBOL(_start)) && (__p < SYMBOL(_end));\
>  })
>  
>  extern char _stext[], _etext[];
> -#define is_kernel_text(p) ({\
> -char *__p = (char *)(unsigned long)(p); \
> -(__p >= _stext) && (__p < _etext);  \
> +#define is_kernel_text(p) ({\
> +const unsigned long __p = (unsigned long)(p);   \
> +(__p >= SYMBOL(_stext)) && (__p < SYMBOL(_etext));  \
>  })
>  
>  extern const char _srodata[], _erodata[];
> -#define is_kernel_rodata(p) ({  \
> -const char *__p = (const char *)(unsigned long)(p); \
> -(__p >= _srodata) && (__p < _erodata);  \
> +#define is_kernel_rodata(p) ({  \
> +const unsigned long __p = (unsigned long)(p);   \
> +(__p >= SYMBOL(_srodata)) && (__p < SYMBOL(_erodata));  \
>  })
>  
>  extern char _sinittext[], _einittext[];
> -#define is_kernel_inittext(p) ({\
> -char *__p = (char *)(unsigned long)(p); \
> -(__p >= _sinittext) && (__p < _einittext);  \
> +#define is_kernel_inittext(p) ({\
> +const unsigned long __p = (unsigned long)(p);   \
> +(__p >= SYMBOL(_sinittext)) && (__p < SYMBOL(_einittext));  \
>  })

If you fully replace the macro bodies anyway, please take the
opportunity and also do away with the name space violating
leading underscores (use trailing ones instead, for example).

Jan


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH 1/6] x86: stop handling MSR_IA32_BNDCFGS save/restore in implementation code

[Paul Durrant]

Saving and restoring the value of this MSR is currently handled by
implementation-specific code despite it being architectural. This patch
moves handling of accesses to this MSR from hvm.c into the msr.c, thus
allowing the common MSR save/restore code to handle it.

This patch also changes hvm_get/set_guest_bndcfgs() to check CPUID policy
for the appropriate feature, rather than hardware, and also re-works
the get/set_guest_bndcfgs() hvm_funcs so they are no longer boolean. Uses
of u64 are also converted to uint64_t.

NOTE: Because vmx_get/set_guest_bndcfgs() call vmx_vmcs_enter(), the
  struct vcpu pointer passed in cannot be const.

Signed-off-by: Paul Durrant 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Wei Liu 
Cc: "Roger Pau Monné" 
Cc: Jun Nakajima 
Cc: Kevin Tian 
---
 xen/arch/x86/hvm/hvm.c | 44 +-
 xen/arch/x86/hvm/vmx/vmx.c | 31 +---
 xen/arch/x86/msr.c | 14 ++-
 xen/arch/x86/pv/emul-priv-op.c |  2 +-
 xen/include/asm-x86/hvm/hvm.h  | 13 --
 xen/include/asm-x86/msr.h  |  2 +-
 6 files changed, 52 insertions(+), 54 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 401c4a9312..5fd5478b7d 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -308,11 +308,16 @@ int hvm_set_guest_pat(struct vcpu *v, u64 guest_pat)
 return 1;
 }
 
-bool hvm_set_guest_bndcfgs(struct vcpu *v, u64 val)
+bool hvm_set_guest_bndcfgs(struct vcpu *v, uint64_t val)
 {
-if ( !hvm_funcs.set_guest_bndcfgs ||
- !is_canonical_address(val) ||
- (val & IA32_BNDCFGS_RESERVED) )
+const struct cpuid_policy *cp = v->domain->arch.cpuid;
+
+if ( !cp->feat.mpx )
+return false;
+
+ASSERT(hvm_funcs.set_guest_bndcfgs);
+
+if ( !is_canonical_address(val) || (val & IA32_BNDCFGS_RESERVED) )
 return false;
 
 /*
@@ -342,7 +347,22 @@ bool hvm_set_guest_bndcfgs(struct vcpu *v, u64 val)
 /* nothing, best effort only */;
 }
 
-return hvm_funcs.set_guest_bndcfgs(v, val);
+hvm_funcs.set_guest_bndcfgs(v, val);
+
+return true;
+}
+
+bool hvm_get_guest_bndcfgs(struct vcpu *v, uint64_t *val)
+{
+const struct cpuid_policy *cp = v->domain->arch.cpuid;
+
+if ( !cp->feat.mpx )
+return false;
+
+ASSERT(hvm_funcs.get_guest_bndcfgs);
+*val = hvm_funcs.get_guest_bndcfgs(v);
+
+return true;
 }
 
 /*
@@ -1312,6 +1332,7 @@ static int hvm_load_cpu_xsave_states(struct domain *d, 
hvm_domain_context_t *h)
 static const uint32_t msrs_to_send[] = {
 MSR_SPEC_CTRL,
 MSR_INTEL_MISC_FEATURES_ENABLES,
+MSR_IA32_BNDCFGS,
 MSR_AMD64_DR0_ADDRESS_MASK,
 MSR_AMD64_DR1_ADDRESS_MASK,
 MSR_AMD64_DR2_ADDRESS_MASK,
@@ -1449,6 +1470,7 @@ static int hvm_load_cpu_msrs(struct domain *d, 
hvm_domain_context_t *h)
 
 case MSR_SPEC_CTRL:
 case MSR_INTEL_MISC_FEATURES_ENABLES:
+case MSR_IA32_BNDCFGS:
 case MSR_AMD64_DR0_ADDRESS_MASK:
 case MSR_AMD64_DR1_ADDRESS_MASK ... MSR_AMD64_DR3_ADDRESS_MASK:
 rc = guest_wrmsr(v, ctxt->msr[i].index, ctxt->msr[i].val);
@@ -3472,12 +3494,6 @@ int hvm_msr_read_intercept(unsigned int msr, uint64_t 
*msr_content)
 *msr_content = v->arch.hvm.msr_xss;
 break;
 
-case MSR_IA32_BNDCFGS:
-if ( !d->arch.cpuid->feat.mpx ||
- !hvm_get_guest_bndcfgs(v, msr_content) )
-goto gp_fault;
-break;
-
 case MSR_K8_ENABLE_C1E:
 case MSR_AMD64_NB_CFG:
  /*
@@ -3624,12 +3640,6 @@ int hvm_msr_write_intercept(unsigned int msr, uint64_t 
msr_content,
 v->arch.hvm.msr_xss = msr_content;
 break;
 
-case MSR_IA32_BNDCFGS:
-if ( !d->arch.cpuid->feat.mpx ||
- !hvm_set_guest_bndcfgs(v, msr_content) )
-goto gp_fault;
-break;
-
 case MSR_AMD64_NB_CFG:
 /* ignore the write */
 break;
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 64af8bf943..4bfabe8d0e 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -805,17 +805,6 @@ static unsigned int __init vmx_init_msr(void)
 
 static void vmx_save_msr(struct vcpu *v, struct hvm_msr *ctxt)
 {
-vmx_vmcs_enter(v);
-
-if ( cpu_has_mpx && cpu_has_vmx_mpx )
-{
-__vmread(GUEST_BNDCFGS, >msr[ctxt->count].val);
-if ( ctxt->msr[ctxt->count].val )
-ctxt->msr[ctxt->count++].index = MSR_IA32_BNDCFGS;
-}
-
-vmx_vmcs_exit(v);
-
 if ( cpu_has_xsaves && cpu_has_vmx_xsaves )
 {
 ctxt->msr[ctxt->count].val = v->arch.hvm.msr_xss;
@@ -835,14 +824,6 @@ static int vmx_load_msr(struct vcpu *v, struct hvm_msr 
*ctxt)
 {
 switch ( ctxt->msr[i].index )
 {
-case MSR_IA32_BNDCFGS:
-if ( cpu_has_mpx && cpu_has_vmx_mpx &&
- is_canonical_address(ctxt->msr[i].val) &&
- !(ctxt->msr[i].val & IA32_BNDCFGS_RESERVED) )
- 

[Xen-devel] [PATCH 2/6] x86: save GUEST_BNDCFGS on context switch...

[Paul Durrant]

...to avoid the need for a VMCS reload when the value of MSR_IA32_BNDCFGS is
read by the tool-stack.

Signed-off-by: Paul Durrant 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Wei Liu 
Cc: "Roger Pau Monné" 
Cc: Jun Nakajima 
Cc: Kevin Tian 
---
 xen/arch/x86/hvm/hvm.c | 18 +++---
 xen/arch/x86/hvm/vmx/vmx.c |  3 +++
 xen/include/asm-x86/msr.h  |  5 +
 3 files changed, 23 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 5fd5478b7d..b86aed7c24 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -311,6 +311,7 @@ int hvm_set_guest_pat(struct vcpu *v, u64 guest_pat)
 bool hvm_set_guest_bndcfgs(struct vcpu *v, uint64_t val)
 {
 const struct cpuid_policy *cp = v->domain->arch.cpuid;
+struct vcpu_msrs *msrs = v->arch.msrs;
 
 if ( !cp->feat.mpx )
 return false;
@@ -347,7 +348,8 @@ bool hvm_set_guest_bndcfgs(struct vcpu *v, uint64_t val)
 /* nothing, best effort only */;
 }
 
-hvm_funcs.set_guest_bndcfgs(v, val);
+msrs->bndcfgs.raw = val;
+hvm_funcs.set_guest_bndcfgs(v, msrs->bndcfgs.raw);
 
 return true;
 }
@@ -355,12 +357,22 @@ bool hvm_set_guest_bndcfgs(struct vcpu *v, uint64_t val)
 bool hvm_get_guest_bndcfgs(struct vcpu *v, uint64_t *val)
 {
 const struct cpuid_policy *cp = v->domain->arch.cpuid;
+struct vcpu_msrs *msrs = v->arch.msrs;
 
 if ( !cp->feat.mpx )
 return false;
 
-ASSERT(hvm_funcs.get_guest_bndcfgs);
-*val = hvm_funcs.get_guest_bndcfgs(v);
+/*
+ * The value only need be read in current context as a context
+ * switch will save the value into msrs->bndcfgs.
+ */
+if ( v == current )
+{
+ASSERT(hvm_funcs.get_guest_bndcfgs);
+msrs->bndcfgs.raw = hvm_funcs.get_guest_bndcfgs(v);
+}
+
+*val = msrs->bndcfgs.raw;
 
 return true;
 }
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 4bfabe8d0e..7dba92da45 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -497,6 +497,9 @@ static void vmx_restore_host_msrs(void)
 
 static void vmx_save_guest_msrs(struct vcpu *v)
 {
+if ( cpu_has_mpx && cpu_has_vmx_mpx )
+__vmread(GUEST_BNDCFGS, >arch.msrs->bndcfgs.raw);
+
 /*
  * We cannot cache SHADOW_GS_BASE while the VCPU runs, as it can
  * be updated at any time via SWAPGS, which we cannot trap.
diff --git a/xen/include/asm-x86/msr.h b/xen/include/asm-x86/msr.h
index ad8688a61f..c69ce56963 100644
--- a/xen/include/asm-x86/msr.h
+++ b/xen/include/asm-x86/msr.h
@@ -305,6 +305,11 @@ struct vcpu_msrs
  * values here may be stale in current context.
  */
 uint32_t dr_mask[4];
+
+/* 0x0d90 - MSR_IA32_BNDCFGS */
+struct {
+uint64_t raw;
+} bndcfgs;
 };
 
 void init_guest_msr_policy(void);
-- 
2.20.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH 6/6] x86: introduce dr_mask_idx() helper function...

[Paul Durrant]

...to avoid repeated open-coding.

Unfortunately the mapping from MSR index MSR_AMD64_DR_ADDRESS_MASK
to the 'idx' value is non-trivial since the MSR index corresponding to
idx value 0 is non-consecutive with the MSR indices corresponding to
idx values 1-3. This mapping is currently dealt with by near-identical
open coding in guest_rdmsr() and guest_wrmsr().

This patch adds a helper function, dr_mask_idx(), to handle the mapping
and then uses this in guest_rdmsr() and guest_wrmsr() instead, thus
making the code somewhat neater.

Signed-off-by: Paul Durrant 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Wei Liu 
Cc: "Roger Pau Monné" 
---
 xen/arch/x86/msr.c| 18 +-
 xen/include/asm-x86/msr.h | 21 +
 2 files changed, 26 insertions(+), 13 deletions(-)

diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c
index 3aa79031cf..4e4c9c805a 100644
--- a/xen/arch/x86/msr.c
+++ b/xen/arch/x86/msr.c
@@ -21,7 +21,6 @@
 
 #include 
 #include 
-#include 
 #include 
 
 #include 
@@ -121,7 +120,7 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t *val)
 const struct domain *d = v->domain;
 const struct cpuid_policy *cp = d->arch.cpuid;
 const struct msr_policy *mp = d->arch.msr;
-const struct vcpu_msrs *msrs = v->arch.msrs;
+struct vcpu_msrs *msrs = v->arch.msrs;
 int ret = X86EMUL_OKAY;
 
 switch ( msr )
@@ -202,13 +201,10 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t 
*val)
  */
 #ifdef CONFIG_HVM
 if ( v == current && is_hvm_domain(d) && v->arch.hvm.flag_dr_dirty )
-rdmsrl(msr, *val);
-else
+rdmsrl(msr, msrs->dr_mask[dr_mask_idx(msr)]);
 #endif
-*val = msrs->dr_mask[
-array_index_nospec((msr == MSR_AMD64_DR0_ADDRESS_MASK)
-   ? 0 : (msr - MSR_AMD64_DR1_ADDRESS_MASK + 
1),
-   ARRAY_SIZE(msrs->dr_mask))];
+
+*val = msrs->dr_mask[dr_mask_idx(msr)];
 break;
 
 default:
@@ -377,11 +373,7 @@ int guest_wrmsr(struct vcpu *v, uint32_t msr, uint64_t val)
 if ( !cp->extd.dbext || val != (uint32_t)val )
 goto gp_fault;
 
-msrs->dr_mask[
-array_index_nospec((msr == MSR_AMD64_DR0_ADDRESS_MASK)
-   ? 0 : (msr - MSR_AMD64_DR1_ADDRESS_MASK + 1),
-   ARRAY_SIZE(msrs->dr_mask))] = val;
-
+msrs->dr_mask[dr_mask_idx(msr)] = val;
 if ( v == curr && (curr->arch.dr7 & DR7_ACTIVE_MASK) )
 wrmsrl(msr, val);
 break;
diff --git a/xen/include/asm-x86/msr.h b/xen/include/asm-x86/msr.h
index e9c685613e..5eb5e6dace 100644
--- a/xen/include/asm-x86/msr.h
+++ b/xen/include/asm-x86/msr.h
@@ -5,6 +5,7 @@
 
 #ifndef __ASSEMBLY__
 
+#include 
 #include 
 #include 
 #include 
@@ -317,6 +318,26 @@ struct vcpu_msrs
 } xss;
 };
 
+static inline unsigned int dr_mask_idx(uint32_t msr)
+{
+switch (msr)
+{
+default:
+ASSERT_UNREACHABLE();
+/* Fallthrough */
+case MSR_AMD64_DR0_ADDRESS_MASK:
+return 0;
+
+case MSR_AMD64_DR1_ADDRESS_MASK ... MSR_AMD64_DR3_ADDRESS_MASK:
+{
+struct vcpu_msrs msrs; /* only used for ARRAY_SIZE() */
+
+return array_index_nospec(msr - MSR_AMD64_DR1_ADDRESS_MASK + 1,
+  ARRAY_SIZE(msrs.dr_mask));
+}
+}
+}
+
 void init_guest_msr_policy(void);
 int init_domain_msr_policy(struct domain *d);
 int init_vcpu_msr_policy(struct vcpu *v);
-- 
2.20.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH 4/6] x86: stop handling MSR_IA32_XSS save/restore in implementation code

[Paul Durrant]

Saving and restoring the value of this MSR is currently handled by
implementation-specific code despite it being architectural. This patch
moves handling of accesses to this MSR from hvm.c into the msr.c, thus
allowing the common MSR save/restore code to handle it.

This patch also adds proper checks of CPUID policy in the new get/set code.

NOTE: MSR_IA32_XSS is the last MSR to be saved and restored by
  implementation-specific code. This patch therefore removes the
  (VMX) definitions and of the init_msr(), save_msr() and
  load_msr() hvm_funcs, as they are no longer necessary. The
  declarations of and calls to those hvm_funcs will be cleaned up
  by a subsequent patch.

Signed-off-by: Paul Durrant 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Wei Liu 
Cc: "Roger Pau Monné" 
Cc: Jun Nakajima 
Cc: Kevin Tian 
---
 xen/arch/x86/hvm/hvm.c | 15 ++--
 xen/arch/x86/hvm/vmx/vmx.c | 49 --
 xen/arch/x86/msr.c | 18 ++
 3 files changed, 20 insertions(+), 62 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index b55bb8b081..856dcf696b 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1345,6 +1345,7 @@ static const uint32_t msrs_to_send[] = {
 MSR_SPEC_CTRL,
 MSR_INTEL_MISC_FEATURES_ENABLES,
 MSR_IA32_BNDCFGS,
+MSR_IA32_XSS,
 MSR_AMD64_DR0_ADDRESS_MASK,
 MSR_AMD64_DR1_ADDRESS_MASK,
 MSR_AMD64_DR2_ADDRESS_MASK,
@@ -1483,6 +1484,7 @@ static int hvm_load_cpu_msrs(struct domain *d, 
hvm_domain_context_t *h)
 case MSR_SPEC_CTRL:
 case MSR_INTEL_MISC_FEATURES_ENABLES:
 case MSR_IA32_BNDCFGS:
+case MSR_IA32_XSS:
 case MSR_AMD64_DR0_ADDRESS_MASK:
 case MSR_AMD64_DR1_ADDRESS_MASK ... MSR_AMD64_DR3_ADDRESS_MASK:
 rc = guest_wrmsr(v, ctxt->msr[i].index, ctxt->msr[i].val);
@@ -3500,12 +3502,6 @@ int hvm_msr_read_intercept(unsigned int msr, uint64_t 
*msr_content)
 *msr_content = var_range_base[index];
 break;
 
-case MSR_IA32_XSS:
-if ( !d->arch.cpuid->xstate.xsaves )
-goto gp_fault;
-*msr_content = v->arch.msrs->xss.raw;
-break;
-
 case MSR_K8_ENABLE_C1E:
 case MSR_AMD64_NB_CFG:
  /*
@@ -3645,13 +3641,6 @@ int hvm_msr_write_intercept(unsigned int msr, uint64_t 
msr_content,
 goto gp_fault;
 break;
 
-case MSR_IA32_XSS:
-/* No XSS features currently supported for guests. */
-if ( !d->arch.cpuid->xstate.xsaves || msr_content != 0 )
-goto gp_fault;
-v->arch.msrs->xss.raw = msr_content;
-break;
-
 case MSR_AMD64_NB_CFG:
 /* ignore the write */
 break;
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index ec87607ec7..f175b79b4b 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -800,52 +800,6 @@ static int vmx_load_vmcs_ctxt(struct vcpu *v, struct 
hvm_hw_cpu *ctxt)
 return 0;
 }
 
-static unsigned int __init vmx_init_msr(void)
-{
-return (cpu_has_mpx && cpu_has_vmx_mpx) +
-   (cpu_has_xsaves && cpu_has_vmx_xsaves);
-}
-
-static void vmx_save_msr(struct vcpu *v, struct hvm_msr *ctxt)
-{
-if ( cpu_has_xsaves && cpu_has_vmx_xsaves )
-{
-ctxt->msr[ctxt->count].val = v->arch.msrs->xss.raw;
-if ( ctxt->msr[ctxt->count].val )
-ctxt->msr[ctxt->count++].index = MSR_IA32_XSS;
-}
-}
-
-static int vmx_load_msr(struct vcpu *v, struct hvm_msr *ctxt)
-{
-unsigned int i;
-int err = 0;
-
-vmx_vmcs_enter(v);
-
-for ( i = 0; i < ctxt->count; ++i )
-{
-switch ( ctxt->msr[i].index )
-{
-case MSR_IA32_XSS:
-if ( cpu_has_xsaves && cpu_has_vmx_xsaves )
-v->arch.msrs->xss.raw = ctxt->msr[i].val;
-else
-err = -ENXIO;
-break;
-default:
-continue;
-}
-if ( err )
-break;
-ctxt->msr[i]._rsvd = 1;
-}
-
-vmx_vmcs_exit(v);
-
-return err;
-}
-
 static void vmx_fpu_enter(struct vcpu *v)
 {
 vcpu_restore_fpu_lazy(v);
@@ -2283,9 +2237,6 @@ static struct hvm_function_table __initdata 
vmx_function_table = {
 .vcpu_destroy = vmx_vcpu_destroy,
 .save_cpu_ctxt= vmx_save_vmcs_ctxt,
 .load_cpu_ctxt= vmx_load_vmcs_ctxt,
-.init_msr = vmx_init_msr,
-.save_msr = vmx_save_msr,
-.load_msr = vmx_load_msr,
 .get_interrupt_shadow = vmx_get_interrupt_shadow,
 .set_interrupt_shadow = vmx_set_interrupt_shadow,
 .guest_x86_mode   = vmx_guest_x86_mode,
diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c
index a3406c29a8..3aa79031cf 100644
--- a/xen/arch/x86/msr.c
+++ b/xen/arch/x86/msr.c
@@ -164,6 +164,13 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t 
*val)
 
 break;
 
+case MSR_IA32_XSS:
+if ( 

[Xen-devel] [PATCH 3/6] x86: move the saved value of MSR_IA32_XSS into struct vcpu_msrs

[Paul Durrant]

Currently the value is saved directly in struct hvm_vcpu. This patch simply
co-locates it with other saved MSR values. No functional change.

Signed-off-by: Paul Durrant 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Wei Liu 
Cc: "Roger Pau Monné" 
Cc: Jun Nakajima 
Cc: Kevin Tian 
---
 xen/arch/x86/domain.c  | 2 +-
 xen/arch/x86/hvm/hvm.c | 4 ++--
 xen/arch/x86/hvm/vmx/vmx.c | 4 ++--
 xen/include/asm-x86/hvm/vcpu.h | 1 -
 xen/include/asm-x86/msr.h  | 5 +
 5 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 32dc4253ff..c5f4b6a38a 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1704,7 +1704,7 @@ static void __context_switch(void)
 BUG();
 
 if ( cpu_has_xsaves && is_hvm_vcpu(n) )
-set_msr_xss(n->arch.hvm.msr_xss);
+set_msr_xss(n->arch.msrs->xss.raw);
 }
 vcpu_restore_fpu_nonlazy(n, false);
 nd->arch.ctxt_switch->to(n);
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index b86aed7c24..b55bb8b081 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3503,7 +3503,7 @@ int hvm_msr_read_intercept(unsigned int msr, uint64_t 
*msr_content)
 case MSR_IA32_XSS:
 if ( !d->arch.cpuid->xstate.xsaves )
 goto gp_fault;
-*msr_content = v->arch.hvm.msr_xss;
+*msr_content = v->arch.msrs->xss.raw;
 break;
 
 case MSR_K8_ENABLE_C1E:
@@ -3649,7 +3649,7 @@ int hvm_msr_write_intercept(unsigned int msr, uint64_t 
msr_content,
 /* No XSS features currently supported for guests. */
 if ( !d->arch.cpuid->xstate.xsaves || msr_content != 0 )
 goto gp_fault;
-v->arch.hvm.msr_xss = msr_content;
+v->arch.msrs->xss.raw = msr_content;
 break;
 
 case MSR_AMD64_NB_CFG:
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 7dba92da45..ec87607ec7 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -810,7 +810,7 @@ static void vmx_save_msr(struct vcpu *v, struct hvm_msr 
*ctxt)
 {
 if ( cpu_has_xsaves && cpu_has_vmx_xsaves )
 {
-ctxt->msr[ctxt->count].val = v->arch.hvm.msr_xss;
+ctxt->msr[ctxt->count].val = v->arch.msrs->xss.raw;
 if ( ctxt->msr[ctxt->count].val )
 ctxt->msr[ctxt->count++].index = MSR_IA32_XSS;
 }
@@ -829,7 +829,7 @@ static int vmx_load_msr(struct vcpu *v, struct hvm_msr 
*ctxt)
 {
 case MSR_IA32_XSS:
 if ( cpu_has_xsaves && cpu_has_vmx_xsaves )
-v->arch.hvm.msr_xss = ctxt->msr[i].val;
+v->arch.msrs->xss.raw = ctxt->msr[i].val;
 else
 err = -ENXIO;
 break;
diff --git a/xen/include/asm-x86/hvm/vcpu.h b/xen/include/asm-x86/hvm/vcpu.h
index c8a40f6d55..a8cfd13987 100644
--- a/xen/include/asm-x86/hvm/vcpu.h
+++ b/xen/include/asm-x86/hvm/vcpu.h
@@ -171,7 +171,6 @@ struct hvm_vcpu {
 struct hvm_vcpu_asid n1asid;
 
 u64 msr_tsc_adjust;
-u64 msr_xss;
 
 union {
 struct vmx_vcpu vmx;
diff --git a/xen/include/asm-x86/msr.h b/xen/include/asm-x86/msr.h
index c69ce56963..e9c685613e 100644
--- a/xen/include/asm-x86/msr.h
+++ b/xen/include/asm-x86/msr.h
@@ -310,6 +310,11 @@ struct vcpu_msrs
 struct {
 uint64_t raw;
 } bndcfgs;
+
+/* 0x0da0 - MSR_IA32_XSS */
+struct {
+uint64_t raw;
+} xss;
 };
 
 void init_guest_msr_policy(void);
-- 
2.20.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Live migrate with Linux >= 4.13 domU causes kernel time jumps and TCP connection stalls.

[Juergen Gross]

On 28/12/2018 15:41, Hans van Kranenburg wrote:
> On 12/28/18 11:15 AM, Juergen Gross wrote:
>> On 27/12/2018 22:12, Hans van Kranenburg wrote:
>>> So,
>>>
>>> On 12/24/18 1:32 AM, Hans van Kranenburg wrote:

 On 12/21/18 6:54 PM, Hans van Kranenburg wrote:
>
> We've been tracking down a live migration bug during the last three days
> here at work, and here's what we found so far.
>
> 1. Xen version and dom0 linux kernel version don't matter.
> 2. DomU kernel is >= Linux 4.13.
>
> When using live migrate to another dom0, this often happens:
>
> [   37.511305] Freezing user space processes ... (elapsed 0.001 seconds)
> done.
> [   37.513316] OOM killer disabled.
> [   37.513323] Freezing remaining freezable tasks ... (elapsed 0.001
> seconds) done.
> [   37.514837] suspending xenstore...
> [   37.515142] xen:grant_table: Grant tables using version 1 layout
> [18446744002.593711] OOM killer enabled.
> [18446744002.593726] Restarting tasks ... done.
> [18446744002.604527] Setting capacity to 6291456

 Tonight, I've been through 29 bisect steps to figure out a bit more. A
 make defconfig with enabling Xen PV for domU reproduces the problem
 already, so a complete cycle with compiling and testing had only to take
 about 7 minutes.

 So, it appears that this 18 gazillion seconds of uptime is a thing that
 started happening earlier than the TCP situation already. All of the
 test scenarios resulted in these huge uptime numbers in dmesg. Not all
 of them result in TCP connections hanging.

> As a side effect, all open TCP connections stall, because the timestamp
> counters of packets sent to the outside world are affected:
>
> https://syrinx.knorrie.org/~knorrie/tmp/tcp-stall.png

 This is happening since:

 commit 9a568de4818dea9a05af141046bd3e589245ab83
 Author: Eric Dumazet 
 Date:   Tue May 16 14:00:14 2017 -0700

 tcp: switch TCP TS option (RFC 7323) to 1ms clock

 [...]

> [...]
>
> 3. Since this is related to time and clocks, the last thing today we
> tried was, instead of using default settings, put "clocksource=tsc
> tsc=stable:socket" on the xen command line and "clocksource=tsc" on the
> domU linux kernel line. What we observed after doing this, is that the
> failure happens less often, but still happens. Everything else applies.

 Actually, it seems that the important thing is that uptime of the dom0s
 is not very close to each other. After rebooting all four back without
 tsc options, and then a few hours later rebooting one of them again, I
 could easily reproduce again when live migrating to the later rebooted
 server.

> Additional question:
>
> It's 2018, should we have these "clocksource=tsc tsc=stable:socket" on
> Xen and "clocksource=tsc" anyways now, for Xen 4.11 and Linux 4.19
> domUs? All our hardware has 'TscInvariant = true'.
>
> Related: https://news.ycombinator.com/item?id=13813079

 This is still interesting.

  >8 

 Now, the next question is... is 9a568de481 bad, or shouldn't there be 18
 gazillion whatever uptime already... In Linux 4.9, this doesn't happen,
 so next task will be to find out where that started.
>>>
>>> And that's...
>>>
>>> commit f94c8d116997597fc00f0812b0ab9256e7b0c58f
>>> Author: Peter Zijlstra 
>>> Date:   Wed Mar 1 15:53:38 2017 +0100
>>>
>>> sched/clock, x86/tsc: Rework the x86 'unstable' sched_clock() interface
>>>
>>> a.k.a. v4.11-rc2~30^2
>>>
>>> Before this commit, time listed in dmesg seems to follow uptime of the
>>> domU, and after it, time in dmesg seems to jump around up and down when
>>> live migrating to different dom0s, with the occasional/frequent jump to
>>> a number above 180 which then also shows the TCP timestamp
>>> breakage since 9a568de4.
>>>
>>> So, next question is... what now? Any ideas appreciated.
>>>
>>> Can anyone else reproduce this? I have super-common HP DL360 hardware
>>> and mostly default settings, so it shouldn't be that hard.
>>>
>>> Should I mail some other mailinglist with a question? Which one? Does
>>> any of you Xen developers have more experience with time keeping code?
>>
>> My gut feeling tells me that above patch was neglecting Xen by setting
>> a non-native TSC clock too often to "stable" (the "only call
>> clear_sched_clock_stable() when we mark TSC unstable when we use
>> native_sched_clock()" part of the commit message).
>>
>> I can have a more thorough look after Jan. 7th.
> 
> Thanks in advance!
> 
> Some additional info:
> 
> I've just left a domU running after the initial live migrate:
> 
> [  171.727462] Freezing user space processes ... (elapsed 0.002 seconds)
> done.
> [  171.729825] OOM killer disabled.
> [  171.729832] Freezing remaining freezable tasks ... (elapsed 0.001
> seconds) 

[Xen-devel] [PATCH 0/6] clean up MSR save/restore code

[Paul Durrant]

Patch #6 is not strictly related to save/restore. It's just clean-up of
something I noticed along the way.

Paul Durrant (6):
  x86: stop handling MSR_IA32_BNDCFGS save/restore in implementation
code
  x86: save GUEST_BNDCFGS on context switch...
  x86: move the saved value of MSR_IA32_XSS into struct vcpu_msrs
  x86: stop handling MSR_IA32_XSS save/restore in implementation code
  x86: remove defunct init/load/save_msr() hvm_funcs
  x86: introduce dr_mask_idx() helper function...

 xen/arch/x86/domain.c  |   2 +-
 xen/arch/x86/hvm/hvm.c | 102 -
 xen/arch/x86/hvm/vmx/vmx.c |  83 +++
 xen/arch/x86/msr.c |  48 +++-
 xen/arch/x86/pv/emul-priv-op.c |   2 +-
 xen/include/asm-x86/hvm/hvm.h  |  17 ++
 xen/include/asm-x86/hvm/vcpu.h |   1 -
 xen/include/asm-x86/msr.h  |  33 ++-
 8 files changed, 133 insertions(+), 155 deletions(-)
---
Cc: Andrew Cooper 
Cc: Jan Beulich 
Cc: Jun Nakajima 
Cc: Kevin Tian 
Cc: "Roger Pau Monné" 
Cc: Wei Liu 
-- 
2.20.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH 5/6] x86: remove defunct init/load/save_msr() hvm_funcs

[Paul Durrant]

These hvm_funcs are no longer required since no MSR values are saved or
restored by implementation-specific code.

Signed-off-by: Paul Durrant 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Wei Liu 
Cc: "Roger Pau Monné" 
---
 xen/arch/x86/hvm/hvm.c| 31 ++-
 xen/include/asm-x86/hvm/hvm.h |  4 
 2 files changed, 10 insertions(+), 25 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 856dcf696b..199aa0c148 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1351,7 +1351,6 @@ static const uint32_t msrs_to_send[] = {
 MSR_AMD64_DR2_ADDRESS_MASK,
 MSR_AMD64_DR3_ADDRESS_MASK,
 };
-static unsigned int __read_mostly msr_count_max = ARRAY_SIZE(msrs_to_send);
 
 static int hvm_save_cpu_msrs(struct vcpu *v, hvm_domain_context_t *h)
 {
@@ -1361,7 +1360,7 @@ static int hvm_save_cpu_msrs(struct vcpu *v, 
hvm_domain_context_t *h)
 int err;
 
 err = _hvm_init_entry(h, CPU_MSR_CODE, v->vcpu_id,
- HVM_CPU_MSR_SIZE(msr_count_max));
+ HVM_CPU_MSR_SIZE(ARRAY_SIZE(msrs_to_send)));
 if ( err )
 return err;
 ctxt = (struct hvm_msr *)>data[h->cur];
@@ -1394,10 +1393,7 @@ static int hvm_save_cpu_msrs(struct vcpu *v, 
hvm_domain_context_t *h)
 ctxt->msr[ctxt->count++].val = val;
 }
 
-if ( hvm_funcs.save_msr )
-hvm_funcs.save_msr(v, ctxt);
-
-ASSERT(ctxt->count <= msr_count_max);
+ASSERT(ctxt->count <= ARRAY_SIZE(msrs_to_send));
 
 for ( i = 0; i < ctxt->count; ++i )
 ctxt->msr[i]._rsvd = 0;
@@ -1472,10 +1468,7 @@ static int hvm_load_cpu_msrs(struct domain *d, 
hvm_domain_context_t *h)
 return -EOPNOTSUPP;
 /* Checking finished */
 
-if ( hvm_funcs.load_msr )
-err = hvm_funcs.load_msr(v, ctxt);
-
-for ( i = 0; !err && i < ctxt->count; ++i )
+for ( i = 0; i < ctxt->count; ++i )
 {
 switch ( ctxt->msr[i].index )
 {
@@ -1516,17 +1509,13 @@ static int __init 
hvm_register_CPU_save_and_restore(void)
 sizeof(struct hvm_save_descriptor),
 HVMSR_PER_VCPU);
 
-if ( hvm_funcs.init_msr )
-msr_count_max += hvm_funcs.init_msr();
-
-if ( msr_count_max )
-hvm_register_savevm(CPU_MSR_CODE,
-"CPU_MSR",
-hvm_save_cpu_msrs,
-hvm_load_cpu_msrs,
-HVM_CPU_MSR_SIZE(msr_count_max) +
-sizeof(struct hvm_save_descriptor),
-HVMSR_PER_VCPU);
+hvm_register_savevm(CPU_MSR_CODE,
+"CPU_MSR",
+hvm_save_cpu_msrs,
+hvm_load_cpu_msrs,
+HVM_CPU_MSR_SIZE(ARRAY_SIZE(msrs_to_send)) +
+sizeof(struct hvm_save_descriptor),
+HVMSR_PER_VCPU);
 
 return 0;
 }
diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
index 5c8237e087..a7b08d1db3 100644
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -115,10 +115,6 @@ struct hvm_function_table {
 void (*save_cpu_ctxt)(struct vcpu *v, struct hvm_hw_cpu *ctxt);
 int (*load_cpu_ctxt)(struct vcpu *v, struct hvm_hw_cpu *ctxt);
 
-unsigned int (*init_msr)(void);
-void (*save_msr)(struct vcpu *, struct hvm_msr *);
-int (*load_msr)(struct vcpu *, struct hvm_msr *);
-
 /* Examine specifics of the guest state. */
 unsigned int (*get_interrupt_shadow)(struct vcpu *v);
 void (*set_interrupt_shadow)(struct vcpu *v, unsigned int intr_shadow);
-- 
2.20.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v1] mm/page_alloc: fix MEMF_no_dma allocations for single NUMA

[Jan Beulich]

>>> On 07.01.19 at 12:27,  wrote:
> Currently dma_bitsize is zero by default on single NUMA node machines.
> This makes all alloc_domheap_pages() calls with MEMF_no_dma return NULL.
> 
> There is only 1 user of MEMF_no_dma: dom0_memflags, which are used
> during memory allocation for Dom0. Failing allocation with default
> dom0_memflags is especially severe for the PV Dom0 case: it makes
> alloc_chunk() to use suboptimal 2MB allocation algorithm with a search
> for higher memory addresses.
> 
> This can lead to the NMI watchdog timeout during PV Dom0 construction
> on some machines, which can be worked around by specifying "dma_bits"
> in Xen's cmdline manually.
> 
> Fix the issue by initialising dma_bitsize even on single NUMA machines.

I've not yet looked at why exactly this was done for multi-node
systems only, but in any event this change renders somewhat
stale the comment next to the dma_bitsize definition.

> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -1863,7 +1863,7 @@ void __init end_boot_allocator(void)
>  nr_bootmem_regions = 0;
>  init_heap_pages(virt_to_page(bootmem_region_list), 1);
>  
> -if ( !dma_bitsize && (num_online_nodes() > 1) )
> +if ( !dma_bitsize )
>  dma_bitsize = arch_get_dma_bitsize();

Did you consider the alternative of leaving this code alone and
instead doing

if ( !dma_bitsize )
memflags &= ~MEMF_no_dma;
else if ( (dma_zone = bits_to_zone(dma_bitsize)) < zone_hi )
pg = alloc_heap_pages(dma_zone + 1, zone_hi, order, memflags, d);

in alloc_domheap_pages(), which would also address the same
issue in the case of arch_get_dma_bitsize() returning zero?

Jan



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] GRUB Xen PVH chainloading

[Juergen Gross]

On 07/01/2019 12:41, Colin Watson wrote:
> Hi,
> 
> I'm working on integrating the recently-merged PVH support for GRUB into
> the Debian packages.  As a result I find myself thinking about how to
> handle the two-stage boot loader scheme that our packages currently
> implement for PV.  I think that it would not be very hard to do this for
> PVH in the manner outlined below, but my x86 asm skills aren't quite up
> to some of the work needed in GRUB.  Assuming that nobody sees any
> obvious holes in this, does anyone fancy giving it a go?

Seems to be a very good idea.

> Background
> --
> 
> Around the time PV support was implemented in GRUB 2, we put together a
> scheme to minimise the coupling between the guest configuration file on
> the host and the boot loader configuration in the guest.  The scheme and
> its rationale are described here:
> 
>   
> https://wiki.xen.org/wiki/PvGrub2#Chainloading_guest_pvgrub2_from_domain_0_pvgrub2
> 
> Essentially the same rationale applies to the PVH case: it should be
> possible for the guest to declare its own booting arrangements (though
> of course some hosts may wish to just provide a grub.cfg and handle all
> that on the host side), and this should be decoupled from the GRUB image
> provided by the host as far as possible in order to minimise
> compatibility issues.
> 
> There seems to be no obstacle to this in principle: just as a PV boot
> loader can chainload another one from the guest's disk, so too could a
> PVH boot loader chainload another one from the guest's disk.
> 
> What needs to be done
> -
> 
> GRUB needs to support chainloading another PVH boot loader.  I think
> this involves observing the existence of the XEN_ELFNOTE_PHYS32_ENTRY
> note and following the machine state rules for the domain builder here:
> 
>   https://xenbits.xen.org/docs/unstable-staging/misc/pvh.html
> 
> (I had a brief go at implementing this, but foundered on my fairly
> minimal understanding of GRUB's relocator/boot code.)

The needed effort should indeed be rather small.

In the moment I have no idea when I'll be able to do it, as I have
plenty of other things to do. In case you want to try it and need some
hints, please feel free to ask (maybe I'm able to give an answer
without having to try to implement it myself ;-) ).

> We need to define a modification to
> https://xenbits.xen.org/docs/unstable-staging/misc/x86-xenpv-bootloader.html
> for PVH boot loaders.  I suggest the obvious: a second-stage PVH boot
> loader should be installed into the guest filesystem as
> /boot/xen/pvhboot-.elf, and otherwise things generally behave the
> same way.  I'd be happy to draft a patch to the protocol specification
> once a proof-of-concept exists.
> 
> The as-yet-unmerged GRUB patch to support the existing PV boot protocol
> (https://salsa.debian.org/grub-team/grub/blob/master/debian/patches/grub-install-pvxen-paths.patch)
> needs to be extended to support the amended protocol.  This is trivial
> given the above.

Would you mind trying to upstream this patch? I have CC-ed Daniel Kiper
one of the grub2 maintainers), as I guess with his Xen skills he will be
the one looking at the patch.


Juergen

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 1/3] string: avoid undefined behavior in strrchr()

[Juergen Gross]

On 07/01/2019 10:39, Jan Beulich wrote:
> The pre-decrement would not only cause misbehavior when wrapping (benign
> because there shouldn't be any NULL pointers passed in), but may also
> create a pointer pointing outside the object that the passed in pointer
> points to (it won't be de-referenced though). Use post-decrement (and >
> instead of >= ) instead.

This commit message doesn't match the patch. There is no post-decrement
and '>' involved.

With that fixed you can add:

Reviewed-by: Juergen Gross 


Juergen

> 
> Take the opportunity and also
> - convert bogus space (partly 7 of them) indentation to Linux style tab
>   one,
> - add two blank lines.
> 
> Signed-off-by: Jan Beulich 
> 
> --- a/xen/common/string.c
> +++ b/xen/common/string.c
> @@ -174,12 +174,13 @@ char *(strchr)(const char *s, int c)
>   */
>  char *(strrchr)(const char *s, int c)
>  {
> -   const char *p = s + strlen(s);
> -   do {
> -   if (*p == (char)c)
> -   return (char *)p;
> -   } while (--p >= s);
> -   return NULL;
> + const char *p = s + strlen(s);
> +
> + for (; *p != (char)c; --p)
> + if (p == s)
> + return NULL;
> +
> + return (char *)p;
>  }
>  #endif
>  
> 
> 
> 
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel
> 


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [ovmf test] 131784: regressions - FAIL

[osstest service owner]

flight 131784 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131784/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i3866 xen-buildfail REGR. vs. 129475
 build-i386-xsm6 xen-buildfail REGR. vs. 129475
 build-amd64-xsm   6 xen-buildfail REGR. vs. 129475
 build-amd64   6 xen-buildfail REGR. vs. 129475

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a

version targeted for testing:
 ovmf 46f4c9677c615d862649459392f8f55b3e6567c2
baseline version:
 ovmf 5ae3184d8c59f7bbb84bad482df6b8020ba58188

Last test of basis   129475  2018-11-05 21:13:11 Z   62 days
Failing since129526  2018-11-06 20:49:26 Z   61 days  249 attempts
Testing same since   131751  2019-01-05 09:12:54 Z2 days   13 attempts


People who touched revisions under test:
  Achin Gupta 
  Alex James 
  Ard Biesheuvel 
  Ashish Singhal 
  Bob Feng 
  bob.c.f...@intel.com 
  BobCF 
  Chasel Chiu 
  Chasel, Chiu 
  Chen A Chen 
  Dandan Bi 
  David Wei 
  Derek Lin 
  Eric Dong 
  Feng, Bob C 
  Fu Siyuan 
  Gary Lin 
  Hao Wu 
  Jaben Carsey 
  Jagadeesh Ujja 
  Jeff Brasen 
  Jian J Wang 
  Jiaxin Wu 
  Jiewen Yao 
  Laszlo Ersek 
  Leif Lindholm 
  Liming Gao 
  Liu Yu 
  Marc Zyngier 
  Marcin Wojtas 
  Mike Maslenkin 
  Ming Huang 
  Pedroa Liu 
  Ruiyu Ni 
  Sami Mujawar 
  shenglei 
  Shenglei Zhang 
  Siyuan Fu 
  Star Zeng 
  Sughosh Ganu 
  Sumit Garg 
  Sun, Zailiang 
  Thomas Abraham 
  Thomas Rydman 
  Ting Ye 
  Tomasz Michalec 
  Vijayenthiran Subramaniam 
  Vladimir Olovyannikov 
  Wang BinX A 
  Wu Jiaxin 
  Ye Ting 
  Yonghong Zhu 
  yuchenlin 
  Zailiang Sun 
  Zhang, Chao B 
  Zhao, ZhiqiangX 
  Zhiju.Fan 
  zhijufan 
  ZhiqiangX Zhao 
  zwei4 

jobs:
 build-amd64-xsm  fail
 build-i386-xsm   fail
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 4888 lines long.)

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 3/4] x86/passthrough: put the x86 folder under x86 maintainership

[Jan Beulich]

>>> On 07.01.19 at 13:14,  wrote:
> On Mon, Jan 07, 2019 at 02:51:54AM -0700, Jan Beulich wrote:
>> >>> On 04.01.19 at 11:33,  wrote:
>> > passthrough/x86 is tied to the x86 code, and as such put it under x86
>> > maintainership.
>> 
>> It is tied to both, so at the very least I object to ...
>> 
>> > --- a/MAINTAINERS
>> > +++ b/MAINTAINERS
>> > @@ -257,6 +257,7 @@ F: xen/drivers/passthrough/
>> >  X:xen/drivers/passthrough/amd/
>> >  X:xen/drivers/passthrough/arm/
>> >  X:xen/drivers/passthrough/vtd/
>> > +X:xen/drivers/passthrough/x86/
>> 
>> ... this; the Arm entry here is questionable too, imo.
>> 
>> > @@ -445,6 +446,7 @@ R: Roger Pau Monné 
>> >  S:Supported
>> >  L:xen-devel@lists.xenproject.org 
>> >  F:xen/arch/x86/
>> > +F:xen/drivers/passthrough/x86/
>> 
>> This one's debatable.
> 
> So you would agree to adding xen/drivers/passthrough/x86/ under x86
> maintainership as long as it's also left under the generic IOMMU
> support entry?

"Agree" goes to far; I think this is worth considering. I'm also not
opposed to leaving things as they are.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 2/4] x86/passthrough: move io.c to the x86 subfolder

[Jan Beulich]

>>> On 07.01.19 at 13:11,  wrote:
> On Fri, Jan 04, 2019 at 10:03:21AM -0700, Jan Beulich wrote:
>> >>> On 04.01.19 at 11:33,  wrote:
>> > It makes no sense for io.c to be on the top level passthrough
>> > directory, since it's x86 specific.
>> 
>> I'm not sure it really is. It's largely about interrupt arrangements
>> for guests, which (being PCI-related) may or may not be re-
>> usable by Arm once they get to support PCI.
> 
> The file makes heavy usage of x86 only constructs, like
> hvm_pirq_dpci, hvm_irq_dpci and a lot of x86 specific HVM functions.
> 
> This could indeed be used by ARM in the future if such functions and
> structures are implemented on ARM, but it would certainly require
> a non-trivial amount of changes to this file and other code.
> 
> As it stands now this code is x86 specific, and as such it makes more
> sense IMO to reside in the x86 sub-folder.

Well, as said - I'd like to hear an Arm side opinion first.

> I agree it makes sense to rename, maybe x86/irq.c or x86/interrupt.c?

I have a slight preference for the former.

Jan



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 3/3] string: fix type use in strstr()

[Juergen Gross]

On 07/01/2019 10:40, Jan Beulich wrote:
> Using plain int for string lengths, while okay for all practical
> purposes, is undesirable in a generic library function.
> 
> Take the opportunity and also move the function from being in the middle
> of mem*() ones to the set of str*() ones, convert its loop from while()
> to for(), and correct style.
> 
> Signed-off-by: Jan Beulich 

Reviewed-by: Juergen Gross 


Juergen

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] xen/build-id: Fix xen_build_id_check() to be robust against malformed notes

[Jan Beulich]

>>> On 31.12.18 at 18:34,  wrote:
> A NT_GNU_BUILD_ID with namesz longer than 4 will cause the strncmp() to use
> bytes in adjacent stringtable entries.
> 
> Instead, check for namesz exactly equal to 4,

Is that a requirement spelled out anywhere? Till now I've been
under the impression that e.g. 8 bytes of name are fine as well,
as long as the first four of them are "GNU\0".

Jan



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Live migrate with Linux >= 4.13 domU causes kernel time jumps and TCP connection stalls.

[Hans van Kranenburg]

On 1/7/19 1:04 PM, Juergen Gross wrote:
> On 28/12/2018 15:41, Hans van Kranenburg wrote:
>> On 12/28/18 11:15 AM, Juergen Gross wrote:
>>
>> [...]
>> So that explains the 18446742891.874140 number, which just corresponds
>> to something near to 'minus 23 minutes'.
> 
> I have a local reproducer for the issue now: instead of using live
> migration I'm just doing a "xl save" after the guest running for some
> minutes. The I reboot the host and do a "xl restore" as soon as
> possible.
> 
> Another note: HVM domains (and probably PVH, too) show the huge time
> info ("[18446742937.583537] ..."), while PV domains seem to show just
> a small jump backwards in time:
> 
> [  224.719316] Freezing user space processes ... (elapsed 0.001 seconds)
> done.
> [  224.720443] OOM killer disabled.
> [  224.720448] Freezing remaining freezable tasks ... (elapsed 0.001
> seconds) done.
> [  224.721678] PM: freeze of devices complete after 0.107 msecs
> [  224.721687] suspending xenstore...
> [  224.721726] PM: late freeze of devices complete after 0.037 msecs
> [  224.736062] PM: noirq freeze of devices complete after 14.325 msecs
> [  224.736155] xen:grant_table: Grant tables using version 1 layout
> [4.404026] Suspended for 187.219 seconds

And if you cause a time difference that lets it go down below zero?

I can just as easily reproduce with PV, and don't see much difference in
behavior with PVH. Actually, all the bisect steps to find it were done
using PV.

I haven't tried HVM, since I'm not using that at all.

Hans
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Live migrate with Linux >= 4.13 domU causes kernel time jumps and TCP connection stalls.

[Juergen Gross]

On 07/01/2019 13:56, Hans van Kranenburg wrote:
> On 1/7/19 1:04 PM, Juergen Gross wrote:
>> On 28/12/2018 15:41, Hans van Kranenburg wrote:
>>> On 12/28/18 11:15 AM, Juergen Gross wrote:
>>>
>>> [...]
>>> So that explains the 18446742891.874140 number, which just corresponds
>>> to something near to 'minus 23 minutes'.
>>
>> I have a local reproducer for the issue now: instead of using live
>> migration I'm just doing a "xl save" after the guest running for some
>> minutes. The I reboot the host and do a "xl restore" as soon as
>> possible.
>>
>> Another note: HVM domains (and probably PVH, too) show the huge time
>> info ("[18446742937.583537] ..."), while PV domains seem to show just
>> a small jump backwards in time:
>>
>> [  224.719316] Freezing user space processes ... (elapsed 0.001 seconds)
>> done.
>> [  224.720443] OOM killer disabled.
>> [  224.720448] Freezing remaining freezable tasks ... (elapsed 0.001
>> seconds) done.
>> [  224.721678] PM: freeze of devices complete after 0.107 msecs
>> [  224.721687] suspending xenstore...
>> [  224.721726] PM: late freeze of devices complete after 0.037 msecs
>> [  224.736062] PM: noirq freeze of devices complete after 14.325 msecs
>> [  224.736155] xen:grant_table: Grant tables using version 1 layout
>> [4.404026] Suspended for 187.219 seconds
> 
> And if you cause a time difference that lets it go down below zero?

Oh yes, of course it will show the same symptoms. Silly me!


Juergen

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 2/3] string: remove memscan()

[Juergen Gross]

On 07/01/2019 10:39, Jan Beulich wrote:
> It has no users, so rather than fixing its use of types (first and
> foremost c would need to be cast to unsigned char in the comparison
> expression) drop it altogether. memchr() ought to be fine for all
> purposes.
> 
> Take the opportunity and also do some stylistic adjustments to its
> surviving sibling function memchr().
> 
> Signed-off-by: Jan Beulich 
> 
> --- a/xen/common/string.c
> +++ b/xen/common/string.c
> @@ -380,30 +380,6 @@ int (memcmp)(const void *cs, const void
>  }
>  #endif
>  
> -#ifndef __HAVE_ARCH_MEMSCAN
> -/**
> - * memscan - Find a character in an area of memory.
> - * @addr: The memory area
> - * @c: The byte to search for
> - * @size: The size of the area.
> - *
> - * returns the address of the first occurrence of @c, or 1 byte past
> - * the area if @c is not found
> - */
> -void * memscan(void * addr, int c, size_t size)
> -{
> - unsigned char * p = (unsigned char *) addr;
> -
> - while (size) {
> - if (*p == c)
> - return (void *) p;
> - p++;
> - size--;
> - }
> - return (void *) p;
> -}
> -#endif
> -
>  #ifndef __HAVE_ARCH_STRSTR
>  /**
>   * strstr - Find the first substring in a %NUL terminated string
> @@ -441,14 +417,13 @@ char *(strstr)(const char *s1, const cha
>  void *(memchr)(const void *s, int c, size_t n)
>  {
>   const unsigned char *p = s;
> - while (n-- != 0) {
> - if ((unsigned char)c == *p++) {
> - return (void *)(p-1);
> - }
> - }
> +
> + while (n--)
> + if ((unsigned char)c == *p++)

White space damage.


Juergen

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 3/4] x86/passthrough: put the x86 folder under x86 maintainership

[Roger Pau Monné]

On Mon, Jan 07, 2019 at 02:51:54AM -0700, Jan Beulich wrote:
> >>> On 04.01.19 at 11:33,  wrote:
> > passthrough/x86 is tied to the x86 code, and as such put it under x86
> > maintainership.
> 
> It is tied to both, so at the very least I object to ...
> 
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -257,6 +257,7 @@ F:  xen/drivers/passthrough/
> >  X: xen/drivers/passthrough/amd/
> >  X: xen/drivers/passthrough/arm/
> >  X: xen/drivers/passthrough/vtd/
> > +X: xen/drivers/passthrough/x86/
> 
> ... this; the Arm entry here is questionable too, imo.
> 
> > @@ -445,6 +446,7 @@ R:  Roger Pau Monné 
> >  S: Supported
> >  L: xen-devel@lists.xenproject.org 
> >  F: xen/arch/x86/
> > +F: xen/drivers/passthrough/x86/
> 
> This one's debatable.

So you would agree to adding xen/drivers/passthrough/x86/ under x86
maintainership as long as it's also left under the generic IOMMU
support entry?

Thanks, Roger.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 2/4] x86/passthrough: move io.c to the x86 subfolder

[Roger Pau Monné]

On Fri, Jan 04, 2019 at 10:03:21AM -0700, Jan Beulich wrote:
> >>> On 04.01.19 at 11:33,  wrote:
> > It makes no sense for io.c to be on the top level passthrough
> > directory, since it's x86 specific.
> 
> I'm not sure it really is. It's largely about interrupt arrangements
> for guests, which (being PCI-related) may or may not be re-
> usable by Arm once they get to support PCI.

The file makes heavy usage of x86 only constructs, like
hvm_pirq_dpci, hvm_irq_dpci and a lot of x86 specific HVM functions.

This could indeed be used by ARM in the future if such functions and
structures are implemented on ARM, but it would certainly require
a non-trivial amount of changes to this file and other code.

As it stands now this code is x86 specific, and as such it makes more
sense IMO to reside in the x86 sub-folder.

I agree it makes sense to rename, maybe x86/irq.c or x86/interrupt.c?

Thanks, Roger.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [linux-linus test] 131772: regressions - FAIL

[osstest service owner]

flight 131772 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131772/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs. 
125898
 test-amd64-amd64-amd64-pvgrub  7 xen-bootfail REGR. vs. 125898
 test-amd64-amd64-xl-qcow2 7 xen-boot fail REGR. vs. 125898
 test-amd64-amd64-pair10 xen-boot/src_hostfail REGR. vs. 125898
 test-amd64-amd64-pair11 xen-boot/dst_hostfail REGR. vs. 125898
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 125898
 test-amd64-amd64-libvirt-vhd  7 xen-boot fail REGR. vs. 125898
 test-amd64-amd64-xl-multivcpu  7 xen-bootfail REGR. vs. 125898
 test-amd64-amd64-pygrub   7 xen-boot fail REGR. vs. 125898
 test-amd64-amd64-rumprun-amd64  7 xen-boot   fail REGR. vs. 125898
 test-amd64-amd64-libvirt-xsm  7 xen-boot fail REGR. vs. 125898
 test-amd64-amd64-libvirt-pair 10 xen-boot/src_host   fail REGR. vs. 125898
 test-amd64-amd64-libvirt-pair 11 xen-boot/dst_host   fail REGR. vs. 125898
 test-amd64-i386-examine   8 reboot   fail REGR. vs. 125898
 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 125898
 test-amd64-i386-xl-shadow 7 xen-boot fail REGR. vs. 125898
 test-amd64-i386-libvirt   7 xen-boot fail REGR. vs. 125898
 test-amd64-i386-xl7 xen-boot fail REGR. vs. 125898
 test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 125898
 test-amd64-i386-xl-qemut-debianhvm-amd64  7 xen-boot fail REGR. vs. 125898
 test-amd64-i386-rumprun-i386  7 xen-boot fail REGR. vs. 125898
 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 125898
 test-amd64-i386-libvirt-xsm   7 xen-boot fail REGR. vs. 125898
 test-amd64-amd64-xl-pvhv2-intel  7 xen-boot  fail REGR. vs. 125898
 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 125898
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  7 xen-boot fail REGR. vs. 125898
 test-amd64-i386-xl-qemut-win10-i386  7 xen-boot  fail REGR. vs. 125898
 test-amd64-i386-qemut-rhel6hvm-intel  7 xen-boot fail REGR. vs. 125898
 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 125898
 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 125898
 test-amd64-amd64-examine  8 reboot   fail REGR. vs. 125898
 test-amd64-i386-qemut-rhel6hvm-amd 13 guest-start.2  fail REGR. vs. 125898

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds  7 xen-boot fail REGR. vs. 125898

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-credit1   7 xen-bootfail baseline untested
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 125898
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 125898
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 125898
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 125898
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 125898
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 125898
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 125898
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 125898
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 

Re: [Xen-devel] status of non-live migration of HVM with libvirt

[Olaf Hering]

Am Fri, 4 Jan 2019 17:48:31 +0100
schrieb Olaf Hering :

> Am Fri, 4 Jan 2019 16:57:55 +0100
> schrieb Olaf Hering :
> 
> > worth keeping (and fixing) the concept of an "offline migration"  
> 
> And regarding the fix, it looks like qmp_xen_save_devices_state does not need 
> the concept of "live". Just shutdown the blockdevices and be done with it?

Anthony, it looks like 5d6c599fe1 ("migration, xen: Fix block image lock issue 
on live migration") went too far. Why does stopping the disks at the very end 
of the save/migrate process depend on "live"? During a migration the disks have 
to be released either way. During "xl save" the domU may continue to run, if 
'-c' was specified. 

It seems the 'live' parameter for xen-save-devices-state is not needed.

Olaf


pgp2TpNabZYIi.pgp
Description: Digitale Signatur von OpenPGP
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v3 2/3] x86/svm: Drop enum instruction_index and simplify svm_get_insn_len()

[Jan Beulich]

>>> On 31.12.18 at 12:37,  wrote:
> Passing a 32-bit integer index into an array with entries containing less than
> 32 bits of data is wasteful, and creates an unnecessary error condition of
> passing an out-of-range index.
> 
> The width of the X86EMUL_OPC() encoding is at most 24 bits, which leaves room
> for a modrm byte.

That's true for the 0x0f-prefix-space insns (and it's just 20 bits in that
case), but going this route we'd paint ourselves into a corner if we'd
ever have to add 0x0f38-, 0x0f3a-, or 0x8f0?-prefix-space insns.

Furthermore someone adjusting the encoding layout in x86_emulate.h
is very unlikely to notice breakage here until trying the resulting
binary - I strongly think some BUILD_BUG_ON() should be added to
make this apparent at build time.

> --- a/xen/include/asm-x86/hvm/svm/emulate.h
> +++ b/xen/include/asm-x86/hvm/svm/emulate.h
> @@ -19,33 +19,36 @@
>  #ifndef __ASM_X86_HVM_SVM_EMULATE_H__
>  #define __ASM_X86_HVM_SVM_EMULATE_H__
>  
> -/* Enumerate some standard instructions that we support */
> -enum instruction_index {
> -INSTR_INVD,
> -INSTR_WBINVD,
> -INSTR_CPUID,
> -INSTR_RDMSR,
> -INSTR_WRMSR,
> -INSTR_VMCALL,
> -INSTR_HLT,
> -INSTR_INT3,
> -INSTR_RDTSC,
> -INSTR_RDTSCP,
> -INSTR_PAUSE,
> -INSTR_XSETBV,
> -INSTR_VMRUN,
> -INSTR_VMLOAD,
> -INSTR_VMSAVE,
> -INSTR_STGI,
> -INSTR_CLGI,
> -INSTR_INVLPGA,
> -INSTR_ICEBP,
> -INSTR_MAX_COUNT /* Must be last - Number of instructions supported */
> -};
> +/*
> + * Encoding for svm_get_insn_len().  We take X86EMUL_OPC() for the main
> + * opcode, shifted left to make room for the ModRM byte.
> + */
> +#define INSTR_ENC(opc, modrm) (((unsigned int)(opc) << 8) | (modrm))

I can't seem to figure what good the cast does.

> +#define MODRM(mod, reg, rm) (((mod) << 6) | ((reg) << 3) | rm)

"rm" also wants to be parenthesized (or neither "mod" nor "reg" would
need to be).

Jan



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v4 2/2] xen/blkback: rework connect_ring() to avoid inconsistent xenstore 'ring-page-order' set by malicious blkfront

[Roger Pau Monné]

On Mon, Jan 07, 2019 at 01:35:59PM +0800, Dongli Zhang wrote:
> The xenstore 'ring-page-order' is used globally for each blkback queue and
> therefore should be read from xenstore only once. However, it is obtained
> in read_per_ring_refs() which might be called multiple times during the
> initialization of each blkback queue.
> 
> If the blkfront is malicious and the 'ring-page-order' is set in different
> value by blkfront every time before blkback reads it, this may end up at
> the "WARN_ON(i != (XEN_BLKIF_REQS_PER_PAGE * blkif->nr_ring_pages));" in
> xen_blkif_disconnect() when frontend is destroyed.
> 
> This patch reworks connect_ring() to read xenstore 'ring-page-order' only
> once.
> 
> Signed-off-by: Dongli Zhang 
> ---
> Changed since v1:
>   * change the order of xenstore read in read_per_ring_refs
>   * use xenbus_read_unsigned() in connect_ring()
> 
> Changed since v2:
>   * simplify the condition check as "(err != 1 && nr_grefs > 1)"
>   * avoid setting err as -EINVAL to remove extra one line of code
> 
> Changed since v3:
>   * exit at the beginning if !nr_grefs
>   * change the if statements to avoid test (err != 1) twice
>   * initialize a 'blkif' stack variable (refer to PATCH 1/2)
> 
>  drivers/block/xen-blkback/xenbus.c | 76 
> +-
>  1 file changed, 43 insertions(+), 33 deletions(-)
> 
> diff --git a/drivers/block/xen-blkback/xenbus.c 
> b/drivers/block/xen-blkback/xenbus.c
> index a4aadac..a2acbc9 100644
> --- a/drivers/block/xen-blkback/xenbus.c
> +++ b/drivers/block/xen-blkback/xenbus.c
> @@ -926,7 +926,7 @@ static int read_per_ring_refs(struct xen_blkif_ring 
> *ring, const char *dir)
>   int err, i, j;
>   struct xen_blkif *blkif = ring->blkif;
>   struct xenbus_device *dev = blkif->be->dev;
> - unsigned int ring_page_order, nr_grefs, evtchn;
> + unsigned int nr_grefs, evtchn;
>  
>   err = xenbus_scanf(XBT_NIL, dir, "event-channel", "%u",
> );
> @@ -936,43 +936,38 @@ static int read_per_ring_refs(struct xen_blkif_ring 
> *ring, const char *dir)
>   return err;
>   }
>  
> - err = xenbus_scanf(XBT_NIL, dev->otherend, "ring-page-order", "%u",
> -   _page_order);
> - if (err != 1) {
> - err = xenbus_scanf(XBT_NIL, dir, "ring-ref", "%u", 
> _ref[0]);
> + nr_grefs = blkif->nr_ring_pages;
> +
> + if (unlikely(!nr_grefs))
> + return -EINVAL;

Is this even possible? AFAICT read_per_ring_refs will always be called
with blkif->nr_ring_pages != 0?

If so, I would consider turning this into a BUG_ON/WARN_ON.

> +
> + for (i = 0; i < nr_grefs; i++) {
> + char ring_ref_name[RINGREF_NAME_LEN];
> +
> + snprintf(ring_ref_name, RINGREF_NAME_LEN, "ring-ref%u", i);
> + err = xenbus_scanf(XBT_NIL, dir, ring_ref_name,
> +"%u", _ref[i]);
> +
>   if (err != 1) {
> - err = -EINVAL;
> - xenbus_dev_fatal(dev, err, "reading %s/ring-ref", dir);
> - return err;
> - }
> - nr_grefs = 1;
> - } else {
> - unsigned int i;
> -
> - if (ring_page_order > xen_blkif_max_ring_order) {
> - err = -EINVAL;
> - xenbus_dev_fatal(dev, err, "%s/request %d ring page 
> order exceed max:%d",
> -  dir, ring_page_order,
> -  xen_blkif_max_ring_order);
> - return err;
> + if (nr_grefs == 1)
> + break;
> +

You need to either set err to EINVAL before calling xenbus_dev_fatal,
or call xenbus_dev_fatal with EINVAL as the second parameter.

> + xenbus_dev_fatal(dev, err, "reading %s/%s",
> +  dir, ring_ref_name);
> + return -EINVAL;
>   }
> + }
>  
> - nr_grefs = 1 << ring_page_order;
> - for (i = 0; i < nr_grefs; i++) {
> - char ring_ref_name[RINGREF_NAME_LEN];
> -
> - snprintf(ring_ref_name, RINGREF_NAME_LEN, "ring-ref%u", 
> i);
> - err = xenbus_scanf(XBT_NIL, dir, ring_ref_name,
> -"%u", _ref[i]);
> - if (err != 1) {
> - err = -EINVAL;
> - xenbus_dev_fatal(dev, err, "reading %s/%s",
> -  dir, ring_ref_name);
> - return err;
> - }
> + if (err != 1) {
> + WARN_ON(nr_grefs != 1);
> +
> + err = xenbus_scanf(XBT_NIL, dir, "ring-ref", "%u",
> +_ref[0]);
> + if (err != 1) {
> + xenbus_dev_fatal(dev, err, "reading %s/ring-ref", dir);

Second 

[Xen-devel] [PATCH RFC v1] x86/emulate: Send vm_event form emulate

[Alexandru Stefan ISAILA]

This patch aims to have mem access vm events sent from the emulator.
This is useful in the case of page-walks that have to emulate
instructions in access denied pages.

We use hvmemul_map_linear_addr() ro intercept r/w access and
hvmemul_insn_fetch() to intercept exec access.

First we try to send a vm event and if the event is sent then emulation
returns X86EMUL_ACCESS_EXCEPTION. If the event is not sent then the
emulation goes on as expected.

Signed-off-by: Alexandru Isaila 
---
 xen/arch/x86/hvm/emulate.c | 298 +
 xen/arch/x86/hvm/vm_event.c|   2 +-
 xen/arch/x86/mm/mem_access.c   |   4 +-
 xen/arch/x86/x86_emulate/x86_emulate.h |   1 +
 xen/include/asm-x86/hvm/emulate.h  |   4 +-
 5 files changed, 212 insertions(+), 97 deletions(-)

diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index 2d02ef1521..f43aed379b 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -26,6 +27,8 @@
 #include 
 #include 
 #include 
+#include 
+#include "../mm/mm-locks.h"
 
 static void hvmtrace_io_assist(const ioreq_t *p)
 {
@@ -530,6 +533,157 @@ static int hvmemul_do_mmio_addr(paddr_t mmio_gpa,
 return hvmemul_do_io_addr(1, mmio_gpa, reps, size, dir, df, ram_gpa);
 }
 
+static bool hvmemul_send_vm_event(paddr_t gpa, unsigned long gla, gfn_t gfn,
+  uint32_t pfec, struct hvm_emulate_ctxt *ctxt)
+{
+p2m_access_t access = p2m_access_n;
+struct p2m_domain *p2m = NULL;
+vm_event_request_t req = {};
+p2m_type_t p2mt;
+mfn_t mfn;
+
+if ( !ctxt->send_event || !pfec )
+return false;
+
+p2m = p2m_get_hostp2m(current->domain);
+if ( altp2m_active(current->domain) )
+p2m = p2m_get_altp2m(current);
+if ( !p2m )
+p2m = p2m_get_hostp2m(current->domain);
+
+gfn_lock(p2m, gfn, 0);
+mfn = p2m->get_entry(p2m, gfn, , , 0, NULL, NULL);
+gfn_unlock(p2m, gfn, 0);
+
+if ( mfn_eq(mfn, INVALID_MFN) )
+return false;
+
+switch ( access ) {
+case p2m_access_x:
+case p2m_access_rx:
+if ( pfec & PFEC_write_access )
+req.u.mem_access.flags = MEM_ACCESS_R | MEM_ACCESS_W;
+break;
+case p2m_access_w:
+case p2m_access_rw:
+if ( pfec & PFEC_insn_fetch )
+req.u.mem_access.flags = MEM_ACCESS_X;
+break;
+case p2m_access_r:
+case p2m_access_n:
+if ( pfec & PFEC_write_access )
+req.u.mem_access.flags |= MEM_ACCESS_R | MEM_ACCESS_W;
+if ( pfec & PFEC_insn_fetch )
+req.u.mem_access.flags |= MEM_ACCESS_X;
+break;
+default:
+return false;
+}
+
+if ( !req.u.mem_access.flags )
+return false; //no violation
+
+req.reason = VM_EVENT_REASON_MEM_ACCESS;
+req.u.mem_access.gfn = gfn_x(gfn);
+req.u.mem_access.flags |= MEM_ACCESS_FAULT_WITH_GLA | MEM_ACCESS_GLA_VALID;
+req.u.mem_access.gla = gla;
+req.u.mem_access.offset = gpa & ((1 << PAGE_SHIFT) - 1);
+
+if ( monitor_traps(current, true, ) < 0 )
+return false;
+
+return true;
+}
+
+/*
+ * Convert addr from linear to physical form, valid over the range
+ * [addr, addr + *reps * bytes_per_rep]. *reps is adjusted according to
+ * the valid computed range. It is always >0 when X86EMUL_OKAY is returned.
+ * @pfec indicates the access checks to be performed during page-table walks.
+*/
+static int hvmemul_linear_to_phys(
+unsigned long addr,
+paddr_t *paddr,
+unsigned int bytes_per_rep,
+unsigned long *reps,
+uint32_t pfec,
+struct hvm_emulate_ctxt *hvmemul_ctxt)
+{
+struct vcpu *curr = current;
+unsigned long pfn, npfn, done, todo, i, offset = addr & ~PAGE_MASK;
+int reverse;
+
+/*
+ * Clip repetitions to a sensible maximum. This avoids extensive looping in
+ * this function while still amortising the cost of I/O trap-and-emulate.
+ */
+*reps = min_t(unsigned long, *reps, 4096);
+
+/* With no paging it's easy: linear == physical. */
+if ( !(curr->arch.hvm.guest_cr[0] & X86_CR0_PG) )
+{
+*paddr = addr;
+return X86EMUL_OKAY;
+}
+
+/* Reverse mode if this is a backwards multi-iteration string operation. */
+reverse = (hvmemul_ctxt->ctxt.regs->eflags & X86_EFLAGS_DF) && (*reps > 1);
+
+if ( reverse && ((PAGE_SIZE - offset) < bytes_per_rep) )
+{
+/* Do page-straddling first iteration forwards via recursion. */
+paddr_t _paddr;
+unsigned long one_rep = 1;
+int rc = hvmemul_linear_to_phys(
+addr, &_paddr, bytes_per_rep, _rep, pfec, hvmemul_ctxt);
+if ( rc != X86EMUL_OKAY )
+return rc;
+pfn = _paddr >> PAGE_SHIFT;
+}
+else if ( (pfn = paging_gva_to_gfn(curr, addr, )) == 
gfn_x(INVALID_GFN) )
+{
+if ( pfec & (PFEC_page_paged | 

Re: [Xen-devel] [PATCH 1/3] string: avoid undefined behavior in strrchr()

[Jan Beulich]

>>> On 07.01.19 at 10:49,  wrote:
> On 07/01/2019 10:39, Jan Beulich wrote:
>> The pre-decrement would not only cause misbehavior when wrapping (benign
>> because there shouldn't be any NULL pointers passed in), but may also
>> create a pointer pointing outside the object that the passed in pointer
>> points to (it won't be de-referenced though). Use post-decrement (and >
>> instead of >= ) instead.
> 
> This commit message doesn't match the patch. There is no post-decrement
> and '>' involved.

Oh, indeed, that was stale from a first attempt, until I realized that
the post-decrement would make things only marginally better. I've
simply dropped that sentence.

> With that fixed you can add:
> 
> Reviewed-by: Juergen Gross 

Thanks, Jan



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v5 2/4] xen/arm: use SYMBOL when required

[Jan Beulich]

>>> On 03.01.19 at 20:19,  wrote:
> Use SYMBOL in cases of comparisons and subtractions of:
> 
> _start, _end, __init_begin, __init_end,  __2M_text_end,
> __2M_rodata_start, __2M_rodata_end, __2M_init_start,__2M_init_end,
> __2M_rwdata_start, __2M_rwdata_end, _stext, _etext, _srodata, _erodata,
> __end_vpci_array, __start_vpci_array, _sinittext, _einittext,
> _stextentry, _etextentry, __start_bug_frames, __stop_bug_frames_0,
> __stop_bug_frames_1, __stop_bug_frames_2,__stop_bug_frames_3,
> __note_gnu_build_id_start, __note_gnu_build_id_end, __start___ex_table,
> __stop___ex_table, __start___pre_ex_table, __stop___pre_ex_table,
> __lock_profile_start, __lock_profile_end, __param_start,
> __param_end, __setup_start, __setup_end, __initcall_start,
> __initcall_end, __presmp_initcall_end, __trampoline_rel_start,
> __trampoline_rel_stop, __trampoline_seg_start, __trampoline_seg_stop
> __alt_instructions, __alt_instructions_end, __ctors_start, __ctors_end,
> __end_schedulers_array, __start_schedulers_array, __bss_start,
> __bss_end, __per_cpu_start, __per_cpu_data_end, _splatform, _eplatform,
> _sdevice, _edevice, _asdevice, _aedevice, __proc_info_start,
> __proc_info_end, _sdtb

Didn't you go a little too far with copy-and-paste here? I don't think
all of the symbols really exist in Arm (and similarly in the x86 instance
I think there are some Arm-only symbols).

Jan



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] libxl: get_reaper_lock_and_uid: Document fd handling

[George Dunlap]

> On Jan 2, 2019, at 10:03 PM, Ian Jackson  wrote:
> 
> Coverity understandably complains that get_reaper_lock_and_uid leaks
> the fd and hence open-file.  But this is intentional: the lock becomes
> owned by the child process as a whole, which is entirely the property
> of libxl.
> 
> (The coding style here in this subprocess is a bit anomalous but it's
> probably not worth it to convert get_reaper_lock_and_uid to `goto out'
> style and have it explicitly return the fd number.)
> 
> Signed-off-by: Ian Jackson 

Acked-by: George Dunlap 


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 2/3] libx86: introduce a helper to deserialise msr_policy objects

[Jan Beulich]

>>> On 04.01.19 at 16:33,  wrote:
> From: Roger Pau Monné 
> 
> Signed-off-by: Sergey Dyasli 
> Signed-off-by: Roger Pau Monné 
> Signed-off-by: Andrew Cooper 

Where applicable, same comments here as for patch 1.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 4/4] x86/shim: only mark special pages as RAM in pvshim mode

[Roger Pau Monné]

On Thu, Dec 27, 2018 at 09:03:43PM +, Andrew Cooper wrote:
> On 27/12/2018 15:56, Roger Pau Monne wrote:
> > When running Xen as a guest it's not necessary to mark such pages as
> > RAM because they won't be assigned to the initial domain memory map.
> >
> > While there move the functions to the PV shim specific file and rename
> > them accordingly.
> >
> > No functional change expected.
> >
> > Reported-by: Andrew Cooper 
> > Signed-off-by: Roger Pau Monné 
> 
> Reviewed-by: Andrew Cooper 

I think this one can go in (if no one objects) regardless of the rest
of the series.

Thanks, Roger.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] GRUB Xen PVH chainloading

[Colin Watson]

Hi,

I'm working on integrating the recently-merged PVH support for GRUB into
the Debian packages.  As a result I find myself thinking about how to
handle the two-stage boot loader scheme that our packages currently
implement for PV.  I think that it would not be very hard to do this for
PVH in the manner outlined below, but my x86 asm skills aren't quite up
to some of the work needed in GRUB.  Assuming that nobody sees any
obvious holes in this, does anyone fancy giving it a go?

Background
--

Around the time PV support was implemented in GRUB 2, we put together a
scheme to minimise the coupling between the guest configuration file on
the host and the boot loader configuration in the guest.  The scheme and
its rationale are described here:

  
https://wiki.xen.org/wiki/PvGrub2#Chainloading_guest_pvgrub2_from_domain_0_pvgrub2

Essentially the same rationale applies to the PVH case: it should be
possible for the guest to declare its own booting arrangements (though
of course some hosts may wish to just provide a grub.cfg and handle all
that on the host side), and this should be decoupled from the GRUB image
provided by the host as far as possible in order to minimise
compatibility issues.

There seems to be no obstacle to this in principle: just as a PV boot
loader can chainload another one from the guest's disk, so too could a
PVH boot loader chainload another one from the guest's disk.

What needs to be done
-

GRUB needs to support chainloading another PVH boot loader.  I think
this involves observing the existence of the XEN_ELFNOTE_PHYS32_ENTRY
note and following the machine state rules for the domain builder here:

  https://xenbits.xen.org/docs/unstable-staging/misc/pvh.html

(I had a brief go at implementing this, but foundered on my fairly
minimal understanding of GRUB's relocator/boot code.)

We need to define a modification to
https://xenbits.xen.org/docs/unstable-staging/misc/x86-xenpv-bootloader.html
for PVH boot loaders.  I suggest the obvious: a second-stage PVH boot
loader should be installed into the guest filesystem as
/boot/xen/pvhboot-.elf, and otherwise things generally behave the
same way.  I'd be happy to draft a patch to the protocol specification
once a proof-of-concept exists.

The as-yet-unmerged GRUB patch to support the existing PV boot protocol
(https://salsa.debian.org/grub-team/grub/blob/master/debian/patches/grub-install-pvxen-paths.patch)
needs to be extended to support the amended protocol.  This is trivial
given the above.

Thanks,

-- 
Colin Watson   [cjwat...@debian.org]

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v4 2/2] xen/blkback: rework connect_ring() to avoid inconsistent xenstore 'ring-page-order' set by malicious blkfront

[Dongli Zhang]

On 01/07/2019 10:05 PM, Dongli Zhang wrote:
> 
> 
> On 01/07/2019 08:01 PM, Roger Pau Monné wrote:
>> On Mon, Jan 07, 2019 at 01:35:59PM +0800, Dongli Zhang wrote:
>>> The xenstore 'ring-page-order' is used globally for each blkback queue and
>>> therefore should be read from xenstore only once. However, it is obtained
>>> in read_per_ring_refs() which might be called multiple times during the
>>> initialization of each blkback queue.
>>>
>>> If the blkfront is malicious and the 'ring-page-order' is set in different
>>> value by blkfront every time before blkback reads it, this may end up at
>>> the "WARN_ON(i != (XEN_BLKIF_REQS_PER_PAGE * blkif->nr_ring_pages));" in
>>> xen_blkif_disconnect() when frontend is destroyed.
>>>
>>> This patch reworks connect_ring() to read xenstore 'ring-page-order' only
>>> once.
>>>
>>> Signed-off-by: Dongli Zhang 
>>> ---
>>> Changed since v1:
>>>   * change the order of xenstore read in read_per_ring_refs
>>>   * use xenbus_read_unsigned() in connect_ring()
>>>
>>> Changed since v2:
>>>   * simplify the condition check as "(err != 1 && nr_grefs > 1)"
>>>   * avoid setting err as -EINVAL to remove extra one line of code
>>>
>>> Changed since v3:
>>>   * exit at the beginning if !nr_grefs
>>>   * change the if statements to avoid test (err != 1) twice
>>>   * initialize a 'blkif' stack variable (refer to PATCH 1/2)
>>>
>>>  drivers/block/xen-blkback/xenbus.c | 76 
>>> +-
>>>  1 file changed, 43 insertions(+), 33 deletions(-)
>>>
>>> diff --git a/drivers/block/xen-blkback/xenbus.c 
>>> b/drivers/block/xen-blkback/xenbus.c
>>> index a4aadac..a2acbc9 100644
>>> --- a/drivers/block/xen-blkback/xenbus.c
>>> +++ b/drivers/block/xen-blkback/xenbus.c
>>> @@ -926,7 +926,7 @@ static int read_per_ring_refs(struct xen_blkif_ring 
>>> *ring, const char *dir)
>>> int err, i, j;
>>> struct xen_blkif *blkif = ring->blkif;
>>> struct xenbus_device *dev = blkif->be->dev;
>>> -   unsigned int ring_page_order, nr_grefs, evtchn;
>>> +   unsigned int nr_grefs, evtchn;
>>>  
>>> err = xenbus_scanf(XBT_NIL, dir, "event-channel", "%u",
>>>   );
>>> @@ -936,43 +936,38 @@ static int read_per_ring_refs(struct xen_blkif_ring 
>>> *ring, const char *dir)
>>> return err;
>>> }
>>>  
>>> -   err = xenbus_scanf(XBT_NIL, dev->otherend, "ring-page-order", "%u",
>>> - _page_order);
>>> -   if (err != 1) {
>>> -   err = xenbus_scanf(XBT_NIL, dir, "ring-ref", "%u", 
>>> _ref[0]);
>>> +   nr_grefs = blkif->nr_ring_pages;
>>> +
>>> +   if (unlikely(!nr_grefs))
>>> +   return -EINVAL;
>>
>> Is this even possible? AFAICT read_per_ring_refs will always be called
>> with blkif->nr_ring_pages != 0?
>>
>> If so, I would consider turning this into a BUG_ON/WARN_ON.
> 
> It used to be "WARN_ON(!nr_grefs);" in the v3 of the patch.
> 
> I would turn it into WARN_ON if it is fine with both Paul and you.

To clarify, I would use WARN_ON() before exit with -EINVAL (when
blkif->nr_ring_pages is 0).

Dongli Zhang

> 
> I prefer WARN_ON because it would remind the developers in the future that
> read_per_ring_refs() should be used only when blkif->nr_ring_pages != 0.
> 
>>
>>> +
>>> +   for (i = 0; i < nr_grefs; i++) {
>>> +   char ring_ref_name[RINGREF_NAME_LEN];
>>> +
>>> +   snprintf(ring_ref_name, RINGREF_NAME_LEN, "ring-ref%u", i);
>>> +   err = xenbus_scanf(XBT_NIL, dir, ring_ref_name,
>>> +  "%u", _ref[i]);
>>> +
>>> if (err != 1) {
>>> -   err = -EINVAL;
>>> -   xenbus_dev_fatal(dev, err, "reading %s/ring-ref", dir);
>>> -   return err;
>>> -   }
>>> -   nr_grefs = 1;
>>> -   } else {
>>> -   unsigned int i;
>>> -
>>> -   if (ring_page_order > xen_blkif_max_ring_order) {
>>> -   err = -EINVAL;
>>> -   xenbus_dev_fatal(dev, err, "%s/request %d ring page 
>>> order exceed max:%d",
>>> -dir, ring_page_order,
>>> -xen_blkif_max_ring_order);
>>> -   return err;
>>> +   if (nr_grefs == 1)
>>> +   break;
>>> +
>>
>> You need to either set err to EINVAL before calling xenbus_dev_fatal,
>> or call xenbus_dev_fatal with EINVAL as the second parameter.
>>
>>> +   xenbus_dev_fatal(dev, err, "reading %s/%s",
>>> +dir, ring_ref_name);
>>> +   return -EINVAL;
>>> }
>>> +   }
>>>  
>>> -   nr_grefs = 1 << ring_page_order;
>>> -   for (i = 0; i < nr_grefs; i++) {
>>> -   char ring_ref_name[RINGREF_NAME_LEN];
>>> -
>>> -   snprintf(ring_ref_name, RINGREF_NAME_LEN, "ring-ref%u", 
>>> i);
>>> -   err = xenbus_scanf(XBT_NIL, dir, ring_ref_name,
>>> - 

[Xen-devel] [PATCH v8 05/18] xen: add xenstore watcher infrastructure

[Paul Durrant]

A Xen PV frontend communicates its state to the PV backend by writing to
the 'state' key in the frontend area in xenstore. It is therefore
necessary for a XenDevice implementation to be notified whenever the
value of this key changes.

This patch adds code to do this as follows:

- an 'fd handler' is registered on the libxenstore handle which will be
  triggered whenever a 'watch' event occurs
- primitives are added to xen-bus-helper to add or remove watch events
- a list of Notifier objects is added to XenBus to provide a mechanism
  to call the appropriate 'watch handler' when its associated event
  occurs

The xen-block implementation is extended with a 'frontend_changed' method,
which calls as-yet stub 'connect' and 'disconnect' functions when the
relevant frontend state transitions occur. A subsequent patch will supply
a full implementation for these functions.

Signed-off-by: Paul Durrant 
Reviewed-by: Anthony Perard 
---
Cc: Kevin Wolf 
Cc: Max Reitz 
Cc: Stefano Stabellini 

v5:
 - Re-base

v3:
 - Remove unnecessary instances of local_err

v2:
 - Don't crash when xen_block_disconnect() fails
 - Check xs_unwatch() for error
 - Add new_watch() and free_watch() utility functions
 - Use xs_check_watch() rather than xs_read_watch()
---
 hw/block/trace-events   |   2 +
 hw/block/xen-block.c|  70 +++
 hw/xen/trace-events |   6 +
 hw/xen/xen-bus-helper.c |  34 +
 hw/xen/xen-bus.c| 211 +++-
 include/hw/xen/xen-bus-helper.h |   6 +
 include/hw/xen/xen-bus.h|  15 +++
 7 files changed, 342 insertions(+), 2 deletions(-)

diff --git a/hw/block/trace-events b/hw/block/trace-events
index 4afbd62a88..89e258319c 100644
--- a/hw/block/trace-events
+++ b/hw/block/trace-events
@@ -130,6 +130,8 @@ xen_disk_free(char *name) "%s"
 
 # hw/block/xen-block.c
 xen_block_realize(const char *type, uint32_t disk, uint32_t partition) "%s 
d%up%u"
+xen_block_connect(const char *type, uint32_t disk, uint32_t partition) "%s 
d%up%u"
+xen_block_disconnect(const char *type, uint32_t disk, uint32_t partition) "%s 
d%up%u"
 xen_block_unrealize(const char *type, uint32_t disk, uint32_t partition) "%s 
d%up%u"
 xen_disk_realize(void) ""
 xen_disk_unrealize(void) ""
diff --git a/hw/block/xen-block.c b/hw/block/xen-block.c
index d27a2865bc..3a963b0383 100644
--- a/hw/block/xen-block.c
+++ b/hw/block/xen-block.c
@@ -21,6 +21,24 @@ static char *xen_block_get_name(XenDevice *xendev, Error 
**errp)
 return g_strdup_printf("%lu", vdev->number);
 }
 
+static void xen_block_disconnect(XenDevice *xendev, Error **errp)
+{
+XenBlockDevice *blockdev = XEN_BLOCK_DEVICE(xendev);
+const char *type = object_get_typename(OBJECT(blockdev));
+XenBlockVdev *vdev = >props.vdev;
+
+trace_xen_block_disconnect(type, vdev->disk, vdev->partition);
+}
+
+static void xen_block_connect(XenDevice *xendev, Error **errp)
+{
+XenBlockDevice *blockdev = XEN_BLOCK_DEVICE(xendev);
+const char *type = object_get_typename(OBJECT(blockdev));
+XenBlockVdev *vdev = >props.vdev;
+
+trace_xen_block_connect(type, vdev->disk, vdev->partition);
+}
+
 static void xen_block_unrealize(XenDevice *xendev, Error **errp)
 {
 XenBlockDevice *blockdev = XEN_BLOCK_DEVICE(xendev);
@@ -35,6 +53,9 @@ static void xen_block_unrealize(XenDevice *xendev, Error 
**errp)
 
 trace_xen_block_unrealize(type, vdev->disk, vdev->partition);
 
+/* Disconnect from the frontend in case this has not already happened */
+xen_block_disconnect(xendev, NULL);
+
 if (blockdev_class->unrealize) {
 blockdev_class->unrealize(blockdev, errp);
 }
@@ -64,6 +85,54 @@ static void xen_block_realize(XenDevice *xendev, Error 
**errp)
 }
 }
 
+static void xen_block_frontend_changed(XenDevice *xendev,
+   enum xenbus_state frontend_state,
+   Error **errp)
+{
+enum xenbus_state backend_state = xen_device_backend_get_state(xendev);
+Error *local_err = NULL;
+
+switch (frontend_state) {
+case XenbusStateInitialised:
+case XenbusStateConnected:
+if (backend_state == XenbusStateConnected) {
+break;
+}
+
+xen_block_disconnect(xendev, _err);
+if (local_err) {
+error_propagate(errp, local_err);
+break;
+}
+
+xen_block_connect(xendev, _err);
+if (local_err) {
+error_propagate(errp, local_err);
+break;
+}
+
+xen_device_backend_set_state(xendev, XenbusStateConnected);
+break;
+
+case XenbusStateClosing:
+xen_device_backend_set_state(xendev, XenbusStateClosing);
+break;
+
+case XenbusStateClosed:
+xen_block_disconnect(xendev, _err);
+if (local_err) {
+error_propagate(errp, local_err);
+break;
+}
+
+xen_device_backend_set_state(xendev, XenbusStateClosed);
+   

[Xen-devel] [xen-unstable test] 131773: tolerable FAIL

[osstest service owner]

flight 131773 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131773/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 131755
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 131755
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 131755
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 131755
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 131755
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 131755
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 131755
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 131755
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 131755
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass

version targeted for testing:
 xen  a5b0eb363694e7e15405f0b3fc5fb6fab79df1db
baseline version:
 xen  a5b0eb363694e7e15405f0b3fc5fb6fab79df1db

Last test of basis   131773  2019-01-06 17:32:33 Z0 days
Testing same since  (not found) 0 attempts

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64-xtf  pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumprun  pass
 build-i386-rumprun   pass
 test-xtf-amd64-amd64-1

Re: [Xen-devel] [PATCH v1] xen: preserve COMPAT in CFLAGS

[Olaf Hering]

Am Thu, 13 Dec 2018 11:05:25 +
schrieb Anthony PERARD :

> Hi,
> 
> Ian, we have those XC_WANT_COMPAT_* #defines to allow consumers of Xen
> libs be able to use old interfaces. Do you think it's a good idea to
> have this consumers (QEMU here) #undef the flag when it has implemented
> the newer interface?

I think the wording is wrong.

The defines exist to expose existing APIs to software that was not updated to 
use the "latest" API. To me it looks like the undef's are wrong. Even the usage 
in configure looks bogus, but that is another unrelated thing.

Olaf


pgpKQGVksNTpr.pgp
Description: Digitale Signatur von OpenPGP
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v5 3/4] xen/x86: use SYMBOL when required

[Stefano Stabellini]

On Mon, 7 Jan 2019, Jan Beulich wrote:
> >>> On 03.01.19 at 20:19,  wrote:
> > --- a/xen/arch/x86/alternative.c
> > +++ b/xen/arch/x86/alternative.c
> > @@ -194,7 +194,7 @@ void init_or_livepatch apply_alternatives(struct 
> > alt_instr *start,
> >   * So be careful if you want to change the scan order to any other
> >   * order.
> >   */
> > -for ( a = base = start; a < end; a++ )
> > +for ( a = base = start; (unsigned long)a < SYMBOL(end); a++ )
> 
> As said before, imo SYMBOL() should only eve be applied _directly_
> to one of the (commonly linker script generated) symbols listed above,
> never to any derivatives.

This is the most problematic case for doing that. This issue also
highlights one of the problems mentioned in the thread about returning
unsigned long or native type from SYMBOL.

To address your comment, I could do the following:

apply_alternatives((struct alt_instr *)SYMBOL(__alt_instructions),
   (struct alt_instr *)SYMBOL(__alt_instructions_end));

But then, we would still have two pointers pointing to different objects
being compared in the implementation of apply_alternatives: `a' and
`end' would be pointers pointing to __alt_instructions and
__alt_instructions_end respectively. The MISRA-C violation would not be
addressed, I think. The same thing would happen here, and in many other
instances, if we switched SYMBOL to returning the native pointer type.

My preference would be to keep the code as-is in this patch and add an
in-code comment in apply_alternatives to explain the behavior.


> > @@ -1382,7 +1383,8 @@ void __init noreturn __start_xen(unsigned long mbi_p)
> >  }
> >  #endif
> >  
> > -xen_virt_end = ((unsigned long)_end + (1UL << L2_PAGETABLE_SHIFT) - 1) 
> > &
> > +xen_virt_end = (SYMBOL(_end) +
> > +(1UL << L2_PAGETABLE_SHIFT) - 1) &
> > ~((1UL << L2_PAGETABLE_SHIFT) - 1);
> 
> No need for the extra line split.

I'll remove

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [Qemu-devel] [PATCH 2/3] machine: Eliminate unnecessary stringify() usage

[Marc-André Lureau]

On Mon, Jan 7, 2019 at 11:32 PM Eduardo Habkost  wrote:
>
> stringify() is useful when we need to use macros in compat_props
> (like when we set virtio-baloon-pci.class=PCI_CLASS_MEMORY_RAM at
> pc_i440fx_1_0_machine_options()), but it is pointless when we are
> already providing a number literal.
>
> Replace stringify() with string literals when appropriate.
>
> Signed-off-by: Eduardo Habkost 

Reviewed-by: Marc-André Lureau 

> ---
>  hw/core/machine.c |  8 ++--
>  hw/i386/pc.c  | 94 +++
>  hw/i386/pc_piix.c | 30 +++
>  hw/ppc/spapr.c|  2 +-
>  4 files changed, 67 insertions(+), 67 deletions(-)
>
> diff --git a/hw/core/machine.c b/hw/core/machine.c
> index f8563efb86..4b4d6c23de 100644
> --- a/hw/core/machine.c
> +++ b/hw/core/machine.c
> @@ -135,11 +135,11 @@ GlobalProperty hw_compat_2_8[] = {
>  {
>  .driver   = "fw_cfg_mem",
>  .property = "x-file-slots",
> -.value= stringify(0x10),
> +.value= "0x10",
>  },{
>  .driver   = "fw_cfg_io",
>  .property = "x-file-slots",
> -.value= stringify(0x10),
> +.value= "0x10",
>  },{
>  .driver   = "pflash_cfi01",
>  .property = "old-multiple-chip-handling",
> @@ -337,11 +337,11 @@ GlobalProperty hw_compat_2_1[] = {
>  },{
>  .driver   = "usb-mouse",
>  .property = "usb_version",
> -.value= stringify(1),
> +.value= "1",
>  },{
>  .driver   = "usb-kbd",
>  .property = "usb_version",
> -.value= stringify(1),
> +.value= "1",
>  },{
>  .driver   = "virtio-pci",
>  .property = "virtio-pci-bus-master-bug-migration",
> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> index 4952feb476..ff14b6d4df 100644
> --- a/hw/i386/pc.c
> +++ b/hw/i386/pc.c
> @@ -148,11 +148,11 @@ GlobalProperty pc_compat_2_12[] = {
>  },{
>  .driver   = "EPYC-" TYPE_X86_CPU,
>  .property = "xlevel",
> -.value= stringify(0x800a),
> +.value= "0x800a",
>  },{
>  .driver   = "EPYC-IBPB-" TYPE_X86_CPU,
>  .property = "xlevel",
> -.value= stringify(0x800a),
> +.value= "0x800a",
>  },
>  };
>  const size_t pc_compat_2_12_len = G_N_ELEMENTS(pc_compat_2_12);
> @@ -191,7 +191,7 @@ GlobalProperty pc_compat_2_9[] = {
>  {
>  .driver   = "mch",
>  .property = "extended-tseg-mbytes",
> -.value= stringify(0),
> +.value= "0",
>  },
>  };
>  const size_t pc_compat_2_9_len = G_N_ELEMENTS(pc_compat_2_9);
> @@ -365,75 +365,75 @@ GlobalProperty pc_compat_2_3[] = {
>  },{
>  .driver   = "qemu64" "-" TYPE_X86_CPU,
>  .property = "min-level",
> -.value= stringify(4),
> +.value= "4",
>  },{
>  .driver   = "kvm64" "-" TYPE_X86_CPU,
>  .property = "min-level",
> -.value= stringify(5),
> +.value= "5",
>  },{
>  .driver   = "pentium3" "-" TYPE_X86_CPU,
>  .property = "min-level",
> -.value= stringify(2),
> +.value= "2",
>  },{
>  .driver   = "n270" "-" TYPE_X86_CPU,
>  .property = "min-level",
> -.value= stringify(5),
> +.value= "5",
>  },{
>  .driver   = "Conroe" "-" TYPE_X86_CPU,
>  .property = "min-level",
> -.value= stringify(4),
> +.value= "4",
>  },{
>  .driver   = "Penryn" "-" TYPE_X86_CPU,
>  .property = "min-level",
> -.value= stringify(4),
> +.value= "4",
>  },{
>  .driver   = "Nehalem" "-" TYPE_X86_CPU,
>  .property = "min-level",
> -.value= stringify(4),
> +.value= "4",
>  },{
>  .driver   = "n270" "-" TYPE_X86_CPU,
>  .property = "min-xlevel",
> -.value= stringify(0x800a),
> +.value= "0x800a",
>  },{
>  .driver   = "Penryn" "-" TYPE_X86_CPU,
>  .property = "min-xlevel",
> -.value= stringify(0x800a),
> +.value= "0x800a",
>  },{
>  .driver   = "Conroe" "-" TYPE_X86_CPU,
>  .property = "min-xlevel",
> -.value= stringify(0x800a),
> +.value= "0x800a",
>  },{
>  .driver   = "Nehalem" "-" TYPE_X86_CPU,
>  .property = "min-xlevel",
> -.value= stringify(0x800a),
> +.value= "0x800a",
>  },{
>  .driver   = "Westmere" "-" TYPE_X86_CPU,
>  .property = "min-xlevel",
> -.value= stringify(0x800a),
> +.value= "0x800a",
>  },{
>  .driver   = "SandyBridge" "-" TYPE_X86_CPU,
>  .property = "min-xlevel",
> -.value= stringify(0x800a),
> +.value= "0x800a",
>  },{
>  .driver   = "IvyBridge" "-" 

Re: [Xen-devel] [PATCH v2] xen/cmdline: Fix buggy strncmp(s, LITERAL, ss - s) construct

[Andrew Cooper]

On 07/01/2019 08:59, Jan Beulich wrote:
>> @@ -271,6 +297,27 @@ int parse_boolean(const char *name, const char *s, 
>> const char *e)
>>  return -1;
>>  }
>>  
>> +int cmdline_strcmp(const char *frag, const char *name)
> So you've decided to retain the strcmp()-like return type and value,
> despite them being of no interest to any caller, and it being
> vanishingly unlikely for a caller to appear which would care. Fine
> for now, but I'd still like to understand why.

You already asked this, and give no objection to my answer, I presumed
you were satisfied with the concrete usecase I gave, citing a patch
needing this behaviour which has already been posted to the list.



~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen (both x86 and Arm) Community Call: Jan 9 - 16:00 - 17:00 UTC - Call for Agenda Items

[Stefano Stabellini]

On Mon, 7 Jan 2019, Juergen Gross wrote:
> On 03/01/2019 15:28, Lars Kurth wrote:
> > Hi all,
> > 
> > based on Stefano's and Julien's suggestion that it may make sense to merge 
> > the x86 and arm calls, I am willing to try. It also makes sense this time 
> > in particular because we are approaching freeze time.
> > 
> > 
> > As per request the meeting is 1 hour later than normal. Also, because there 
> > were NO attendees from China on the last 3 calls. For Chinese attendees: if 
> > you plan to attend, please confirm you are attending and we can discuss 
> > moving the meeting to earlier.
> > 
> > @Juergen, @Jan: we can discuss the timing of future meetings going forward 
> > if 17:00-18:00 is a problem for you.
> > 
> > Please propose topics by either editing the running agenda document at 
> > https://docs.google.com/document/d/1Ufv9XcQO0zIAVeFbFCAHAeEIB9Ap4Y4srAm4vI8I01I/edit#
> >  or by replying to the mail. Ideally by next Tuesday!
> 
> I'd like to discuss status of the current pending patch series:
> 
> Series   Author Status
> Per-cpu tasklet  Konrad Rzeszutek Wilk  ->4.13?
> Improvements to domain creation (v2) Andrew Cooper  ?
> Argo (inter-VM communication) (v3)   Christopher Clark  ?
> Core aware sched (RFC v1)Dario Faggioli ->4.13?
> Core aware sched credit2 (RFC v1)Dario Faggioli ->4.13?
> x86 instr emulator add AVX512 (v7)   Jan Beulichfinished?
> HVM guest CPU topology support (RFC) Chao Gao   ->4.13?
> Intel Trace virt. enabling (v1)  Luwei Kang ->4.13?
> Linux stub domains (RFC v2)  Marek Marczykowski-G.  ->4.13?
> qemu deprivilege (v4)George Dunlap  finished?
> Improve late microcode loading (v4)  Chao Gao   ?
> Fixes to #DB injection   Andrew Cooper  ->4.13?
> CPUID/MSR Xen/toolstack improvements Andrew Cooper  ->4.13?
> Improvements to domain_crash()   Andrew Cooper  ->4.13?
> Fix VGA logdirty with altp2m (v11)   Razvan Cojocaru?
> dom0less (v4)Stefano Stabellini ?

Dom0less is already in. "Dom0less device assignment" missed the window
by only a couple of days (I forgot to send it in time -- too bad.)

I have another outstanding series for 4.12: "misc safety certification
fixes".


> Implement Set/Way operations (RFC)   Julien Grall   ?

Also already committed


> TEE mediator support in XEN (v2) Volodymyr Babchuk  ?
 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH 0/3] machine: Make compat_props arrays shorter and more readable

[Eduardo Habkost]

Current declarations of compat_props arrays are very verbose,
with each entry taking 4 lines of code.  By omitting the field
designators, we can make each array entry fit a single line of
code and be more readable.

Eduardo Habkost (3):
  spapr: Eliminate SPAPR_PCI_2_7_MMIO_WIN_SIZE macro
  machine: Eliminate unnecessary stringify() usage
  machine: Use shorter format for GlobalProperty arrays

 include/hw/i386/pc.h|  18 +-
 include/hw/pci-host/spapr.h |   1 -
 hw/core/machine.c   | 338 -
 hw/i386/pc.c| 720 +++-
 hw/i386/pc_piix.c   | 192 ++
 hw/ppc/spapr.c  |  72 +---
 hw/s390x/s390-virtio-ccw.c  |  75 +---
 hw/xen/xen-common.c |  18 +-
 8 files changed, 265 insertions(+), 1169 deletions(-)

-- 
2.18.0.rc1.1.g3f1ff2140


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] xen/build-id: Fix xen_build_id_check() to be robust against malformed notes

[Andrew Cooper]

On 07/01/2019 10:36, Jan Beulich wrote:
 On 31.12.18 at 18:34,  wrote:
>> A NT_GNU_BUILD_ID with namesz longer than 4 will cause the strncmp() to use
>> bytes in adjacent stringtable entries.
>>
>> Instead, check for namesz exactly equal to 4,
> Is that a requirement spelled out anywhere? Till now I've been
> under the impression that e.g. 8 bytes of name are fine as well,
> as long as the first four of them are "GNU\0".

No idea, but if this is true then we've got bigger problems with parsing
the notes.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v4 2/2] xen: use SYMBOL when required

[Stefano Stabellini]

On Mon, 7 Jan 2019, Jan Beulich wrote:
> >>> On 04.01.19 at 18:05,  wrote:
> > I realize that you are not convinced by these arguments, but let's find
> > a way forward. My preference would be to have SYMBOL returning unsigned
> > long and do unsigned long comparisons when pointers pointing to
> > different objects are involved.
> 
> I continue to fail to see how suitable hiding of the connection to the
> original symbol from the compiler makes code less standard compliant
> when comparing pointers: The compiler simply can't know whether
> the underlying object is (in the extreme case) an array spanning the
> entire address space.

That is because the requirement I am trying to address is MISRA-C
compliance, which in turns requires C language compliance for C language
(I think it allows mixing C with assembly code). I don't particularly
care whether the compiler can or cannot find the connection to the
original symbol. 

The important thing for me is to avoid comparisons (and subtractions)
between pointers pointing to different objects. If we compare unsigned
longs, it is easier to prove that the comparison is not between pointers
pointing to different objects, even if somehow the numeric values
indirectly come from pointers. If we compare pointers, even if they went
through some sort of assembly conversions, we are still comparing
pointers pointing to different objects. The compiler might not be able
to figure it out, but a MISRA-C compliance scanning tool, or a human,
might.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH for-4.12] xen/iommu: fix dev assignment on ARM after 91d4eca7

[Stefano Stabellini]

On Mon, 7 Jan 2019, Paul Durrant wrote:
> > -Original Message-
> > From: Stefano Stabellini [mailto:sstabell...@kernel.org]
> > Sent: 04 January 2019 17:46
> > To: Paul Durrant 
> > Cc: 'Stefano Stabellini' ; Andrew Cooper
> > ; xen-de...@lists.xen.org;
> > julien.gr...@arm.com; jbeul...@suse.com
> > Subject: RE: [Xen-devel] [PATCH for-4.12] xen/iommu: fix dev assignment on
> > ARM after 91d4eca7
> > 
> > On Fri, 4 Jan 2019, Paul Durrant wrote:
> > > > -Original Message-
> > > > From: Stefano Stabellini [mailto:sstabell...@kernel.org]
> > > > Sent: 03 January 2019 18:20
> > > > To: Andrew Cooper 
> > > > Cc: Stefano Stabellini ; xen-
> > de...@lists.xen.org;
> > > > julien.gr...@arm.com; jbeul...@suse.com; Paul Durrant
> > > > 
> > > > Subject: Re: [Xen-devel] [PATCH for-4.12] xen/iommu: fix dev
> > assignment on
> > > > ARM after 91d4eca7
> > > >
> > > > On Thu, 3 Jan 2019, Andrew Cooper wrote:
> > > > > On 03/01/2019 00:28, Stefano Stabellini wrote:
> > > > > > Fix device assignment on ARM after 91d4eca7 "mm / iommu: split
> > > > > > need_iommu() into has_iommu_pt() and need_iommu_pt_sync()".
> > > > > >
> > > > > > arch_iommu_populate_page_table returns -ENOSYS which causes
> > > > > > iommu_construct to return early, although it is not an error.
> > > > > >
> > > > > > Interestingly, the if ( rc ) was present even before 91d4eca7, but
> > it
> > > > was
> > > > > > still working before. Now, with the new hd->status field it won't
> > > > > > complete the initialization successfully.
> > > > > >
> > > > > > Signed-off-by: Stefano Stabellini 
> > > > > >
> > > > > > diff --git a/xen/drivers/passthrough/iommu.c
> > > > b/xen/drivers/passthrough/iommu.c
> > > > > > index ac62d7f..a63329b 100644
> > > > > > --- a/xen/drivers/passthrough/iommu.c
> > > > > > +++ b/xen/drivers/passthrough/iommu.c
> > > > > > @@ -269,7 +269,7 @@ int iommu_construct(struct domain *d)
> > > > > >  hd->need_sync = true;
> > > > > >
> > > > > >  rc = arch_iommu_populate_page_table(d);
> > > > >
> > > > > The comment in ARM's arch_iommu_populate_page_table() says
> > > > >
> > > > > /* The IOMMU shares the p2m with the CPU */
> > > > >
> > > > > Which means that iommu_use_hap_pt() (just out of context above this
> > > > > hunk) is wrong.  It should return true, which will prevent us
> > entering
> > > > > this path during initialisation.
> > > >
> > > > iommu_use_hap_pt is implemented by calling has_iommu_pt(d) (also on
> > x86
> > > > is part of the implementation), which is implemented as:
> > > >
> > > >   (dom_iommu(d)->status != IOMMU_STATUS_disabled)
> > > >
> > > > IOMMU_STATUS_disabled is zero in the enum, so status starts as
> > > > IOMMU_STATUS_disabled. It is set to IOMMU_STATUS_initializing for dom0
> > > > in iommu_hwdom_init, but it is not set to IOMMU_STATUS_initializing
> > for
> > > > other domains anywhere, leading to this error.
> > >
> > > It is set for other domains... see iommu_construct().
> > 
> > Hi Paul, unfortunately it doesn't work that way. Let me explain:
> > 
> > 
> > iommu_construct() sets hd->status to IOMMU_STATUS_initializing *after*
> > calling iommu_use_hap_pt(d), and specifically inside the if statement:
> > 
> > if ( !iommu_use_hap_pt(d) )
> > {
> > int rc;
> > 
> > hd->status = IOMMU_STATUS_initializing;
> > hd->need_sync = true;
> > 
> > rc = arch_iommu_populate_page_table(d);
> > if ( rc )
> > {
> > if ( rc != -ERESTART )
> > {
> > hd->need_sync = false;
> > hd->status = IOMMU_STATUS_disabled;
> > }
> > 
> > return rc;
> > }
> > }
> > 
> > However, for iommu_use_hap_pt(d) to return the correct value, which
> > should be always true on ARM, status needs to be already set to
> > IOMMU_STATUS_initializing.
> > 
> > Because when we enter iommu_construct status is IOMMU_STATUS_disabled,
> > iommu_use_hap_pt(d) calls has_iommu_pt(d) which wrongly returns false
> > because it is implemented as:
> > 
> > #define has_iommu_pt(d) (dom_iommu(d)->status != IOMMU_STATUS_disabled)
> > 
> > 
> > I think we need to move the initialization of status to
> > IOMMU_STATUS_initializing earlier, specifically to iommu_domain_init.
> 
> The use of iommu_use_hap_pt() here is indeed a problem, but I think it would 
> be sufficient to move the line "hd->status = IOMMU_STATUS_initializing" to 
> just before the if rather than to a completely separate function.

Yes, that works too.
 
---
xen/iommu: fix dev assignment on ARM after 91d4eca7

Fix device assignment on ARM after 91d4eca7 "mm / iommu: split
need_iommu() into has_iommu_pt() and need_iommu_pt_sync()".

arch_iommu_populate_page_table returns -ENOSYS which causes
iommu_construct to return early, although it is not an error.

hd->status needs to be set to IOMMU_STATUS_initializing before calling
iommu_use_hap_pt, otherwise iommu_use_hap_pt will return the wrong
value.

Signed-off-by: 

[Xen-devel] [PATCH 2/3] machine: Eliminate unnecessary stringify() usage

[Eduardo Habkost]

stringify() is useful when we need to use macros in compat_props
(like when we set virtio-baloon-pci.class=PCI_CLASS_MEMORY_RAM at
pc_i440fx_1_0_machine_options()), but it is pointless when we are
already providing a number literal.

Replace stringify() with string literals when appropriate.

Signed-off-by: Eduardo Habkost 
---
 hw/core/machine.c |  8 ++--
 hw/i386/pc.c  | 94 +++
 hw/i386/pc_piix.c | 30 +++
 hw/ppc/spapr.c|  2 +-
 4 files changed, 67 insertions(+), 67 deletions(-)

diff --git a/hw/core/machine.c b/hw/core/machine.c
index f8563efb86..4b4d6c23de 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -135,11 +135,11 @@ GlobalProperty hw_compat_2_8[] = {
 {
 .driver   = "fw_cfg_mem",
 .property = "x-file-slots",
-.value= stringify(0x10),
+.value= "0x10",
 },{
 .driver   = "fw_cfg_io",
 .property = "x-file-slots",
-.value= stringify(0x10),
+.value= "0x10",
 },{
 .driver   = "pflash_cfi01",
 .property = "old-multiple-chip-handling",
@@ -337,11 +337,11 @@ GlobalProperty hw_compat_2_1[] = {
 },{
 .driver   = "usb-mouse",
 .property = "usb_version",
-.value= stringify(1),
+.value= "1",
 },{
 .driver   = "usb-kbd",
 .property = "usb_version",
-.value= stringify(1),
+.value= "1",
 },{
 .driver   = "virtio-pci",
 .property = "virtio-pci-bus-master-bug-migration",
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 4952feb476..ff14b6d4df 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -148,11 +148,11 @@ GlobalProperty pc_compat_2_12[] = {
 },{
 .driver   = "EPYC-" TYPE_X86_CPU,
 .property = "xlevel",
-.value= stringify(0x800a),
+.value= "0x800a",
 },{
 .driver   = "EPYC-IBPB-" TYPE_X86_CPU,
 .property = "xlevel",
-.value= stringify(0x800a),
+.value= "0x800a",
 },
 };
 const size_t pc_compat_2_12_len = G_N_ELEMENTS(pc_compat_2_12);
@@ -191,7 +191,7 @@ GlobalProperty pc_compat_2_9[] = {
 {
 .driver   = "mch",
 .property = "extended-tseg-mbytes",
-.value= stringify(0),
+.value= "0",
 },
 };
 const size_t pc_compat_2_9_len = G_N_ELEMENTS(pc_compat_2_9);
@@ -365,75 +365,75 @@ GlobalProperty pc_compat_2_3[] = {
 },{
 .driver   = "qemu64" "-" TYPE_X86_CPU,
 .property = "min-level",
-.value= stringify(4),
+.value= "4",
 },{
 .driver   = "kvm64" "-" TYPE_X86_CPU,
 .property = "min-level",
-.value= stringify(5),
+.value= "5",
 },{
 .driver   = "pentium3" "-" TYPE_X86_CPU,
 .property = "min-level",
-.value= stringify(2),
+.value= "2",
 },{
 .driver   = "n270" "-" TYPE_X86_CPU,
 .property = "min-level",
-.value= stringify(5),
+.value= "5",
 },{
 .driver   = "Conroe" "-" TYPE_X86_CPU,
 .property = "min-level",
-.value= stringify(4),
+.value= "4",
 },{
 .driver   = "Penryn" "-" TYPE_X86_CPU,
 .property = "min-level",
-.value= stringify(4),
+.value= "4",
 },{
 .driver   = "Nehalem" "-" TYPE_X86_CPU,
 .property = "min-level",
-.value= stringify(4),
+.value= "4",
 },{
 .driver   = "n270" "-" TYPE_X86_CPU,
 .property = "min-xlevel",
-.value= stringify(0x800a),
+.value= "0x800a",
 },{
 .driver   = "Penryn" "-" TYPE_X86_CPU,
 .property = "min-xlevel",
-.value= stringify(0x800a),
+.value= "0x800a",
 },{
 .driver   = "Conroe" "-" TYPE_X86_CPU,
 .property = "min-xlevel",
-.value= stringify(0x800a),
+.value= "0x800a",
 },{
 .driver   = "Nehalem" "-" TYPE_X86_CPU,
 .property = "min-xlevel",
-.value= stringify(0x800a),
+.value= "0x800a",
 },{
 .driver   = "Westmere" "-" TYPE_X86_CPU,
 .property = "min-xlevel",
-.value= stringify(0x800a),
+.value= "0x800a",
 },{
 .driver   = "SandyBridge" "-" TYPE_X86_CPU,
 .property = "min-xlevel",
-.value= stringify(0x800a),
+.value= "0x800a",
 },{
 .driver   = "IvyBridge" "-" TYPE_X86_CPU,
 .property = "min-xlevel",
-.value= stringify(0x800a),
+.value= "0x800a",
 },{
 .driver   = "Haswell" "-" TYPE_X86_CPU,
 .property = "min-xlevel",
-.value= stringify(0x800a),
+.value= "0x800a",
 },{
 .driver   = "Haswell-noTSX" "-" TYPE_X86_CPU,
 

[Xen-devel] [PATCH 1/3] spapr: Eliminate SPAPR_PCI_2_7_MMIO_WIN_SIZE macro

[Eduardo Habkost]

The macro is only used in one place, where the purpose of the
value is obvious.  Eliminate the macro so we don't need to rely
on stringify().

Signed-off-by: Eduardo Habkost 
---
 include/hw/pci-host/spapr.h | 1 -
 hw/ppc/spapr.c  | 2 +-
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/include/hw/pci-host/spapr.h b/include/hw/pci-host/spapr.h
index 7c66c3872f..a85a995b6c 100644
--- a/include/hw/pci-host/spapr.h
+++ b/include/hw/pci-host/spapr.h
@@ -99,7 +99,6 @@ struct sPAPRPHBState {
 #define SPAPR_PCI_BASE   (1ULL << 45) /* 32 TiB */
 #define SPAPR_PCI_LIMIT  (1ULL << 46) /* 64 TiB */
 
-#define SPAPR_PCI_2_7_MMIO_WIN_SIZE  0xf8000
 #define SPAPR_PCI_IO_WIN_SIZE0x1
 
 #define SPAPR_PCI_MSI_WINDOW 0x400ULL
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 5671608cea..bff42f0adb 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -4225,7 +4225,7 @@ static void spapr_machine_2_7_class_options(MachineClass 
*mc)
 {
 .driver   = TYPE_SPAPR_PCI_HOST_BRIDGE,
 .property = "mem_win_size",
-.value= stringify(SPAPR_PCI_2_7_MMIO_WIN_SIZE),
+.value= "0xf8000",
 },
 {
 .driver   = TYPE_SPAPR_PCI_HOST_BRIDGE,
-- 
2.18.0.rc1.1.g3f1ff2140


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [ovmf test] 131785: regressions - FAIL

[osstest service owner]

flight 131785 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131785/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i3866 xen-buildfail REGR. vs. 129475
 build-i386-xsm6 xen-buildfail REGR. vs. 129475
 build-amd64-xsm   6 xen-buildfail REGR. vs. 129475
 build-amd64   6 xen-buildfail REGR. vs. 129475

Tests which did not succeed, but are not blocking:
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a

version targeted for testing:
 ovmf 46f4c9677c615d862649459392f8f55b3e6567c2
baseline version:
 ovmf 5ae3184d8c59f7bbb84bad482df6b8020ba58188

Last test of basis   129475  2018-11-05 21:13:11 Z   62 days
Failing since129526  2018-11-06 20:49:26 Z   61 days  250 attempts
Testing same since   131751  2019-01-05 09:12:54 Z2 days   14 attempts


People who touched revisions under test:
  Achin Gupta 
  Alex James 
  Ard Biesheuvel 
  Ashish Singhal 
  Bob Feng 
  bob.c.f...@intel.com 
  BobCF 
  Chasel Chiu 
  Chasel, Chiu 
  Chen A Chen 
  Dandan Bi 
  David Wei 
  Derek Lin 
  Eric Dong 
  Feng, Bob C 
  Fu Siyuan 
  Gary Lin 
  Hao Wu 
  Jaben Carsey 
  Jagadeesh Ujja 
  Jeff Brasen 
  Jian J Wang 
  Jiaxin Wu 
  Jiewen Yao 
  Laszlo Ersek 
  Leif Lindholm 
  Liming Gao 
  Liu Yu 
  Marc Zyngier 
  Marcin Wojtas 
  Mike Maslenkin 
  Ming Huang 
  Pedroa Liu 
  Ruiyu Ni 
  Sami Mujawar 
  shenglei 
  Shenglei Zhang 
  Siyuan Fu 
  Star Zeng 
  Sughosh Ganu 
  Sumit Garg 
  Sun, Zailiang 
  Thomas Abraham 
  Thomas Rydman 
  Ting Ye 
  Tomasz Michalec 
  Vijayenthiran Subramaniam 
  Vladimir Olovyannikov 
  Wang BinX A 
  Wu Jiaxin 
  Ye Ting 
  Yonghong Zhu 
  yuchenlin 
  Zailiang Sun 
  Zhang, Chao B 
  Zhao, ZhiqiangX 
  Zhiju.Fan 
  zhijufan 
  ZhiqiangX Zhao 
  zwei4 

jobs:
 build-amd64-xsm  fail
 build-i386-xsm   fail
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 4888 lines long.)

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH 3/3] machine: Use shorter format for GlobalProperty arrays

[Eduardo Habkost]

Instead of verbose arrays with 4 lines for each entry, make each
entry take only one line.  This makes long arrays that couldn't
fit in the screen become short and readable.

Signed-off-by: Eduardo Habkost 
---
 include/hw/i386/pc.h   |  18 +-
 hw/core/machine.c  | 338 -
 hw/i386/pc.c   | 720 +++--
 hw/i386/pc_piix.c  | 192 ++
 hw/ppc/spapr.c |  72 +---
 hw/s390x/s390-virtio-ccw.c |  75 +---
 hw/xen/xen-common.c|  18 +-
 7 files changed, 265 insertions(+), 1168 deletions(-)

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 84720bede9..0abbe45637 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -354,21 +354,9 @@ extern const size_t pc_compat_1_4_len;
  * depending on QEMU versions up to QEMU 2.4.
  */
 #define PC_CPU_MODEL_IDS(v) \
-{\
-.driver   = "qemu32-" TYPE_X86_CPU,\
-.property = "model-id",\
-.value= "QEMU Virtual CPU version " v,\
-},\
-{\
-.driver   = "qemu64-" TYPE_X86_CPU,\
-.property = "model-id",\
-.value= "QEMU Virtual CPU version " v,\
-},\
-{\
-.driver   = "athlon-" TYPE_X86_CPU,\
-.property = "model-id",\
-.value= "QEMU Virtual CPU version " v,\
-},
+{ "qemu32-" TYPE_X86_CPU, "model-id", "QEMU Virtual CPU version " v, },\
+{ "qemu64-" TYPE_X86_CPU, "model-id", "QEMU Virtual CPU version " v, },\
+{ "athlon-" TYPE_X86_CPU, "model-id", "QEMU Virtual CPU version " v, },
 
 #define DEFINE_PC_MACHINE(suffix, namestr, initfn, optsfn) \
 static void pc_machine_##suffix##_class_init(ObjectClass *oc, void *data) \
diff --git a/hw/core/machine.c b/hw/core/machine.c
index 4b4d6c23de..5530b71981 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -24,23 +24,10 @@
 #include "hw/pci/pci.h"
 
 GlobalProperty hw_compat_3_1[] = {
-{
-.driver   = "pcie-root-port",
-.property = "x-speed",
-.value= "2_5",
-},{
-.driver   = "pcie-root-port",
-.property = "x-width",
-.value= "1",
-},{
-.driver   = "memory-backend-file",
-.property = "x-use-canonical-path-for-ramblock-id",
-.value= "true",
-},{
-.driver   = "memory-backend-memfd",
-.property = "x-use-canonical-path-for-ramblock-id",
-.value= "true",
-},
+{ "pcie-root-port", "x-speed", "2_5" },
+{ "pcie-root-port", "x-width", "1" },
+{ "memory-backend-file", "x-use-canonical-path-for-ramblock-id", "true" },
+{ "memory-backend-memfd", "x-use-canonical-path-for-ramblock-id", "true" },
 };
 const size_t hw_compat_3_1_len = G_N_ELEMENTS(hw_compat_3_1);
 
@@ -48,269 +35,96 @@ GlobalProperty hw_compat_3_0[] = {};
 const size_t hw_compat_3_0_len = G_N_ELEMENTS(hw_compat_3_0);
 
 GlobalProperty hw_compat_2_12[] = {
-{
-.driver   = "migration",
-.property = "decompress-error-check",
-.value= "off",
-},{
-.driver   = "hda-audio",
-.property = "use-timer",
-.value= "false",
-},{
-.driver   = "cirrus-vga",
-.property = "global-vmstate",
-.value= "true",
-},{
-.driver   = "VGA",
-.property = "global-vmstate",
-.value= "true",
-},{
-.driver   = "vmware-svga",
-.property = "global-vmstate",
-.value= "true",
-},{
-.driver   = "qxl-vga",
-.property = "global-vmstate",
-.value= "true",
-},
+{ "migration", "decompress-error-check", "off" },
+{ "hda-audio", "use-timer", "false" },
+{ "cirrus-vga", "global-vmstate", "true" },
+{ "VGA", "global-vmstate", "true" },
+{ "vmware-svga", "global-vmstate", "true" },
+{ "qxl-vga", "global-vmstate", "true" },
 };
 const size_t hw_compat_2_12_len = G_N_ELEMENTS(hw_compat_2_12);
 
 GlobalProperty hw_compat_2_11[] = {
-{
-.driver   = "hpet",
-.property = "hpet-offset-saved",
-.value= "false",
-},{
-.driver   = "virtio-blk-pci",
-.property = "vectors",
-.value= "2",
-},{
-.driver   = "vhost-user-blk-pci",
-.property = "vectors",
-.value= "2",
-},{
-.driver   = "e1000",
-.property = "migrate_tso_props",
-.value= "off",
-},
+{ "hpet", "hpet-offset-saved", "false" },
+{ "virtio-blk-pci", "vectors", "2" },
+{ "vhost-user-blk-pci", "vectors", "2" },
+{ "e1000", "migrate_tso_props", "off" },
 };
 const size_t hw_compat_2_11_len = G_N_ELEMENTS(hw_compat_2_11);
 
 GlobalProperty hw_compat_2_10[] = {
-{
-.driver   = "virtio-mouse-device",
-.property = "wheel-axis",
-.value= "false",
-},{
-.driver   = "virtio-tablet-device",
-.property = "wheel-axis",
-.value= "false",
-},
+{ "virtio-mouse-device", "wheel-axis", "false" 

Re: [Xen-devel] [Qemu-devel] [PATCH 3/3] machine: Use shorter format for GlobalProperty arrays

[Marc-André Lureau]

On Mon, Jan 7, 2019 at 11:33 PM Eduardo Habkost  wrote:
>
> Instead of verbose arrays with 4 lines for each entry, make each
> entry take only one line.  This makes long arrays that couldn't
> fit in the screen become short and readable.
>
> Signed-off-by: Eduardo Habkost 
> ---
>  include/hw/i386/pc.h   |  18 +-
>  hw/core/machine.c  | 338 -
>  hw/i386/pc.c   | 720 +++--
>  hw/i386/pc_piix.c  | 192 ++
>  hw/ppc/spapr.c |  72 +---
>  hw/s390x/s390-virtio-ccw.c |  75 +---
>  hw/xen/xen-common.c|  18 +-
>  7 files changed, 265 insertions(+), 1168 deletions(-)

Nice diff state, hopefully I didn't miss any before/after difference:
Reviewed-by: Marc-André Lureau 

>
> diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
> index 84720bede9..0abbe45637 100644
> --- a/include/hw/i386/pc.h
> +++ b/include/hw/i386/pc.h
> @@ -354,21 +354,9 @@ extern const size_t pc_compat_1_4_len;
>   * depending on QEMU versions up to QEMU 2.4.
>   */
>  #define PC_CPU_MODEL_IDS(v) \
> -{\
> -.driver   = "qemu32-" TYPE_X86_CPU,\
> -.property = "model-id",\
> -.value= "QEMU Virtual CPU version " v,\
> -},\
> -{\
> -.driver   = "qemu64-" TYPE_X86_CPU,\
> -.property = "model-id",\
> -.value= "QEMU Virtual CPU version " v,\
> -},\
> -{\
> -.driver   = "athlon-" TYPE_X86_CPU,\
> -.property = "model-id",\
> -.value= "QEMU Virtual CPU version " v,\
> -},
> +{ "qemu32-" TYPE_X86_CPU, "model-id", "QEMU Virtual CPU version " v, },\
> +{ "qemu64-" TYPE_X86_CPU, "model-id", "QEMU Virtual CPU version " v, },\
> +{ "athlon-" TYPE_X86_CPU, "model-id", "QEMU Virtual CPU version " v, },
>
>  #define DEFINE_PC_MACHINE(suffix, namestr, initfn, optsfn) \
>  static void pc_machine_##suffix##_class_init(ObjectClass *oc, void 
> *data) \
> diff --git a/hw/core/machine.c b/hw/core/machine.c
> index 4b4d6c23de..5530b71981 100644
> --- a/hw/core/machine.c
> +++ b/hw/core/machine.c
> @@ -24,23 +24,10 @@
>  #include "hw/pci/pci.h"
>
>  GlobalProperty hw_compat_3_1[] = {
> -{
> -.driver   = "pcie-root-port",
> -.property = "x-speed",
> -.value= "2_5",
> -},{
> -.driver   = "pcie-root-port",
> -.property = "x-width",
> -.value= "1",
> -},{
> -.driver   = "memory-backend-file",
> -.property = "x-use-canonical-path-for-ramblock-id",
> -.value= "true",
> -},{
> -.driver   = "memory-backend-memfd",
> -.property = "x-use-canonical-path-for-ramblock-id",
> -.value= "true",
> -},
> +{ "pcie-root-port", "x-speed", "2_5" },
> +{ "pcie-root-port", "x-width", "1" },
> +{ "memory-backend-file", "x-use-canonical-path-for-ramblock-id", "true" 
> },
> +{ "memory-backend-memfd", "x-use-canonical-path-for-ramblock-id", "true" 
> },
>  };
>  const size_t hw_compat_3_1_len = G_N_ELEMENTS(hw_compat_3_1);
>
> @@ -48,269 +35,96 @@ GlobalProperty hw_compat_3_0[] = {};
>  const size_t hw_compat_3_0_len = G_N_ELEMENTS(hw_compat_3_0);
>
>  GlobalProperty hw_compat_2_12[] = {
> -{
> -.driver   = "migration",
> -.property = "decompress-error-check",
> -.value= "off",
> -},{
> -.driver   = "hda-audio",
> -.property = "use-timer",
> -.value= "false",
> -},{
> -.driver   = "cirrus-vga",
> -.property = "global-vmstate",
> -.value= "true",
> -},{
> -.driver   = "VGA",
> -.property = "global-vmstate",
> -.value= "true",
> -},{
> -.driver   = "vmware-svga",
> -.property = "global-vmstate",
> -.value= "true",
> -},{
> -.driver   = "qxl-vga",
> -.property = "global-vmstate",
> -.value= "true",
> -},
> +{ "migration", "decompress-error-check", "off" },
> +{ "hda-audio", "use-timer", "false" },
> +{ "cirrus-vga", "global-vmstate", "true" },
> +{ "VGA", "global-vmstate", "true" },
> +{ "vmware-svga", "global-vmstate", "true" },
> +{ "qxl-vga", "global-vmstate", "true" },
>  };
>  const size_t hw_compat_2_12_len = G_N_ELEMENTS(hw_compat_2_12);
>
>  GlobalProperty hw_compat_2_11[] = {
> -{
> -.driver   = "hpet",
> -.property = "hpet-offset-saved",
> -.value= "false",
> -},{
> -.driver   = "virtio-blk-pci",
> -.property = "vectors",
> -.value= "2",
> -},{
> -.driver   = "vhost-user-blk-pci",
> -.property = "vectors",
> -.value= "2",
> -},{
> -.driver   = "e1000",
> -.property = "migrate_tso_props",
> -.value= "off",
> -},
> +{ "hpet", "hpet-offset-saved", "false" },
> +{ "virtio-blk-pci", "vectors", "2" },
> +{ "vhost-user-blk-pci", "vectors", "2" },
> +{ "e1000", 

Re: [Xen-devel] [PATCH v5 2/4] xen/arm: use SYMBOL when required

[Stefano Stabellini]

On Mon, 7 Jan 2019, Jan Beulich wrote:
> >>> On 03.01.19 at 20:19,  wrote:
> > Use SYMBOL in cases of comparisons and subtractions of:
> > 
> > _start, _end, __init_begin, __init_end,  __2M_text_end,
> > __2M_rodata_start, __2M_rodata_end, __2M_init_start,__2M_init_end,
> > __2M_rwdata_start, __2M_rwdata_end, _stext, _etext, _srodata, _erodata,
> > __end_vpci_array, __start_vpci_array, _sinittext, _einittext,
> > _stextentry, _etextentry, __start_bug_frames, __stop_bug_frames_0,
> > __stop_bug_frames_1, __stop_bug_frames_2,__stop_bug_frames_3,
> > __note_gnu_build_id_start, __note_gnu_build_id_end, __start___ex_table,
> > __stop___ex_table, __start___pre_ex_table, __stop___pre_ex_table,
> > __lock_profile_start, __lock_profile_end, __param_start,
> > __param_end, __setup_start, __setup_end, __initcall_start,
> > __initcall_end, __presmp_initcall_end, __trampoline_rel_start,
> > __trampoline_rel_stop, __trampoline_seg_start, __trampoline_seg_stop
> > __alt_instructions, __alt_instructions_end, __ctors_start, __ctors_end,
> > __end_schedulers_array, __start_schedulers_array, __bss_start,
> > __bss_end, __per_cpu_start, __per_cpu_data_end, _splatform, _eplatform,
> > _sdevice, _edevice, _asdevice, _aedevice, __proc_info_start,
> > __proc_info_end, _sdtb
> 
> Didn't you go a little too far with copy-and-paste here? I don't think
> all of the symbols really exist in Arm (and similarly in the x86 instance
> I think there are some Arm-only symbols).

Ops, you are right, I'll filter the list in each commit message to only
the symbols that make sense.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH] arch/arm/xen: Remove duplicate header

[Souptick Joarder]

Remove duplicate header which is included twice.

Signed-off-by: Souptick Joarder 
---
 arch/arm/xen/mm.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index cb44aa2..e1d44b9 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -7,7 +7,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v5 4/4] xen/common: use SYMBOL when required

[Stefano Stabellini]

On Mon, 7 Jan 2019, Jan Beulich wrote:
> >>> On 03.01.19 at 20:19,  wrote:
> > --- a/xen/common/kernel.c
> > +++ b/xen/common/kernel.c
> > @@ -312,14 +312,18 @@ extern const initcall_t __initcall_start[], 
> > __presmp_initcall_end[],
> >  void __init do_presmp_initcalls(void)
> >  {
> >  const initcall_t *call;
> > -for ( call = __initcall_start; call < __presmp_initcall_end; call++ )
> > +for ( call = __initcall_start;
> > + (unsigned long)call < SYMBOL(__presmp_initcall_end);
> > + call++ )
> 
> Hard tabs here and ...

I'll fix


> >  (*call)();
> >  }
> >  
> >  void __init do_initcalls(void)
> >  {
> >  const initcall_t *call;
> > -for ( call = __presmp_initcall_end; call < __initcall_end; call++ )
> > +for ( call = __presmp_initcall_end;
> > + (unsigned long)call < SYMBOL(__initcall_end);
> > + call++ )
> 
> ... here.

I'll fix


> > --- a/xen/common/lib.c
> > +++ b/xen/common/lib.c
> > @@ -497,7 +497,7 @@ extern const ctor_func_t __ctors_start[], __ctors_end[];
> >  void __init init_constructors(void)
> >  {
> >  const ctor_func_t *f;
> > -for ( f = __ctors_start; f < __ctors_end; ++f )
> > +for ( f = __ctors_start; (unsigned long)f < SYMBOL(__ctors_end); ++f )
> >  (*f)();
> 
> One of the best examples where SYMBOL() retaining the original type
> would help.

Yes, depending on the result of the discussion on the topic, I'll either
keep it as is, or change all these instances.


> Also please take the opportunity and add the missing blank line.

You mean before the `for', right? I'll add.


> > --- a/xen/common/schedule.c
> > +++ b/xen/common/schedule.c
> > @@ -68,7 +68,7 @@ DEFINE_PER_CPU(struct scheduler *, scheduler);
> >  DEFINE_PER_CPU(cpumask_t, cpumask_scratch);
> >  
> >  extern const struct scheduler *__start_schedulers_array[], 
> > *__end_schedulers_array[];
> > -#define NUM_SCHEDULERS (__end_schedulers_array - __start_schedulers_array)
> > +#define NUM_SCHEDULERS (SYMBOL(__end_schedulers_array) - 
> > SYMBOL(__start_schedulers_array))
> 
> Long line.

I'll fix.


> > --- a/xen/common/spinlock.c
> > +++ b/xen/common/spinlock.c
> > @@ -474,7 +474,9 @@ static int __init lock_prof_init(void)
> >  {
> >  struct lock_profile **q;
> >  
> > -for ( q = &__lock_profile_start; q < &__lock_profile_end; q++ )
> > +for ( q = &__lock_profile_start;
> > + (unsigned long)q < SYMBOL(&__lock_profile_end);
> > + q++ )
> 
> Hard tabs again.

I'll fix


> > --- a/xen/common/virtual_region.c
> > +++ b/xen/common/virtual_region.c
> > @@ -119,7 +119,11 @@ void __init setup_virtual_regions(const struct 
> > exception_table_entry *start,
> >  const struct bug_frame *s;
> >  
> >  s = bug_frames[i - 1];
> > -sz = bug_frames[i] - s;
> > +/*
> > + * Cast to unsigned long to calculate the size to avoid
> > + * subtractions between pointers pointing to different objects.
> > + */
> > +sz = (unsigned long)bug_frames[i] - (unsigned long)s;
> 
> Perhaps better to use SYMBOL() in the definition of bug_frames[]?

That was my initial thought, but then bug_frames cannot be const and
cannot be statically initialized. So the code would become something
like this:

void __init setup_virtual_regions(const struct exception_table_entry *start,
  const struct exception_table_entry *end)
{
size_t sz;
unsigned int i = 0;
static unsigned long bug_frames[6];
bug_frames[i++] = SYMBOL(__start_bug_frames);
bug_frames[i++] = SYMBOL(__stop_bug_frames_0),
bug_frames[i++] = SYMBOL(__stop_bug_frames_1),
bug_frames[i++] = SYMBOL(__stop_bug_frames_2),
#ifdef CONFIG_X86
bug_frames[i++] = SYMBOL(__stop_bug_frames_3),
#endif
bug_frames[i++] = 0;

for ( i = 1; bug_frames[i]; i++ )
{
unsigned long s;

s = bug_frames[i - 1];
/*
 * Cast to unsigned long to calculate the size to avoid
 * subtractions between pointers pointing to different objects.
 */
sz = bug_frames[i] - s;

core.frame[i - 1].n_bugs = sz;
core.frame[i - 1].bugs = (const struct bug_frame *)s;

core_init.frame[i - 1].n_bugs = sz;
core_init.frame[i - 1].bugs = (const struct bug_frame *)s;
}

What do you think?





> > --- a/xen/include/xen/kernel.h
> > +++ b/xen/include/xen/kernel.h
> > @@ -66,27 +66,27 @@
> >  })
> >  
> >  extern char _start[], _end[], start[];
> > -#define is_kernel(p) ({ \
> > -char *__p = (char *)(unsigned long)(p); \
> > -(__p >= _start) && (__p < _end);\
> > +#define is_kernel(p) ({ \
> > +const unsigned long __p = (unsigned long)(p);   \
> > +(__p >= SYMBOL(_start)) && (__p < SYMBOL(_end));\
> >  })
> >  
> >  extern char _stext[], _etext[];
> > -#define is_kernel_text(p) ({  

Re: [Xen-devel] [Qemu-devel] [PATCH 1/3] spapr: Eliminate SPAPR_PCI_2_7_MMIO_WIN_SIZE macro

[Marc-André Lureau]

On Mon, Jan 7, 2019 at 11:34 PM Eduardo Habkost  wrote:
>
> The macro is only used in one place, where the purpose of the
> value is obvious.  Eliminate the macro so we don't need to rely
> on stringify().
>
> Signed-off-by: Eduardo Habkost 

Reviewed-by: Marc-André Lureau 

> ---
>  include/hw/pci-host/spapr.h | 1 -
>  hw/ppc/spapr.c  | 2 +-
>  2 files changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/include/hw/pci-host/spapr.h b/include/hw/pci-host/spapr.h
> index 7c66c3872f..a85a995b6c 100644
> --- a/include/hw/pci-host/spapr.h
> +++ b/include/hw/pci-host/spapr.h
> @@ -99,7 +99,6 @@ struct sPAPRPHBState {
>  #define SPAPR_PCI_BASE   (1ULL << 45) /* 32 TiB */
>  #define SPAPR_PCI_LIMIT  (1ULL << 46) /* 64 TiB */
>
> -#define SPAPR_PCI_2_7_MMIO_WIN_SIZE  0xf8000
>  #define SPAPR_PCI_IO_WIN_SIZE0x1
>
>  #define SPAPR_PCI_MSI_WINDOW 0x400ULL
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index 5671608cea..bff42f0adb 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -4225,7 +4225,7 @@ static void 
> spapr_machine_2_7_class_options(MachineClass *mc)
>  {
>  .driver   = TYPE_SPAPR_PCI_HOST_BRIDGE,
>  .property = "mem_win_size",
> -.value= stringify(SPAPR_PCI_2_7_MMIO_WIN_SIZE),
> +.value= "0xf8000",
>  },
>  {
>  .driver   = TYPE_SPAPR_PCI_HOST_BRIDGE,
> --
> 2.18.0.rc1.1.g3f1ff2140
>
>


-- 
Marc-André Lureau

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [linux-4.19 test] 131775: regressions - trouble: broken/fail/pass

[osstest service owner]

flight 131775 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131775/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt-pair broken
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm   broken
 test-amd64-amd64-amd64-pvgrub broken
 test-amd64-amd64-xl-shadow7 xen-boot fail REGR. vs. 129313
 test-amd64-amd64-i386-pvgrub  7 xen-boot fail REGR. vs. 129313
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR. 
vs. 129313
 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 129313
 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 129313
 test-amd64-i386-xl-qemuu-debianhvm-amd64  7 xen-boot fail REGR. vs. 129313
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  7 xen-boot fail REGR. vs. 129313
 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 129313
 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 129313
 test-amd64-amd64-pair10 xen-boot/src_hostfail REGR. vs. 129313
 test-amd64-amd64-pair11 xen-boot/dst_hostfail REGR. vs. 129313
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 129313
 test-amd64-i386-examine   8 reboot   fail REGR. vs. 129313
 test-amd64-i386-qemut-rhel6hvm-intel  7 xen-boot fail REGR. vs. 129313
 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 129313
 test-amd64-amd64-examine  8 reboot   fail REGR. vs. 129313
 test-amd64-amd64-amd64-pvgrub  7 xen-boot  fail in 131642 REGR. vs. 129313
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail in 
131642 REGR. vs. 129313
 test-amd64-amd64-libvirt-pair 10 xen-boot/src_host fail in 131642 REGR. vs. 
129313
 test-amd64-amd64-libvirt-pair 11 xen-boot/dst_host fail in 131642 REGR. vs. 
129313
 test-amd64-i386-qemut-rhel6hvm-amd 13 guest-start.2 fail in 131739 REGR. vs. 
129313

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 4 host-install(4) broken 
pass in 131757
 test-amd64-amd64-libvirt-pair 4 host-install/src_host(4) broken pass in 131757
 test-amd64-amd64-amd64-pvgrub  4 host-install(4) broken pass in 131757
 test-amd64-amd64-rumprun-amd64 17 rumprun-demo-xenstorels/xenstorels.repeat 
fail in 131642 pass in 131775
 test-amd64-amd64-xl-qcow2 19 guest-start/debian.repeat fail in 131739 pass in 
131775
 test-amd64-i386-xl7 xen-boot   fail pass in 131642
 test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail pass in 
131739

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  7 xen-boot   fail never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop  

Re: [Xen-devel] [PATCH 1/3] spapr: Eliminate SPAPR_PCI_2_7_MMIO_WIN_SIZE macro

[David Gibson]

On Mon, Jan 07, 2019 at 05:30:18PM -0200, Eduardo Habkost wrote:
> The macro is only used in one place, where the purpose of the
> value is obvious.  Eliminate the macro so we don't need to rely
> on stringify().
> 
> Signed-off-by: Eduardo Habkost 

Acked-by: David Gibson 

> ---
>  include/hw/pci-host/spapr.h | 1 -
>  hw/ppc/spapr.c  | 2 +-
>  2 files changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/include/hw/pci-host/spapr.h b/include/hw/pci-host/spapr.h
> index 7c66c3872f..a85a995b6c 100644
> --- a/include/hw/pci-host/spapr.h
> +++ b/include/hw/pci-host/spapr.h
> @@ -99,7 +99,6 @@ struct sPAPRPHBState {
>  #define SPAPR_PCI_BASE   (1ULL << 45) /* 32 TiB */
>  #define SPAPR_PCI_LIMIT  (1ULL << 46) /* 64 TiB */
>  
> -#define SPAPR_PCI_2_7_MMIO_WIN_SIZE  0xf8000
>  #define SPAPR_PCI_IO_WIN_SIZE0x1
>  
>  #define SPAPR_PCI_MSI_WINDOW 0x400ULL
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index 5671608cea..bff42f0adb 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -4225,7 +4225,7 @@ static void 
> spapr_machine_2_7_class_options(MachineClass *mc)
>  {
>  .driver   = TYPE_SPAPR_PCI_HOST_BRIDGE,
>  .property = "mem_win_size",
> -.value= stringify(SPAPR_PCI_2_7_MMIO_WIN_SIZE),
> +.value= "0xf8000",
>  },
>  {
>  .driver   = TYPE_SPAPR_PCI_HOST_BRIDGE,

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel