[Xen-devel] [xen-4.10-testing test] 131191: regressions - FAIL

[osstest service owner]

flight 131191 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131191/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stopfail REGR. vs. 129676

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemut-debianhvm-amd64 15 guest-saverestore.2 fail in 
131151 pass in 131191
 test-amd64-amd64-libvirt-vhd 11 guest-startfail pass in 131151
 test-amd64-i386-xl-qemut-win7-amd64 15 guest-saverestore.2 fail pass in 131151
 test-armhf-armhf-xl-vhd  15 guest-start/debian.repeat  fail pass in 131151

Tests which did not succeed, but are not blocking:
 test-xtf-amd64-amd64-3   69 xtf/test-hvm64-xsa-278  fail blocked in 129676
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail in 131151 never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stopfail in 131151 never pass
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
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-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-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail 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 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-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail 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-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   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 fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop 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-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   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
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass

version targeted for testing:
 xen  b6e203bc80e9d3e1dc7eb579d9665a77700d78cc
baseline version:
 xen  e907460fd61c350487ffee5d8aa375bef56bc81c

Last test of basis   129676  2018-11-09 01:56:32 Z   32 days
Testing same since   130611  2018-11-20 15:07:52 Z   20 days   11 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Roger Pau Monné 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64-xtf  pass
 build-amd64  pass
 build-armhf  pass
 build-i386

[Xen-devel] [PATCH v2] x86emul: avoid triggering assertions with VME/PVI early #GP check

[Jan Beulich]

In commit efe9cba66c ("x86emul: VME and PVI modes require a #GP(0) check
first thing") I neglected the fact that the retire flags get zapped only
in x86_decode(), which hasn't been invoked yet at the point of the #GP(0)
check added. Move output state initialization into a helper function,
and invoke it from the callers of x86_decode() instead of doing it
(possibly too late) in that function.

Signed-off-by: Jan Beulich 
---
v2: Different approach, different title and description.

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1866,6 +1866,13 @@ static bool vcpu_has(
 #define host_and_vcpu_must_have(feat) vcpu_must_have(feat)
 #endif
 
+/* Initialise output state in x86_emulate_ctxt */
+static void init_context(struct x86_emulate_ctxt *ctxt)
+{
+ctxt->retire.raw = 0;
+x86_emul_reset_event(ctxt);
+}
+
 static int
 realmode_load_seg(
 enum x86_segment seg,
@@ -2713,10 +2720,6 @@ x86_decode(
 state->regs = ctxt->regs;
 state->ip = ctxt->regs->r(ip);
 
-/* Initialise output state in x86_emulate_ctxt */
-ctxt->retire.raw = 0;
-x86_emul_reset_event(ctxt);
-
 op_bytes = def_op_bytes = ad_bytes = def_ad_bytes = ctxt->addr_size/8;
 if ( op_bytes == 8 )
 {
@@ -3400,6 +3403,8 @@ x86_emulate(
 
 ASSERT(ops->read);
 
+init_context(ctxt);
+
 generate_exception_if((mode_vif() &&
(_regs.eflags & X86_EFLAGS_VIF) &&
(_regs.eflags & X86_EFLAGS_VIP)),
@@ -9791,8 +9796,11 @@ x86_decode_insn(
 .insn_fetch = insn_fetch,
 .read   = x86emul_unhandleable_rw,
 };
-int rc = x86_decode(state, ctxt, &ops);
+int rc;
+
+init_context(ctxt);
 
+rc = x86_decode(state, ctxt, &ops);
 if ( unlikely(rc != X86EMUL_OKAY) )
 return ERR_PTR(-rc);
 





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

[Xen-devel] [PATCH v2] x86emul: fix vector-length check for AVX512F scalar fused-multiply-add insns

[Jan Beulich]

The check needs to happen whenever EVEX.b (SDM nomenclature) is clear,
not just in the memory operand case.

Signed-off-by: Jan Beulich 
---
v2: Clarify naming (to address apparent disconnect between description
and code change).

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -8526,11 +8526,9 @@ x86_emulate(
 case X86EMUL_OPC_EVEX_66(0x0f38, 0xbd): /* vfnmadd231s{s,d} 
xmm/mem,xmm,xmm{k} */
 case X86EMUL_OPC_EVEX_66(0x0f38, 0xbf): /* vfnmsub231s{s,d} 
xmm/mem,xmm,xmm{k} */
 host_and_vcpu_must_have(avx512f);
-if ( ea.type == OP_MEM )
-{
-generate_exception_if(evex.br, EXC_UD);
+generate_exception_if(ea.type != OP_REG && evex.br, EXC_UD);
+if ( !evex.br )
 avx512_vlen_check(true);
-}
 goto simd_zmm;
 
 case X86EMUL_OPC(0x0f38, 0xc8): /* sha1nexte xmm/m128,xmm */



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

[Xen-devel] [PATCH] x86emul: work around SandyBridge errata

[Jan Beulich]

There are a number of exception condition related errata on SandyBridge
CPUs, some of which are unexpected #UD (others, of no interest here, are
lack of mandated exceptions, or exceptions of unexpected type). Annotate
the one workaround we already have, and add two more.

Due to the exception recovery we have in place for stub invocations
these aren't security issues.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -6078,9 +6078,11 @@ x86_emulate(
 else
 {
 generate_exception_if(vex.reg != 0xf, EXC_UD);
-vex.l = 0;
 host_and_vcpu_must_have(avx);
 get_fpu(X86EMUL_FPU_ymm);
+
+/* Work around erratum BT230. */
+vex.l = 0;
 }
 
 opc = init_prefixes(stub);
@@ -6983,6 +6985,9 @@ x86_emulate(
 get_fpu(X86EMUL_FPU_mmx);
 }
 
+/* Work around erratum BT36. */
+vex.w = 0;
+
 opc = init_prefixes(stub);
 opc[0] = b;
 insn_bytes = PFX_BYTES + 1;
@@ -8815,6 +8820,11 @@ x86_emulate(
 generate_exception_if(vex.l || vex.reg != 0xf, EXC_UD);
 host_and_vcpu_must_have(avx);
 get_fpu(X86EMUL_FPU_ymm);
+
+/* Work around erratum BT41. */
+if ( !mode_64bit() )
+vex.w = 0;
+
 opc = init_prefixes(stub);
 goto pextr;
 





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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qcow2 7 xen-boot fail REGR. vs. 125898
 test-amd64-amd64-pygrub   7 xen-boot fail REGR. vs. 125898
 test-amd64-amd64-xl-qemuu-win7-amd64  7 xen-boot fail REGR. vs. 125898
 test-amd64-amd64-libvirt-xsm  7 xen-boot fail REGR. vs. 125898
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 125898
 test-amd64-amd64-xl-pvhv2-intel  7 xen-boot  fail REGR. vs. 125898
 test-amd64-amd64-rumprun-amd64  7 xen-boot   fail REGR. vs. 125898
 test-amd64-amd64-libvirt-vhd  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-amd64-xl-multivcpu  7 xen-bootfail 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-i386-examine   8 reboot   fail REGR. vs. 125898
 test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 125898
 test-amd64-i386-xl7 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-xl-shadow 7 xen-boot fail REGR. vs. 125898
 test-amd64-i386-libvirt   7 xen-boot fail REGR. vs. 125898
 test-amd64-i386-rumprun-i386  7 xen-boot fail REGR. vs. 125898
 test-amd64-i386-xl-qemut-debianhvm-amd64  7 xen-boot fail REGR. vs. 125898
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  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-i386-libvirt-xsm   7 xen-boot fail REGR. vs. 125898
 test-amd64-amd64-examine  8 reboot   fail REGR. vs. 125898
 test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail REGR. vs. 
125898
 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 125898
 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 125898
 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 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-qemut-win7-amd64 17 guest-stopfail like 125898
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 125898
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 125898
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 125898
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 125898
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 125898
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 125898
 test-amd64-i386-xl-pvshim12 guest-start  fail   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-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail 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-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-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-libvirt 13 migrate-support-checkfail   never pass
 tes

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

[Olaf Hering]

Ping?


On Fri, Oct 26, Olaf Hering wrote:

> A given Qemu version can not predict what version of Xen it will run on.
> There are some checks in configure to decide what Xen libraries and
> functions are available. How exactly these functions must be accessed
> has to be decided by configure and the user who is compiling Qemu.
> In no way some random header file must override this decision.
> 
> Remove the breakage introduced by commit 5eeb39c24b, which would always
> hide the libxc interfaces the given version of Qemu knows about.
> 
> The current symptom of such breakage is a build failure with qemu-2.9
> and older, in combination with Xen 4.12.
> 
> Fixes: 5eeb39c24b7d4da5d129bfdd9c4fd21cfb3d28d6
> Signed-off-by: Olaf Hering 
> ---
>  include/hw/xen/xen_common.h | 9 -
>  1 file changed, 9 deletions(-)
> 
> diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
> index 5f1402b494..33fa2d3497 100644
> --- a/include/hw/xen/xen_common.h
> +++ b/include/hw/xen/xen_common.h
> @@ -1,15 +1,6 @@
>  #ifndef QEMU_HW_XEN_COMMON_H
>  #define QEMU_HW_XEN_COMMON_H
>  
> -/*
> - * If we have new enough libxenctrl then we do not want/need these compat
> - * interfaces, despite what the user supplied cflags might say. They
> - * must be undefined before including xenctrl.h
> - */
> -#undef XC_WANT_COMPAT_EVTCHN_API
> -#undef XC_WANT_COMPAT_GNTTAB_API
> -#undef XC_WANT_COMPAT_MAP_FOREIGN_API
> -
>  #include 
>  #include 
>  #include 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel


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

Re: [Xen-devel] [PATCH] kprobes/x86/xen: blacklist non-attachable xen interrupt functions

[Masami Hiramatsu]

On Mon, 10 Dec 2018 16:12:57 +0100
Andrea Righi  wrote:

> Blacklist symbols in Xen probe-prohibited areas, so that user can see
> these prohibited symbols in debugfs.
> 
> See also: a50480cb6d61.

Looks good to me, thanks!

Acked-by: Masami Hiramatsu 

> 
> Signed-off-by: Andrea Righi 
> ---
>  arch/x86/xen/xen-asm_64.S | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/x86/xen/xen-asm_64.S b/arch/x86/xen/xen-asm_64.S
> index bb1c2da0381d..1e9ef0ba30a5 100644
> --- a/arch/x86/xen/xen-asm_64.S
> +++ b/arch/x86/xen/xen-asm_64.S
> @@ -12,6 +12,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  
> @@ -24,6 +25,7 @@ ENTRY(xen_\name)
>   pop %r11
>   jmp  \name
>  END(xen_\name)
> +_ASM_NOKPROBE(xen_\name)
>  .endm
>  
>  xen_pv_trap divide_error
> -- 
> 2.17.1
> 


-- 
Masami Hiramatsu 

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

Re: [Xen-devel] [PATCH V2] x86/vm_event: block interrupt injection for sync vm_events

[Razvan Cojocaru]

On 12/10/18 6:59 PM, Razvan Cojocaru wrote:
> On 12/10/18 6:49 PM, Roger Pau Monné wrote:
>> On Mon, Dec 10, 2018 at 06:01:49PM +0200, Razvan Cojocaru wrote:
>>> diff --git a/xen/include/asm-arm/vm_event.h b/xen/include/asm-arm/vm_event.h
>>> index 66f2474..b63249e 100644
>>> --- a/xen/include/asm-arm/vm_event.h
>>> +++ b/xen/include/asm-arm/vm_event.h
>>> @@ -52,4 +52,10 @@ void vm_event_emulate_check(struct vcpu *v, 
>>> vm_event_response_t *rsp)
>>>  /* Not supported on ARM. */
>>>  }
>>>  
>>> +static inline
>>> +void vm_event_block_interrupts(struct vcpu *v, bool value)
>>> +{
>>> +/* Not supported on ARM. */
>>
>> ASSERT_UNREACHABLE?
> 
> Will do (although if you look at the rest of the function in that header
> it'll break what appears to be the prior convention).

Sorry, on second thought we can't do that, because that function is
being called from the common code - which is why the function became
necessary. Specifically, this it unconditionally called in
monitor_traps(), which is used for all events (ARM and otherwise).

So it's valid to call monitor_traps() for ARM vm_events and expect it to
run without issue, which ASSERT_UNREACHABLE() would of course break.


Thanks,
Razvan

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

Re: [Xen-devel] [PATCH V2] x86/vm_event: block interrupt injection for sync vm_events

[Roger Pau Monné]

On Tue, Dec 11, 2018 at 12:01:53PM +0200, Razvan Cojocaru wrote:
> On 12/10/18 6:59 PM, Razvan Cojocaru wrote:
> > On 12/10/18 6:49 PM, Roger Pau Monné wrote:
> >> On Mon, Dec 10, 2018 at 06:01:49PM +0200, Razvan Cojocaru wrote:
> >>> diff --git a/xen/include/asm-arm/vm_event.h 
> >>> b/xen/include/asm-arm/vm_event.h
> >>> index 66f2474..b63249e 100644
> >>> --- a/xen/include/asm-arm/vm_event.h
> >>> +++ b/xen/include/asm-arm/vm_event.h
> >>> @@ -52,4 +52,10 @@ void vm_event_emulate_check(struct vcpu *v, 
> >>> vm_event_response_t *rsp)
> >>>  /* Not supported on ARM. */
> >>>  }
> >>>  
> >>> +static inline
> >>> +void vm_event_block_interrupts(struct vcpu *v, bool value)
> >>> +{
> >>> +/* Not supported on ARM. */
> >>
> >> ASSERT_UNREACHABLE?
> > 
> > Will do (although if you look at the rest of the function in that header
> > it'll break what appears to be the prior convention).
> 
> Sorry, on second thought we can't do that, because that function is
> being called from the common code - which is why the function became
> necessary. Specifically, this it unconditionally called in
> monitor_traps(), which is used for all events (ARM and otherwise).
> 
> So it's valid to call monitor_traps() for ARM vm_events and expect it to
> run without issue, which ASSERT_UNREACHABLE() would of course break.

But then the functionality that makes use of vm_event_block_interrupts
cannot work reliably on ARM and should not be used?

Thanks, Roger.

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

Re: [Xen-devel] [PATCH V2] x86/vm_event: block interrupt injection for sync vm_events

[Razvan Cojocaru]

On 12/11/18 12:14 PM, Roger Pau Monné wrote:
> On Tue, Dec 11, 2018 at 12:01:53PM +0200, Razvan Cojocaru wrote:
>> On 12/10/18 6:59 PM, Razvan Cojocaru wrote:
>>> On 12/10/18 6:49 PM, Roger Pau Monné wrote:
 On Mon, Dec 10, 2018 at 06:01:49PM +0200, Razvan Cojocaru wrote:
> diff --git a/xen/include/asm-arm/vm_event.h 
> b/xen/include/asm-arm/vm_event.h
> index 66f2474..b63249e 100644
> --- a/xen/include/asm-arm/vm_event.h
> +++ b/xen/include/asm-arm/vm_event.h
> @@ -52,4 +52,10 @@ void vm_event_emulate_check(struct vcpu *v, 
> vm_event_response_t *rsp)
>  /* Not supported on ARM. */
>  }
>  
> +static inline
> +void vm_event_block_interrupts(struct vcpu *v, bool value)
> +{
> +/* Not supported on ARM. */

 ASSERT_UNREACHABLE?
>>>
>>> Will do (although if you look at the rest of the function in that header
>>> it'll break what appears to be the prior convention).
>>
>> Sorry, on second thought we can't do that, because that function is
>> being called from the common code - which is why the function became
>> necessary. Specifically, this it unconditionally called in
>> monitor_traps(), which is used for all events (ARM and otherwise).
>>
>> So it's valid to call monitor_traps() for ARM vm_events and expect it to
>> run without issue, which ASSERT_UNREACHABLE() would of course break.
> 
> But then the functionality that makes use of vm_event_block_interrupts
> cannot work reliably on ARM and should not be used?

Well, it's currently a no-op on ARM so it doesn't make anything worse.
I don't have access to ARM hardware and am unfamiliar with the specifics
of handling interrupts on ARM with regard to vm_events (or even if this
specific problem applies to ARM) - so it's the best that I am able to do
at the moment.

Of course, this patch can be the basis of a future one for ARM if that
work makes sense (perhaps Tamas has more to say about this), or if an
ARM maintaner can point out what modifications should be done I can
compile-test for ARM with a cross-compiler, _hope_ it works, and
re-submit the patch.


Thanks,
Razvan

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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 freebsd  f71d2bdf0c00378411ab60ec1ab76196b920e666
baseline version:
 freebsd  3c25eec2c353aafe1b3338c66bfbaed78075ef43

Last test of basis   131118  2018-12-07 09:21:36 Z4 days
Testing same since   131205  2018-12-10 09:21:49 Z1 days1 attempts


People who touched revisions under test:
  alc 
  avg 
  bde 
  cy 
  emaste 
  eugen 
  imp 
  jchandra 
  jhibbits 
  jilles 
  kib 
  markj 
  Mathy Vanhoef 
  mav 
  mjg 
  mmel 
  scottl 
  sobomax 
  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
   3c25eec2c35..f71d2bdf0c0  f71d2bdf0c00378411ab60ec1ab76196b920e666 -> 
tested/master

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

Re: [Xen-devel] [PATCH 09/21] configure: use pkg-config for obtaining xen version

[Peter Maydell]

On Tue, 25 Apr 2017 at 19:35, Stefano Stabellini  wrote:
>
> From: Juergen Gross 
>
> Instead of trying to guess the Xen version to use by compiling various
> test programs first just ask the system via pkg-config. Only if it
> can't return the version fall back to the test program scheme.
>
> If configure is being called with dedicated flags for the Xen libraries
> use those instead of the pkg-config output. This will avoid breaking
> an in-tree Xen build of an old Xen version while a new Xen version is
> installed on the build machine: pkg-config would pick up the installed
> Xen config files as the Xen tree wouldn't contain any of them.
>
> Signed-off-by: Juergen Gross 
> Signed-off-by: Stefano Stabellini 
> Tested-by: Paul Durrant 
> Reviewed-by: Stefano Stabellini 
> ---
>  configure | 159 
> ++
>  1 file changed, 88 insertions(+), 71 deletions(-)
>
> diff --git a/configure b/configure
> index 271bea8..3133ef8 100755
> --- a/configure
> +++ b/configure
> @@ -1975,30 +1975,46 @@ fi
>  # xen probe
>
>  if test "$xen" != "no" ; then
> -  xen_libs="-lxenstore -lxenctrl -lxenguest"
> -  xen_stable_libs="-lxencall -lxenforeignmemory -lxengnttab -lxenevtchn"
> +  # Check whether Xen library path is specified via --extra-ldflags to avoid
> +  # overriding this setting with pkg-config output. If not, try pkg-config
> +  # to obtain all needed flags.
> +
> +  if ! echo $EXTRA_LDFLAGS | grep tools/libxc > /dev/null && \
> + $pkg_config --exists xencontrol ; then
> +xen_ctrl_version="$(printf '%d%02d%02d' \
> +  $($pkg_config --modversion xencontrol | sed 's/\./ /g') )"
> +xen=yes
> +xen_pc="xencontrol xenstore xenguest xenforeignmemory xengnttab"
> +xen_pc="$xen_pc xenevtchn xendevicemodel"
> +QEMU_CFLAGS="$QEMU_CFLAGS $($pkg_config --cflags $xen_pc)"
> +libs_softmmu="$($pkg_config --libs $xen_pc) $libs_softmmu"
> +LDFLAGS="$($pkg_config --libs $xen_pc) $LDFLAGS"
> +  else

Hi -- this is an old patch, but MJT has just noticed that
it means that (assuming configure takes the "we have a pkg-config
for Xen" path) the Xen libraries get added to both libs_softmmu
and LDFLAGS, which means that everything, including the linux-user
binaries, gets linked against them. The old fallback path
only adds them to libs_softmmu.

Juergen: is there a reason why you added the libs to both
libs_softmmu and LDFLAGS here? Can we just delete the line
that alters LDFLAGS?

thanks
-- PMM

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

Re: [Xen-devel] [Qemu-devel] [PATCH 09/21] configure: use pkg-config for obtaining xen version

[Daniel P . Berrangé]

On Tue, Dec 11, 2018 at 10:34:52AM +, Peter Maydell wrote:
> On Tue, 25 Apr 2017 at 19:35, Stefano Stabellini  
> wrote:
> >
> > From: Juergen Gross 
> >
> > Instead of trying to guess the Xen version to use by compiling various
> > test programs first just ask the system via pkg-config. Only if it
> > can't return the version fall back to the test program scheme.
> >
> > If configure is being called with dedicated flags for the Xen libraries
> > use those instead of the pkg-config output. This will avoid breaking
> > an in-tree Xen build of an old Xen version while a new Xen version is
> > installed on the build machine: pkg-config would pick up the installed
> > Xen config files as the Xen tree wouldn't contain any of them.
> >
> > Signed-off-by: Juergen Gross 
> > Signed-off-by: Stefano Stabellini 
> > Tested-by: Paul Durrant 
> > Reviewed-by: Stefano Stabellini 
> > ---
> >  configure | 159 
> > ++
> >  1 file changed, 88 insertions(+), 71 deletions(-)
> >
> > diff --git a/configure b/configure
> > index 271bea8..3133ef8 100755
> > --- a/configure
> > +++ b/configure
> > @@ -1975,30 +1975,46 @@ fi
> >  # xen probe
> >
> >  if test "$xen" != "no" ; then
> > -  xen_libs="-lxenstore -lxenctrl -lxenguest"
> > -  xen_stable_libs="-lxencall -lxenforeignmemory -lxengnttab -lxenevtchn"
> > +  # Check whether Xen library path is specified via --extra-ldflags to 
> > avoid
> > +  # overriding this setting with pkg-config output. If not, try pkg-config
> > +  # to obtain all needed flags.
> > +
> > +  if ! echo $EXTRA_LDFLAGS | grep tools/libxc > /dev/null && \
> > + $pkg_config --exists xencontrol ; then
> > +xen_ctrl_version="$(printf '%d%02d%02d' \
> > +  $($pkg_config --modversion xencontrol | sed 's/\./ /g') )"
> > +xen=yes
> > +xen_pc="xencontrol xenstore xenguest xenforeignmemory xengnttab"
> > +xen_pc="$xen_pc xenevtchn xendevicemodel"
> > +QEMU_CFLAGS="$QEMU_CFLAGS $($pkg_config --cflags $xen_pc)"
> > +libs_softmmu="$($pkg_config --libs $xen_pc) $libs_softmmu"
> > +LDFLAGS="$($pkg_config --libs $xen_pc) $LDFLAGS"
> > +  else
> 
> Hi -- this is an old patch, but MJT has just noticed that
> it means that (assuming configure takes the "we have a pkg-config
> for Xen" path) the Xen libraries get added to both libs_softmmu
> and LDFLAGS, which means that everything, including the linux-user
> binaries, gets linked against them. The old fallback path
> only adds them to libs_softmmu.
> 
> Juergen: is there a reason why you added the libs to both
> libs_softmmu and LDFLAGS here? Can we just delete the line
> that alters LDFLAGS?

In the 'else' block that takes the non-pkg-config path, the libs are
only added to "libs_softmmu". So I think removing LDFLAGS is right.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

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

[Xen-devel] [PATCH v3 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 

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

diff --git a/hw/block/dataplane/xen-block.c b/hw/block/dataplane/xen-block.c
index 9fae505..98f987d 100644
--- a/hw/block/dataplane/xen-block.c
+++ b/hw/block/dataplane/xen-block.c
@@ -1,6 +1,4 @@
 /*
- *  xen paravirt block device backend
- *
  *  (c) Gerd Hoffmann 
  *
  *  This program is free software; you can redistribute it and/or modify
@@ -19,26 +17,12 @@
  *  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)
+/*
+ * 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.
+ */
 
 struct ioreq {
 blkif_request_t req;
@@ -101,8 +85,6 @@ struct XenBlkDev {
 AioContext  *ctx;
 };
 
-/* - */
-
 static void ioreq_reset(struct ioreq *ioreq)
 {
 memset(&ioreq->req, 0, sizeof(ioreq->req));
@@ -183,11 +165,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 +179,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 (ioreq->req.seg[i].first_sect > ioreq->req.seg[i].last_sect) {
-xen_pv_printf(xendev, 0, "error: first > last sector\n");
+error_report("error: first > last sector");
 goto err;
 }
 if (ioreq->req.seg[i].last_sect * BLOCK_SIZE >= XC_PAGE_SIZE) {
-xen_pv_printf(xendev, 0, "error: page crossing\n");
+error_report("error: page crossing");
 goto err;
 }
 
@@ -232,7 +208,7 @@ static int ioreq_parse(struct ioreq *ioreq)
 ioreq->size += len;
 }
 if (ioreq->start + ioreq->size > blkdev->file_size) {
-xen_pv_printf(xendev, 0, "error: access beyond end of file\n");
+error_report("error: access beyond end of file");
 goto err;
 }
 return 0;
@@ -278,8 +254,7 @@ static int ioreq_grant_copy(struct ioreq *ioreq)
 rc = xen_be_copy_grant_refs(xendev, to_domain, segs, count);
 
 if (rc) {
-xen_pv_printf(xendev, 0,
-  "failed to copy data %d\n", rc);
+error_report("failed to copy data %d", rc);
 ioreq->aio_errors++;
 return -1;
 }
@@ -298,8 +273,9 @@ static void qemu_aio_complete(void *opaque, int ret)
 aio_context_acquire(blkdev->ctx);
 
 if (ret != 0) {
-xen_pv_printf(xendev, 0, "%s I/O error\n",
-  ioreq->req.operation == 

[Xen-devel] [PATCH v3 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 1d63763..4497f75 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"
@@ -1479,6 +1480,8 @@ void xen_hvm_init(PCMachineState *pcms, MemoryRegion 
**ram_memory)
 QLIST_INIT(&state->dev_list);
 device_listener_register(&state->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 3f64a44..d9d6d7b 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 c7e7a3b..0172cd4 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 000..bc04da7
--- /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) {
+xendev_class->realize(

[Xen-devel] [PATCH v3 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 
---
Cc: Kevin Wolf 
Cc: Max Reitz 
Cc: Stefano Stabellini 
Cc: Anthony Perard 

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 |  69 +
 5 files changed, 422 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 63effdc..dd728c3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -403,7 +403,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 53ce575..f34813a 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 335c092..4afbd62 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 000..c29acb0
--- /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 = &blockdev->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 = &blockdev->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) {
+blockdev_class->realize(blockdev, &local_err);
+if (local_err) {
+error_propagate(errp, local_err);
+}
+}
+}
+
+static char *d

[Xen-devel] [PATCH v3 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 
---
Cc: Anthony Perard 
Cc: Stefano Stabellini 
Cc: Kevin Wolf 
Cc: Max Reitz 

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 c29acb0..fa57bf1 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 = &blockdev->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 d9d6d7b..77c0868 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 0172cd4..75dc226 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 000..15b3ad8
--- /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),
+XS_STATE(XenbusStateInitialised),
+   

[Xen-devel] [PATCH v3 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: Stefano Stabellini 
---
Cc: Anthony Perard 

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 faa9fd3..9443f27 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(&xendev->event_notifiers, &channel->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(&channel->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), &error_abort);
 }
 
+static void xen_device_event(void *opaque)
+{
+XenDevice *xendev = opaque;
+unsigned long port = xenevtchn_pending(xendev->xeh);
+
+notifier_list_notify(&xendev->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(&xendev->event_notifiers);
+qemu_set_fd_handler(xenevtchn_fd(xendev->xeh), xen_device_event, NULL,
+xendev);
+
 xen_device_backend_create(xendev, &local_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 63a09b6..f83a95c 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;
+ 

[Xen-devel] [PATCH v3 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/qom29

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  |  814 
 hw/block/dataplane/xen-block.h  |   29 +
 hw/block/trace-events   |   11 +
 hw/block/xen-block.c|  847 +
 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|   69 ++
 hw/xen/xen-bus-helper.c |  184 ++
 hw/xen/xen-bus.c| 1189 +++
 hw/xen/xen-common.c |2 +-
 hw/xen/xen-legacy-backend.c |  853 +
 hw/xen/xen_backend.c|  845 -
 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|   26 +
 include/hw/xen/xen-block.h  |   79 +++
 include/hw/xen/xen-bus-helper.h |   45 ++
 include/hw/xen/xen-bus.h|  138 
 include/hw/xen/xen-legacy-backend.h |  104 +++
 include/hw/xen/xen_backend.h|   99 ---
 include/hw/xen/xen_pvdev.h  |   38 +-
 include/qemu/module.h   |3 +
 40 files changed, 4518 insertions(+), 2042 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
 create mode 100644 hw/xen/xen-legacy-backend.c
 delete mode 100644 hw/xen/xen_backend.c
 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
 create mode 100644 include/hw/xen/xen-legacy-backend.h
 delete mode 100644 include/hw/xen/xen_backend.h
---
Cc: Anthony Perard 
Cc: Eduardo Habkost 
Cc: Gerd Hoffmann 
Cc: Greg Kurz 
Cc: Jason Wang 
Cc: Kevin Wolf 
Cc: "Marc-André Lureau" 
Cc: Marcel Apf

[Xen-devel] [PATCH v3 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 5e19592..faa9fd3 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 = &segs[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 = &segs[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 = &segs[i];
+xengnttab_grant_copy_segment_t *xengnttab_seg = &xengnttab_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 = &xengnttab_segs[i];
+
+if (xengntta

[Xen-devel] [PATCH v3 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 
---
Cc: Kevin Wolf 
Cc: Max Reitz 
Cc: Stefano Stabellini 
Cc: Anthony Perard 

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 4afbd62..89e2583 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 fa57bf1..5932672 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 = &blockdev->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 = &blockdev->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, &local_err);
+if (local_err) {
+error_propagate(errp, local_err);
+break;
+}
+
+xen_block_connect(xendev, &local_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, &local_err);
+if (local_err) {
+error_propagate(errp, local_err);
+break;
+}
+
+xen_device_backend_set_state(xendev, XenbusStateClosed);
+

[Xen-devel] [PATCH v3 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 dd728c3..ab62ad4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -404,6 +404,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 000..9fae505
--- /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(&ioreq->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(&ioreq->list, 0, sizeof(ioreq->list));
+memset(&ioreq->acct, 0, sizeof(ioreq->acct))

[Xen-devel] [PATCH v3 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 +-
 hw/xen/xen-legacy-backend.c | 854 
 hw/xen/xen_backend.c| 845 ---
 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 +-
 include/hw/xen/xen-legacy-backend.h | 104 +
 include/hw/xen/xen_backend.h|  99 -
 include/hw/xen/xen_pvdev.h  |  38 +-
 24 files changed, 1059 insertions(+), 1041 deletions(-)
 create mode 100644 hw/xen/xen-legacy-backend.c
 delete mode 100644 hw/xen/xen_backend.c
 create mode 100644 include/hw/xen/xen-legacy-backend.h
 delete mode 100644 include/hw/xen/xen_backend.h

diff --git a/hw/9pfs/xen-9p-backend.c b/hw/9pfs/xen-9p-backend.c
index 3f54a21..3859a06 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 36eff94..75fe55f 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 ioreq {
 #define MAX_RING_PAGE_OR

[Xen-devel] [PATCH v3 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 
---
Cc: Stefano Stabellini 
Cc: Anthony Perard 
Cc: Kevin Wolf 
Cc: Max Reitz 

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 5932672..f3d21c6 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 = &blockdev->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 = &blockdev->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",
+  &order) != 1) {
+nr_ring_ref = 1;
+ring_ref = g_new(unsigned int, nr_ring_ref);
+
+if (xen_device_frontend_scanf(xendev, "ring-ref", "%u",
+  &ring_ref[0]) != 1) {
+error_setg(errp, "failed to read ring-ref");
+g_free(ring_ref);
+return;
+}
+} else if (order <= blockdev->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",
+  &ring_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",
+  &event_channel) != 1) {
+error_setg(errp, "failed to read event-channel");
+g_free(ring_ref);
+return;
+}
+
+if (xen_device_frontend_scanf(xendev, "protocol", "%ms",
+  &str) != 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);
 }
@@ -69,6 +144,7 @@ static void xen_block_realize(XenDevic

[Xen-devel] [PATCH v3 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 426e83c..8c451ae 100644
--- a/hw/block/dataplane/xen-block.c
+++ b/hw/block/dataplane/xen-block.c
@@ -73,7 +73,7 @@ struct XenBlockDataPlane {
 AioContext *ctx;
 };
 
-static void ioreq_reset(XenBlockRequest *request)
+static void reset_request(XenBlockRequest *request)
 {
 memset(&request->req, 0, sizeof(request->req));
 request->status = 0;
@@ -92,7 +92,7 @@ static void ioreq_reset(XenBlockRequest *request)
 qemu_iovec_reset(&request->v);
 }
 
-static XenBlockRequest *ioreq_start(XenBlockDataPlane *dataplane)
+static XenBlockRequest *xen_block_start_request(XenBlockDataPlane *dataplane)
 {
 XenBlockRequest *request = NULL;
 
@@ -117,7 +117,7 @@ out:
 return request;
 }
 
-static void ioreq_finish(XenBlockRequest *request)
+static void xen_block_finish_request(XenBlockRequest *request)
 {
 XenBlockDataPlane *dataplane = request->dataplane;
 
@@ -127,12 +127,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(&dataplane->freelist, request, list);
 if (finish) {
@@ -146,7 +146,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;
@@ -207,7 +207,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;
@@ -253,9 +253,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;
@@ -272,7 +272,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) {
@@ -283,7 +283,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;
@@ -299,7 +299,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:
@@ -324,9 +324,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;
@@ -349,7 +349,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);
@@ -357,7 +357,7 @@ static bool

[Xen-devel] [PATCH v3 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 20d16e7..6ecd160 100644
--- a/hw/block/dataplane/xen-block.c
+++ b/hw/block/dataplane/xen-block.c
@@ -44,12 +44,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;
@@ -85,33 +85,33 @@ static void ioreq_reset(struct ioreq *ioreq)
 ioreq->aio_inflight = 0;
 ioreq->aio_errors = 0;
 
-ioreq->blkdev = NULL;
+ioreq->dataplane = NULL;
 memset(&ioreq->list, 0, sizeof(ioreq->list));
 memset(&ioreq->acct, 0, sizeof(ioreq->acct));
 
 qemu_iovec_reset(&ioreq->v);
 }
 
-static struct ioreq *ioreq_start(struct XenBlkDev *blkdev)
+static struct ioreq *ioreq_start(XenBlockDataPlane *dataplane)
 {
 struct ioreq *ioreq = NULL;
 
-if (QLIST_EMPTY(&blkdev->freelist)) {
-if (blkdev->requests_total >= blkdev->max_requests) {
+if (QLIST_EMPTY(&dataplane->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(&ioreq->v, 1);
 } else {
 /* get one from freelist */
-ioreq = QLIST_FIRST(&blkdev->freelist);
+ioreq = QLIST_FIRST(&dataplane->freelist);
 QLIST_REMOVE(ioreq, list);
 }
-QLIST_INSERT_HEAD(&blkdev->inflight, ioreq, list);
-blkdev->requests_inflight++;
+QLIST_INSERT_HEAD(&dataplane->inflight, ioreq, list);
+dataplane->requests_inflight++;
 
 out:
 return ioreq;
@@ -119,26 +119,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(&blkdev->finished, ioreq, list);
-blkdev->requests_inflight--;
-blkdev->requests_finished++;
+QLIST_INSERT_HEAD(&dataplane->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(&blkdev->freelist, ioreq, list);
+ioreq->dataplane = dataplane;
+QLIST_INSERT_HEAD(&dataplane->freelist, ioreq, list);
 if (finish) {
-blkdev->requests_finished--;
+dataplane->requests_finished--;
 } else {
-blkdev->requests_inflight--;
+dataplane->requests_inflight--;
 }
 }
 
@@ -148,7 +148,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;
 
@@ -171,12 +171,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");
@@ -186,16 +186,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->r

[Xen-devel] [PATCH v3 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 6ecd160..426e83c 100644
--- a/hw/block/dataplane/xen-block.c
+++ b/hw/block/dataplane/xen-block.c
@@ -34,7 +34,7 @@
 #include "sysemu/iothread.h"
 #include "xen-block.h"
 
-struct ioreq {
+typedef struct XenBlockRequest {
 blkif_request_t req;
 int16_t status;
 off_t start;
@@ -45,9 +45,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;
@@ -60,9 +60,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;
@@ -73,68 +73,68 @@ struct XenBlockDataPlane {
 AioContext *ctx;
 };
 
-static void ioreq_reset(struct ioreq *ioreq)
+static void ioreq_reset(XenBlockRequest *request)
 {
-memset(&ioreq->req, 0, sizeof(ioreq->req));
-ioreq->status = 0;
-ioreq->start = 0;
-ioreq->buf = NULL;
-ioreq->size = 0;
-ioreq->presync = 0;
+memset(&request->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(&ioreq->list, 0, sizeof(ioreq->list));
-memset(&ioreq->acct, 0, sizeof(ioreq->acct));
+request->dataplane = NULL;
+memset(&request->list, 0, sizeof(request->list));
+memset(&request->acct, 0, sizeof(request->acct));
 
-qemu_iovec_reset(&ioreq->v);
+qemu_iovec_reset(&request->v);
 }
 
-static struct ioreq *ioreq_start(XenBlockDataPlane *dataplane)
+static XenBlockRequest *ioreq_start(XenBlockDataPlane *dataplane)
 {
-struct ioreq *ioreq = NULL;
+XenBlockRequest *request = NULL;
 
 if (QLIST_EMPTY(&dataplane->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(&ioreq->v, 1);
+qemu_iovec_init(&request->v, 1);
 } else {
 /* get one from freelist */
-ioreq = QLIST_FIRST(&dataplane->freelist);
-QLIST_REMOVE(ioreq, list);
+request = QLIST_FIRST(&dataplane->freelist);
+QLIST_REMOVE(request, list);
 }
-QLIST_INSERT_HEAD(&dataplane->inflight, ioreq, list);
+QLIST_INSERT_HEAD(&dataplane->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(&dataplane->finished, ioreq, list);
+QLIST_REMOVE(request, list);
+QLIST_INSERT_HEAD(&dataplane->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(&dataplane->freelist, ioreq, list);
+QLIST_REMOVE(request, list);
+io

[Xen-devel] [PATCH v3 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 9875581..e6bd441 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -396,6 +396,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.1.4


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

[Xen-devel] [PATCH v3 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 ab62ad4..9875581 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -408,6 +408,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 e786f66..c6c68db 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 98f987d..20d16e7 100644
--- a/hw/block/dataplane/xen-block.c
+++ b/hw/block/dataplane/xen-block.c
@@ -24,65 +24,53 @@
  * See the COPYING file in the top-level directory.
  */
 
+#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)
@@ -161,7 +149,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 = &blkdev->xendev;
 size_t len;
 int i;
 
@@ -183,7 +170,8 @@ static int ioreq_parse(struct ioreq *ioreq)
 goto err;
 };
 
-if (ioreq-

[Xen-devel] [PATCH v3 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 a creator function to be called when a tool-
stack instantiates a new backend in this way.

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 
---
Cc: Anthony Perard 
Cc: Stefano Stabellini 
Cc: Anthony Perard 

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 |  69 +++
 hw/xen/xen-bus.c | 154 +++
 include/hw/xen/xen-backend.h |  26 
 include/hw/xen/xen-bus.h |   1 +
 include/qemu/module.h|   3 +
 7 files changed, 257 insertions(+), 1 deletion(-)
 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 77c0868..84df60a 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 d4651bd..f694462 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 000..d87e6ec
--- /dev/null
+++ b/hw/xen/xen-backend.c
@@ -0,0 +1,69 @@
+/*
+ * 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 "hw/xen/xen-backend.h"
+
+typedef struct XenBackendImpl {
+const char *type;
+XenBackendDeviceCreate create;
+} XenBackendImpl;
+
+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 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;
+
+xen_backend_table_add(impl);
+}
+
+void xen_backend_device_create(BusState *bus, const char *type,
+   const char *name, QDict *opts, Error **errp)
+{
+XenBackendImpl *impl = xen_backend_table_lookup(type);
+
+if (impl) {
+impl->create(bus, name, opts, errp);
+}
+}
diff --git a/hw/xen/xen-bus.c b/hw/xen/xen-bus.c
index a22aa49..7593d61 100644
--- a/hw/xen/xen-bus.c
+++ b/hw/xen/xen-bus.c
@@ -11,10 +11,12 @@
 #include "hw/hw.h"
 #include "hw/sysbus.h"
 #include "hw/xen/xen.h"
+#include "hw/xen/xen-backend.h"
 #include "hw/xen/xen-bus.h"
 #include "hw/xen/xen-bus-helper.h"
 #include "monitor/monito

[Xen-devel] [PATCH v3 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 f34813a..e206b8e 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 75fe55f..000
--- 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(&ioreq->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(&ioreq->list, 0, sizeof(ioreq->list));
-memset(&ioreq->acct, 0, sizeof(ioreq->acct));
-
-qemu_iovec_reset(&ioreq->v);
-}
-
-static struct ioreq *ioreq_start(struct XenBlkDev *blkdev)
-{
-struct ioreq *ioreq = NULL;
-
-if (QLIST_EMPTY(&blkdev->freelist)) {
-if (blkdev->requests_total >= blkdev->max_requests) {
-goto out;
-}
-/* allocate new struct */
-ioreq = g_malloc0(sizeof(*ioreq));
-ioreq-

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

[Paul Durrant]

This patch adds a creator function for XenBlockDevice-s so that they can
be created automatically when the Xen toolstack instantiates a new
PV backend. 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 drive is marked 'auto_del' so
that it will be removed when the XenBlockDevice is destroyed. Also, for
compatibility with the legacy 'xen_disk' implementation, an iothread
is automatically created for the new XenBlockDevice. This will also be
removed when the XenBlockDevice is destroyed.

Correspondingly the legacy backend scan for 'qdisk' is removed.

After this patch is applied the legacy 'xen_disk' code is redundant. It
will be removed by a subsequent patch.

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

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

diff --git a/hw/block/trace-events b/hw/block/trace-events
index 89e2583..a89c8a6 100644
--- a/hw/block/trace-events
+++ b/hw/block/trace-events
@@ -137,3 +137,4 @@ xen_disk_realize(void) ""
 xen_disk_unrealize(void) ""
 xen_cdrom_realize(void) ""
 xen_cdrom_unrealize(void) ""
+xen_block_device_create(const char *name) "name: %s"
diff --git a/hw/block/xen-block.c b/hw/block/xen-block.c
index f3d21c6..0d1616d 100644
--- a/hw/block/xen-block.c
+++ b/hw/block/xen-block.c
@@ -7,12 +7,15 @@
 
 #include "qemu/osdep.h"
 #include "qemu/cutils.h"
+#include "qemu/option.h"
 #include "qapi/error.h"
 #include "qapi/visitor.h"
+#include "qapi/qmp/qdict.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"
@@ -131,6 +134,11 @@ static void xen_block_unrealize(XenDevice *xendev, Error 
**errp)
 xen_block_dataplane_destroy(blockdev->dataplane);
 blockdev->dataplane = NULL;
 
+if (blockdev->auto_iothread) {
+iothread_destroy(blockdev->auto_iothread);
+blockdev->auto_iothread = NULL;
+}
+
 if (blockdev_class->unrealize) {
 blockdev_class->unrealize(blockdev, errp);
 }
@@ -145,6 +153,8 @@ static void xen_block_realize(XenDevice *xendev, Error 
**errp)
 XenBlockVdev *vdev = &blockdev->vdev;
 Error *local_err = NULL;
 BlockConf *conf = &blockdev->conf;
+IOThread *iothread = blockdev->auto_iothread ?
+blockdev->auto_iothread : blockdev->iothread;
 
 if (vdev->type == XEN_BLOCK_VDEV_TYPE_INVALID) {
 error_setg(errp, "vdev property not set");
@@ -212,7 +222,7 @@ static void xen_block_realize(XenDevice *xendev, Error 
**errp)
   conf->logical_block_size);
 
 blockdev->dataplane = xen_block_dataplane_create(xendev, conf,
- blockdev->iothread);
+ iothread);
 }
 
 static void xen_block_frontend_changed(XenDevice *xendev,
@@ -474,6 +484,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 +597,251 @@ static void xen_block_register_types(void)
 }
 
 type_init(xen_block_register_types)
+
+static void xen_block_drive_create(const char *id, const char *device_type,
+   QDict *opts, Error **errp)
+{
+const char *params = qdict_get_try_str(opts, "params");
+const char *mode = qdict_get_try_str(opts, "mode");
+const char *direct_io_safe = qdict_get_try_str(opts, "direct-io-safe");
+const char *discard_enable = qdict_get_try_str(opts, "discard-enable");
+char *format = NULL;
+char *file = NULL;
+char *drive_optstr = NULL;
+QemuOpts *drive_opts;
+Error *local_err = NULL;
+
+if (params) {
+char **v = g_strsplit(params, ":", 2);
+
+if (v[1] == NULL) {
+file = g_strdup(v[0]);
+} else {
+if (strcmp(v[0], "aio") == 0) {
+format = g_strdup("raw");
+} else if (strcmp(v[0], "vhd") == 0) {
+format = g_strdup("vpc");
+} else {
+format = g_strdup(v[0]);
+}
+file = g_strdup(v[1]);
+}
+
+g_strfreev(v);
+}
+
+if (!file) {
+error_setg(errp, "no file parameter");
+   

Re: [Xen-devel] [PATCH v3] amd-iommu: remove page merging code

[Paul Durrant]

Ping? This has acks from Andy and Brian now, but has not been committed. Is 
there anything holding it up?

> -Original Message-
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: 28 November 2018 09:56
> To: xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; Suravee Suthikulpanit
> ; Brian Woods 
> Subject: [PATCH v3] amd-iommu: remove page merging code
> 
> The page merging logic makes use of bits 1-8 and bit 63 of a PTE, which
> used to be specified as 'ignored'. However, bits 5 and 6 are now specified
> as 'accessed' and 'dirty' bits and their use only remains safe as long as
> the DTE 'Host Access Dirty' bits remain unused by Xen, or by hardware
> before the domain starts running. (XSA-275 disabled the operation of the
> code after domain creation completes).
> 
> With the page merging logic present in its current form there are no spare
> ignored bits in the PTE at all, but PV-IOMMU support will require at least
> one spare bit to track which PTEs are added by hypercall.
> 
> This patch removes the code, freeing up the remaining PTE ignored bits
> for other use, including PV-IOMMU support, as well as significantly
> simplifying and shortening the source by ~170 lines. There may be some
> marginal performance cost (but none has been observed in manual testing
> with a passed-through NVIDIA GPU) since higher order mappings will now be
> ruled out until a mapping order parameter is passed to iommu_ops. That
> will
> be dealt with by a subsequent patch though.
> 
> Signed-off-by: Paul Durrant 
> ---
> Cc: Suravee Suthikulpanit 
> Cc: Brian Woods 
> 
> v3:
>  - Further expand commit comment
> 
> v2:
>  - Remove 'no_merge' boolean
>  - Expand commit comment
> ---
>  xen/drivers/passthrough/amd/iommu_map.c | 175 +--
> -
>  xen/include/asm-x86/iommu.h |   1 -
>  2 files changed, 1 insertion(+), 175 deletions(-)
> 
> diff --git a/xen/drivers/passthrough/amd/iommu_map.c
> b/xen/drivers/passthrough/amd/iommu_map.c
> index 0ac3f473b3..04cb7b3182 100644
> --- a/xen/drivers/passthrough/amd/iommu_map.c
> +++ b/xen/drivers/passthrough/amd/iommu_map.c
> @@ -323,134 +323,6 @@ uint64_t amd_iommu_get_address_from_pte(void *pte)
>  return ptr;
>  }
> 
> -/* For each pde, We use ignored bits (bit 1 - bit 8 and bit 63)
> - * to save pde count, pde count = 511 is a candidate of page coalescing.
> - */
> -static unsigned int get_pde_count(uint64_t pde)
> -{
> -unsigned int count;
> -uint64_t upper_mask = 1ULL << 63 ;
> -uint64_t lower_mask = 0xFF << 1;
> -
> -count = ((pde & upper_mask) >> 55) | ((pde & lower_mask) >> 1);
> -return count;
> -}
> -
> -/* Convert pde count into iommu pte ignored bits */
> -static void set_pde_count(uint64_t *pde, unsigned int count)
> -{
> -uint64_t upper_mask = 1ULL << 8 ;
> -uint64_t lower_mask = 0xFF;
> -uint64_t pte_mask = (~(1ULL << 63)) & (~(0xFF << 1));
> -
> -*pde &= pte_mask;
> -*pde |= ((count & upper_mask ) << 55) | ((count & lower_mask ) << 1);
> -}
> -
> -/* Return 1, if pages are suitable for merging at merge_level.
> - * otherwise increase pde count if mfn is contigous with mfn - 1
> - */
> -static bool iommu_update_pde_count(struct domain *d, unsigned long
> pt_mfn,
> -   unsigned long dfn, unsigned long mfn,
> -   unsigned int merge_level)
> -{
> -unsigned int pde_count, next_level;
> -unsigned long first_mfn;
> -uint64_t *table, *pde, *ntable;
> -uint64_t ntable_maddr, mask;
> -struct domain_iommu *hd = dom_iommu(d);
> -bool ok = false;
> -
> -ASSERT( spin_is_locked(&hd->arch.mapping_lock) && pt_mfn );
> -
> -next_level = merge_level - 1;
> -
> -/* get pde at merge level */
> -table = map_domain_page(_mfn(pt_mfn));
> -pde = table + pfn_to_pde_idx(dfn, merge_level);
> -
> -/* get page table of next level */
> -ntable_maddr = amd_iommu_get_address_from_pte(pde);
> -ntable = map_domain_page(_mfn(paddr_to_pfn(ntable_maddr)));
> -
> -/* get the first mfn of next level */
> -first_mfn = amd_iommu_get_address_from_pte(ntable) >> PAGE_SHIFT;
> -
> -if ( first_mfn == 0 )
> -goto out;
> -
> -mask = (1ULL<< (PTE_PER_TABLE_SHIFT * next_level)) - 1;
> -
> -if ( ((first_mfn & mask) == 0) &&
> - (((dfn & mask) | first_mfn) == mfn) )
> -{
> -pde_count = get_pde_count(*pde);
> -
> -if ( pde_count == (PTE_PER_TABLE_SIZE - 1) )
> -ok = true;
> -else if ( pde_count < (PTE_PER_TABLE_SIZE - 1))
> -{
> -pde_count++;
> -set_pde_count(pde, pde_count);
> -}
> -}
> -
> -else
> -/* non-contiguous mapping */
> -set_pde_count(pde, 0);
> -
> -out:
> -unmap_domain_page(ntable);
> -unmap_domain_page(table);
> -
> -return ok;
> -}
> -
> -static int iommu_merge_pages(struct domain *d, unsigned long pt_mfn,
> - uns

Re: [Xen-devel] [PATCH v2] CONTRIBUTING: Clarifications on how to handle license deviations

[Wei Liu]

On Mon, Dec 10, 2018 at 11:33:09AM -0800, Lars Kurth wrote:
> This patch makes a few clarifications which were discussed on
> IRC recently. 
> 
> Specifically: 
> - Highlight the principle that license deviations
>   should be brought to the attention of maintainers 
> - Add a requirement for GPLv2 compatibility 
> - Restructure the document toghlight  use-cases for  

"tohlight" is still wrong.

This can be fixed while committing though.

>   "New components" and "Importing code" clearer 
> - Add conventions and instructions for "New files"
> 
> Changes since v1:
> - Fixed typo

Note to committers: this needs to be removed while committing.

The text looks good to me:

Acked-by: Wei Liu 

No need to resend just for the commit message.

> 
> Signed-off-by: Lars Kurth 
> ---
>  CONTRIBUTING | 27 +++
>  1 file changed, 23 insertions(+), 4 deletions(-)
> 
> diff --git a/CONTRIBUTING b/CONTRIBUTING
> index cfee8f1567..63050e9141 100644
> --- a/CONTRIBUTING
> +++ b/CONTRIBUTING
> @@ -19,6 +19,19 @@ Most notably:
>   - tools/xl   : LGPL v2.1
>   - xen/include/public : MIT license
>  
> +The COMMON COPYRIGHT NOTICES section of this document contains
> +sample copyright notices for the most common licenses used within
> +this repository.
> +
> +When creating new components, new files, or importing code please follow
> +the conventions outlined below. As a general rule, whenever code using a
> +license other than GPLv2 is introduced, attention must be drawn to the
> +difference, such that maintainers can make an informed decision about the
> +deviation. Any new code must be GPLv2 compatible.
> +
> +New components
> +--
> +
>  When creating new components and directories that contain a
>  significant amount of files that are licensed under licenses other
>  than GPLv2 or the license specified in the COPYING file, please
> @@ -27,15 +40,21 @@ license text and a rationale for using a different 
> license. This helps
>  ensure that the license of this new component/directory is maintained
>  consistently with the original intention.
>  
> +New files
> +-
> +
> +If specific files that differ from the license in a directory are introduced,
> +exceptions should be highlighted and discussed in the commit message or cover
> +letter introducing the file.
> +
> +Importing code
> +--
> +
>  When importing code from other upstream projects into this repository,
>  please create a README.source file in the directory the code is imported
>  to, listing the original source of the code. An example can be found at
>  m4/README.source
>  
> -The COMMON COPYRIGHT NOTICES section of this document contains
> -sample copyright notices for the most common licenses used within
> -this repository.
> -
>  Developer's Certificate of Origin
>  -
>  
> -- 
> 2.13.0
> 

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

Re: [Xen-devel] [PATCH v3] amd-iommu: remove page merging code

[Jan Beulich]

>>> On 11.12.18 at 12:00,  wrote:
> Ping? This has acks from Andy and Brian now, but has not been committed. Is 
> there anything holding it up?

I keep overlooking it when checking what is ready to be committed,
sorry.

Jan



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

Re: [Xen-devel] [PATCH v3] amd-iommu: remove page merging code

[Paul Durrant]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 11 December 2018 11:22
> To: Paul Durrant 
> Cc: Brian Woods ; Suravee Suthikulpanit
> ; xen-devel  de...@lists.xenproject.org>
> Subject: Re: [Xen-devel] [PATCH v3] amd-iommu: remove page merging code
> 
> >>> On 11.12.18 at 12:00,  wrote:
> > Ping? This has acks from Andy and Brian now, but has not been committed.
> Is
> > there anything holding it up?
> 
> I keep overlooking it when checking what is ready to be committed,
> sorry.
> 

Just wanted to make sure I didn't need to chase anyone else :-) I need this and 
the flush eliding to move on with PV-IOMMU.

  Paul

> Jan
> 


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

Re: [Xen-devel] [PATCH v2] CONTRIBUTING: Clarifications on how to handle license deviations

[Julien Grall]

Hi Lars,

On 10/12/2018 19:33, Lars Kurth wrote:

This patch makes a few clarifications which were discussed on
IRC recently.

Specifically:
- Highlight the principle that license deviations
   should be brought to the attention of maintainers
- Add a requirement for GPLv2 compatibility
- Restructure the document toghlight  use-cases for
   "New components" and "Importing code" clearer
- Add conventions and instructions for "New files"

Changes since v1:
- Fixed typo

Signed-off-by: Lars Kurth 


Acked-by: Julien Grall 

Cheers,


---
  CONTRIBUTING | 27 +++
  1 file changed, 23 insertions(+), 4 deletions(-)

diff --git a/CONTRIBUTING b/CONTRIBUTING
index cfee8f1567..63050e9141 100644
--- a/CONTRIBUTING
+++ b/CONTRIBUTING
@@ -19,6 +19,19 @@ Most notably:
   - tools/xl   : LGPL v2.1
   - xen/include/public : MIT license
  
+The COMMON COPYRIGHT NOTICES section of this document contains

+sample copyright notices for the most common licenses used within
+this repository.
+
+When creating new components, new files, or importing code please follow
+the conventions outlined below. As a general rule, whenever code using a
+license other than GPLv2 is introduced, attention must be drawn to the
+difference, such that maintainers can make an informed decision about the
+deviation. Any new code must be GPLv2 compatible.
+
+New components
+--
+
  When creating new components and directories that contain a
  significant amount of files that are licensed under licenses other
  than GPLv2 or the license specified in the COPYING file, please
@@ -27,15 +40,21 @@ license text and a rationale for using a different license. 
This helps
  ensure that the license of this new component/directory is maintained
  consistently with the original intention.
  
+New files

+-
+
+If specific files that differ from the license in a directory are introduced,
+exceptions should be highlighted and discussed in the commit message or cover
+letter introducing the file.
+
+Importing code
+--
+
  When importing code from other upstream projects into this repository,
  please create a README.source file in the directory the code is imported
  to, listing the original source of the code. An example can be found at
  m4/README.source
  
-The COMMON COPYRIGHT NOTICES section of this document contains

-sample copyright notices for the most common licenses used within
-this repository.
-
  Developer's Certificate of Origin
  -
  



--
Julien Grall

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

[Xen-devel] [xen-unstable-smoke test] 131225: tolerable all pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  76a68b902062a5ca9053f5cf6a3ab46148cb45f2
baseline version:
 xen  4cf5d6264242aac1c308a89b9869d82732733b08

Last test of basis   131212  2018-12-10 18:00:42 Z0 days
Testing same since   131225  2018-12-11 09:00:50 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Juergen Gross 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt 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/xen.git
   4cf5d62642..76a68b9020  76a68b902062a5ca9053f5cf6a3ab46148cb45f2 -> smoke

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

[Xen-devel] [PATCH] x86: remove out label in spurious_interrupt

[Wei Liu]

The out label is followed by a semicolon only. Use return directly.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/apic.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/xen/arch/x86/apic.c b/xen/arch/x86/apic.c
index 7120107b0c..b06eedf326 100644
--- a/xen/arch/x86/apic.c
+++ b/xen/arch/x86/apic.c
@@ -1406,15 +1406,13 @@ void spurious_interrupt(struct cpu_user_regs *regs)
 if (this_cpu(state_dump_pending)) {
 this_cpu(state_dump_pending) = false;
 dump_execstate(regs);
-goto out;
+return;
 }
 }
 
 /* see sw-dev-man vol 3, chapter 7.4.13.5 */
 printk(KERN_INFO "spurious APIC interrupt on CPU#%d, should "
"never happen.\n", smp_processor_id());
-
-out: ;
 }
 
 /*
-- 
2.11.0


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

[Xen-devel] [PATCH 0/2] Misc patches for common/page_alloc.c

[Wei Liu]

Wei Liu (2):
  xen: clean up common/page_alloc.c
  xen: simplify {check,poison}_one_page

 xen/common/page_alloc.c | 56 -
 1 file changed, 27 insertions(+), 29 deletions(-)

-- 
2.11.0


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

[Xen-devel] [PATCH 2/2] xen: simplify {check,poison}_one_page

[Wei Liu]

Use __map_domain_page macro to deal with page_info directly.

No functional change.

Signed-off-by: Wei Liu 
---
 xen/common/page_alloc.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 677a8e18ce..2c6509e3a0 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -771,13 +771,12 @@ static void page_list_add_scrub(struct page_info *pg, 
unsigned int node,
 static void poison_one_page(struct page_info *pg)
 {
 #ifdef CONFIG_SCRUB_DEBUG
-mfn_t mfn = page_to_mfn(pg);
 uint64_t *ptr;
 
 if ( !scrub_debug )
 return;
 
-ptr = map_domain_page(mfn);
+ptr = __map_domain_page(pg);
 *ptr = ~SCRUB_PATTERN;
 unmap_domain_page(ptr);
 #endif
@@ -786,14 +785,13 @@ static void poison_one_page(struct page_info *pg)
 static void check_one_page(struct page_info *pg)
 {
 #ifdef CONFIG_SCRUB_DEBUG
-mfn_t mfn = page_to_mfn(pg);
 const uint64_t *ptr;
 unsigned int i;
 
 if ( !scrub_debug )
 return;
 
-ptr = map_domain_page(mfn);
+ptr = __map_domain_page(pg);
 for ( i = 0; i < PAGE_SIZE / sizeof (*ptr); i++ )
 BUG_ON(ptr[i] != SCRUB_PATTERN);
 unmap_domain_page(ptr);
-- 
2.11.0


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

[Xen-devel] [PATCH 1/2] xen: clean up common/page_alloc.c

[Wei Liu]

Remove trailing whitespaces. Turn bool_t into bool. Annotate a section
for CONFIG_SEPARATE_XENHEAP.

Signed-off-by: Wei Liu 
---
 xen/common/page_alloc.c | 50 -
 1 file changed, 25 insertions(+), 25 deletions(-)

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index b314b5cee8..677a8e18ce 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -1,21 +1,21 @@
 /**
  * page_alloc.c
- * 
+ *
  * Simple buddy heap allocator for Xen.
- * 
+ *
  * Copyright (c) 2002-2004 K A Fraser
  * Copyright (c) 2006 IBM Ryan Harper 
- * 
+ *
  * 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; either version 2 of the License, or
  * (at your option) any later version.
- * 
+ *
  * 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 .
  */
@@ -330,7 +330,7 @@ void __init init_boot_pages(paddr_t ps, paddr_t pe)
 bootmem_region_add(ps >> PAGE_SHIFT, pe >> PAGE_SHIFT);
 
 #ifdef CONFIG_X86
-/* 
+/*
  * Here we put platform-specific memory range workarounds, i.e.
  * memory known to be corrupt or otherwise in need to be reserved on
  * specific platforms.
@@ -568,7 +568,7 @@ void get_outstanding_claims(uint64_t *free_pages, uint64_t 
*outstanding_pages)
 spin_unlock(&heap_lock);
 }
 
-static bool_t __read_mostly first_node_initialised;
+static bool __read_mostly first_node_initialised;
 #ifndef CONFIG_SEPARATE_XENHEAP
 static unsigned int __read_mostly xenheap_bits;
 #else
@@ -576,7 +576,7 @@ static unsigned int __read_mostly xenheap_bits;
 #endif
 
 static unsigned long init_node_heap(int node, unsigned long mfn,
-unsigned long nr, bool_t *use_tail)
+unsigned long nr, bool *use_tail)
 {
 /* First node to be discovered has its heap metadata statically alloced. */
 static heap_by_zone_and_order_t _heap_static;
@@ -590,7 +590,7 @@ static unsigned long init_node_heap(int node, unsigned long 
mfn,
 {
 _heap[node] = &_heap_static;
 avail[node] = avail_static;
-first_node_initialised = 1;
+first_node_initialised = true;
 needed = 0;
 }
 else if ( *use_tail && nr >= needed &&
@@ -610,7 +610,7 @@ static unsigned long init_node_heap(int node, unsigned long 
mfn,
 _heap[node] = mfn_to_virt(mfn);
 avail[node] = mfn_to_virt(mfn + needed - 1) +
   PAGE_SIZE - sizeof(**avail) * NR_ZONES;
-*use_tail = 0;
+*use_tail = false;
 }
 else if ( get_order_from_bytes(sizeof(**_heap)) ==
   get_order_from_pages(needed) )
@@ -661,7 +661,7 @@ static void __init setup_low_mem_virq(void)
 {
 unsigned int order;
 paddr_t threshold;
-bool_t halve;
+bool halve;
 
 /* If the user specifies zero, then he/she doesn't want this virq
  * to ever trigger. */
@@ -849,8 +849,8 @@ static struct page_info *get_free_buddy(unsigned int 
zone_lo,
 first_node = node;
 
 /*
- * Start with requested node, but exhaust all node memory in requested 
- * zone before failing, only calc new node value if we fail to find memory 
+ * Start with requested node, but exhaust all node memory in requested
+ * zone before failing, only calc new node value if we fail to find memory
  * in target node, this avoids needless computation on fast-path.
  */
 for ( ; ; )
@@ -1268,11 +1268,11 @@ bool scrub_free_pages(void)
 bool preempt = false;
 nodeid_t node;
 unsigned int cnt = 0;
-  
+
 node = node_to_scrub(true);
 if ( node == NUMA_NO_NODE )
 return false;
- 
+
 spin_lock(&heap_lock);
 
 for ( zone = 0; zone < NR_ZONES; zone++ )
@@ -1319,7 +1319,7 @@ bool scrub_free_pages(void)
 /* Someone wants this chunk. Drop everything. */
 
 pg->u.free.first_dirty = (i == (1U << order) - 1) ?
-INVALID_DIRTY_IDX : i + 1; 
+INVALID_DIRTY_IDX : i + 1;
 smp_wmb();
 pg->u.free.scrub_state = BUDDY_NOT_SCRUBBING;
 
@@ -1791,9 +1791,9 @@ static void init_heap_pages(
 {
 unsigned long s = mfn_x(page_to_mfn(pg + i));
 unsigned long e = mfn_x(mfn_add(page_to_mfn(pg + nr_pages - 1), 
1));
-bool_t use_tail = (nid == phys_to_nid(pfn_to_paddr(e - 1))) &&
-  !(s & ((

Re: [Xen-devel] [PATCH V2] x86/vm_event: block interrupt injection for sync vm_events

[Julien Grall]

Hi,

On 11/12/2018 10:21, Razvan Cojocaru wrote:

On 12/11/18 12:14 PM, Roger Pau Monné wrote:

On Tue, Dec 11, 2018 at 12:01:53PM +0200, Razvan Cojocaru wrote:

On 12/10/18 6:59 PM, Razvan Cojocaru wrote:

On 12/10/18 6:49 PM, Roger Pau Monné wrote:

On Mon, Dec 10, 2018 at 06:01:49PM +0200, Razvan Cojocaru wrote:

diff --git a/xen/include/asm-arm/vm_event.h b/xen/include/asm-arm/vm_event.h
index 66f2474..b63249e 100644
--- a/xen/include/asm-arm/vm_event.h
+++ b/xen/include/asm-arm/vm_event.h
@@ -52,4 +52,10 @@ void vm_event_emulate_check(struct vcpu *v, 
vm_event_response_t *rsp)
  /* Not supported on ARM. */
  }
  
+static inline

+void vm_event_block_interrupts(struct vcpu *v, bool value)
+{
+/* Not supported on ARM. */


ASSERT_UNREACHABLE?


Will do (although if you look at the rest of the function in that header
it'll break what appears to be the prior convention).


Sorry, on second thought we can't do that, because that function is
being called from the common code - which is why the function became
necessary. Specifically, this it unconditionally called in
monitor_traps(), which is used for all events (ARM and otherwise).

So it's valid to call monitor_traps() for ARM vm_events and expect it to
run without issue, which ASSERT_UNREACHABLE() would of course break.


But then the functionality that makes use of vm_event_block_interrupts
cannot work reliably on ARM and should not be used?


Well, it's currently a no-op on ARM so it doesn't make anything worse.

Can an vm-event app rely on the interrupts to be blocked?


I don't have access to ARM hardware and am unfamiliar with the specifics
of handling interrupts on ARM with regard to vm_events (or even if this
specific problem applies to ARM) - so it's the best that I am able to do
at the moment.


At the first, the name of the function looks quite wrong for Arm. If you block 
interrupts, you will never receive them again. I read the commit message and I 
am not sure to understand the exact behavior of this function.


Do you mind to provide more explanation what you are trying to achieve?



Of course, this patch can be the basis of a future one for ARM if that
work makes sense (perhaps Tamas has more to say about this), or if an
ARM maintaner can point out what modifications should be done I can
compile-test for ARM with a cross-compiler, _hope_ it works, and
re-submit the patch.


Before pointing out the modifications, I need to understand what you exactly 
want to achieve with it. But then, I think such code should be tested before 
getting merged.


That's fine by me if you don't want to implement it for Arm. However, we need to 
make sure that vm-event app does not expect that behavior.


In any case, I think you want to rename the function and/or document more that 
expected behavior.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 3/3] docs/cmdline: Rewrite the cpuid_mask_* section

[Julien Grall]

Hi Andrew,

On 07/12/2018 15:24, Andrew Cooper wrote:

On 07/12/2018 15:09, Julien Grall wrote:

Hi Andrew,

On 07/12/2018 13:45, Andrew Cooper wrote:

A large amount of the information here is obsolete since Xen 4.7

To being with, however, this patch marks a change in style for section
headings, due to how HTML anchors are generated.  Having more than one
parameter per heading makes an awkward anchor, especially when brace
globbing
is used.  Furthermore, the misc suffixes such as (AMD only) get
included, as
do the escaping for the underscores.

Markdown doesn't require escaped underscores in headings (I'm not
entirely
sure how we ended up with that style), so remove them and fully
expand the
glob syntax.  Also adjust com1,com2 while at it, which is the only other
multi-parameter heading.  Move the misc suffixes into an
"Applicability:" note
alongside the information about defaults.

This results in the headings being unadorned, and identical to how
they are
expressed on the command line and in code.

For cpuid_mask_cpu option, collapse the long line of almost identical
strings
using [] globbing.  The result is much shorter and clearer to read.
Add a
warning that this option no longer masks all features on Fam15h and
above, due
to not making use of the leaf 7 masks.

For the remainder of the cpuid_mask_* options, collapse them all
together into
a single description.

Finally, leave an explicit note explaining that people should not be
using
these options for migration safety.

Signed-off-by: Andrew Cooper 
---
CC: George Dunlap 
CC: Ian Jackson 
CC: Jan Beulich 
CC: Konrad Rzeszutek Wilk 
CC: Stefano Stabellini 
CC: Tim Deegan 
CC: Wei Liu 
CC: Julien Grall 
---
   docs/misc/xen-command-line.markdown | 60
+++--
   1 file changed, 31 insertions(+), 29 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown
b/docs/misc/xen-command-line.markdown
index 175d462..29fec20 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -277,7 +277,8 @@ Interrupts.  Specifying zero disables CMCI handling.
   Flag to indicate whether to probe for a CMOS Real Time Clock
irrespective of
   ACPI indicating none to be there.
   -### com1,com2
+### com1
+### com2


Should not this belong to patch #1?


No.  This change isn't for markdown syntax issues.

It is for a change in how we express headings, and more logically fits
in this patch, as explained (hopefully well enough) in the commit message.


I misread the commit message. It is explained well enough.

Cheers,

--
Julien Grall

___
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: improve paging memory usage calculations

[Wei Liu]

On Mon, Dec 10, 2018 at 11:33:28AM +0100, Roger Pau Monné wrote:
> On Thu, Dec 06, 2018 at 12:42:15PM +, Wei Liu wrote:
> > On Wed, Dec 05, 2018 at 03:55:00PM +0100, Roger Pau Monne wrote:
> > > Current approximation of paging memory usage is based on the required
> > > amount when running in shadow mode and doesn't take into account the
> > > memory required by the IOMMU page tables.
> > > 
> > > Fix this by introducing a function to calculate the amount of memory
> > > required by HAP/IOMMU page tables. The formula used to calculate such
> > > approximation is based on the pessimistic approach that each 4KB
> > > memory chunk will use 8 bytes of page table memory. Note that this
> > > approximation might need further tuning based on testing on different
> > > systems.
> > > 
> > > Also fix the calculation of the required paging related memory in
> > > dom0_compute_nr_pages to take into account the paging implementation
> > > (shadow or HAP) and whether the IOMMU pages tables are shared with the
> > > HAP page tables.
> > > 
> > > Signed-off-by: Roger Pau Monné 
> > > ---
> > > Cc: Jan Beulich 
> > > Cc: Andrew Cooper 
> > > Cc: Wei Liu 
> > > Cc: andrei.seme...@bertin.fr
> > > ---
> > >  xen/arch/x86/dom0_build.c| 31 +++
> > >  xen/arch/x86/hvm/dom0_build.c|  6 --
> > >  xen/include/asm-x86/dom0_build.h |  2 ++
> > >  3 files changed, 33 insertions(+), 6 deletions(-)
> > > 
> > > diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
> > > index ba9aa85611..3a8e138f23 100644
> > > --- a/xen/arch/x86/dom0_build.c
> > > +++ b/xen/arch/x86/dom0_build.c
> > > @@ -267,6 +267,25 @@ unsigned long __init dom0_shadow_pages(const struct 
> > > domain *d,
> > >  return ((memkb + 1023) / 1024) << (20 - PAGE_SHIFT);
> > >  }
> > >  
> > > +unsigned long __init dom0_hap_pages(const struct domain *d,
> > > +unsigned long nr_pages)
> > > +{
> > > +/*
> > > + * Attempt to account for at least some of the MMIO regions by 
> > > adding the
> > > + * size of the holes in the memory map to the amount of pages to 
> > > map. Note
> > > + * this will obviously not account for MMIO regions that are past 
> > > the last
> > > + * RAM range in the memory map.
> > > + */
> > > +nr_pages += max_page - total_pages;
> > 
> > Do those regions past end of RAM range show up in E820 map?
> 
> No, BARs for example don't need to be in reserved regions. I've got
> one box with a 16GB Tesla card that has the 16GB BAR placed way past
> the last entry in the memory map, without any reserved region.
> 
> So while this approach is not perfect, it's better than what we
> currently do, and we can always improve from there if it's clear what
> limitations we currently have.

Fair enough.

Reviewed-by: Wei Liu 

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

Re: [Xen-devel] Xen optimization

[Julien Grall]

On 10/12/2018 12:23, Andrii Anisov wrote:

Hello Julien,

On 10.12.18 13:54, Julien Grall wrote:

What are the numbers without Xen?

Good question. Didn't try. At least putchar should be implemented for that.


I think we need the baremetal numbers to be able to compare properly the old and 
new vGIC.





Which version of Xen are you using?

This morning's staging, commit-id 58eb90a9650a8ea73533bc2b87c13b8ca7bbe35a.


This also tells you that in the trap case the vGIC is not the bigger overhead.
Indeed, not the bigger. But significant even in this trivial case (receiving an 
interrupt twice a second).


To confirm, in your use-case you have the interrupt firing every 500ms, right?

But I am not sure what you are trying to argue here... I never said it was 
insignificant, I only pointed out that the context switch/trap has a strong 
impact. This means that focusing on optimizing context/switch is probably more 
worth it at the moment than trying to micro-optimizing the vGIC.


What matters at the end is the overhead of virtualization (i.e Xen). Without 
those baremetal numbers, it is quite difficult to make an idea whether this is 
significant.





This is with all your series applied but [4], correct?

Right.


Did you try to see the perfomance improvement patch by patch?

No. Not yet.


I would like to have performance per patch so we can make the decisions whether 
the implementation cost is worth it for upstream.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH V2] x86/vm_event: block interrupt injection for sync vm_events

[Razvan Cojocaru]

On 12/11/18 1:59 PM, Julien Grall wrote:
> Hi,
> 
> On 11/12/2018 10:21, Razvan Cojocaru wrote:
>> On 12/11/18 12:14 PM, Roger Pau Monné wrote:
>>> On Tue, Dec 11, 2018 at 12:01:53PM +0200, Razvan Cojocaru wrote:
 On 12/10/18 6:59 PM, Razvan Cojocaru wrote:
> On 12/10/18 6:49 PM, Roger Pau Monné wrote:
>> On Mon, Dec 10, 2018 at 06:01:49PM +0200, Razvan Cojocaru wrote:
>>> diff --git a/xen/include/asm-arm/vm_event.h
>>> b/xen/include/asm-arm/vm_event.h
>>> index 66f2474..b63249e 100644
>>> --- a/xen/include/asm-arm/vm_event.h
>>> +++ b/xen/include/asm-arm/vm_event.h
>>> @@ -52,4 +52,10 @@ void vm_event_emulate_check(struct vcpu *v,
>>> vm_event_response_t *rsp)
>>>   /* Not supported on ARM. */
>>>   }
>>>   +static inline
>>> +void vm_event_block_interrupts(struct vcpu *v, bool value)
>>> +{
>>> +    /* Not supported on ARM. */
>>
>> ASSERT_UNREACHABLE?
>
> Will do (although if you look at the rest of the function in that
> header
> it'll break what appears to be the prior convention).

 Sorry, on second thought we can't do that, because that function is
 being called from the common code - which is why the function became
 necessary. Specifically, this it unconditionally called in
 monitor_traps(), which is used for all events (ARM and otherwise).

 So it's valid to call monitor_traps() for ARM vm_events and expect
 it to
 run without issue, which ASSERT_UNREACHABLE() would of course break.
>>>
>>> But then the functionality that makes use of vm_event_block_interrupts
>>> cannot work reliably on ARM and should not be used?
>>
>> Well, it's currently a no-op on ARM so it doesn't make anything worse.
> Can an vm-event app rely on the interrupts to be blocked?
> 
>> I don't have access to ARM hardware and am unfamiliar with the specifics
>> of handling interrupts on ARM with regard to vm_events (or even if this
>> specific problem applies to ARM) - so it's the best that I am able to do
>> at the moment.
> 
> At the first, the name of the function looks quite wrong for Arm. If you
> block interrupts, you will never receive them again. I read the commit
> message and I am not sure to understand the exact behavior of this
> function.
> 
> Do you mind to provide more explanation what you are trying to achieve?

So on x86 what happens is this:

1. A sync vm_event is sent out, for an EPT fault. This happens in
xen/arch/x86/hvm/hvm.c, which for VMX / Intel is called in
ept_handle_violation(), which in turn is called in vmx_vmexit_handler(),
as a consequence of handling an EXIT_REASON_EPT_VIOLATION exit.

2. Since this is a _sync_ event, this means that the VCPU is now paused
until the introspection agent replies to it. Let's assume that at this
step, the introspection agent does reply, and tells Xen to emulate the
current instruction in the reply.

3. After Xen receives the reply and re-schedules the VCPU to run, we may
see this backtrace (collected on Xen 4.7, but it applies to staging as
well):

(XEN) [] vmx.c#__vmx_inject_exception+0x74/0xc7
(XEN) [] vmx.c#vmx_inject_trap+0x1e1/0x29f
(XEN) [] hvm_inject_trap+0xb0/0xb5
(XEN) [] hvm_inject_page_fault+0x2a/0x2c
(XEN) [] hvm.c#__hvm_copy+0xdd/0x37f
(XEN) [] hvm_copy_to_guest_virt+0x1d/0x1f
(XEN) [] emulate.c#hvmemul_write+0xe0/0x148
(XEN) [] x86_emulate+0xd148/0x11405
(XEN) [] emulate.c#_hvm_emulate_one+0x188/0x2bc
(XEN) [] hvm_emulate_one+0x10/0x12
(XEN) [] hvm_mem_access_emulate_one+0x7a/0xee
(XEN) [] hvm_do_resume+0x246/0x3c5
(XEN) [] vmx_do_resume+0x102/0x119
(XEN) [] context_switch+0xf52/0xfad
(XEN) [] schedule.c#schedule+0x753/0x792
(XEN) [] softirq.c#__do_softirq+0x85/0x90
(XEN) [] do_softirq+0x13/0x15
(XEN) [] domain.c#idle_loop+0x61/0x6e

Now, vmx_inject_exception() calls __vmwrite(VM_ENTRY_INTR_INFO,
intr_fields);, and _before_ we get here, the asm code has already
previously called vmx_intr_assist(), which may have placed some valid
value into VM_ENTRY_INTR_INFO as well. This, of course, means that the
previous value will now be overwritten, and so lost.

The current patch ensures that vmx_intr_info() will _not_ pick that
pending interrupt up until after the sync vm_event has been handled
(which is also essentially how the interrupt should be processed anyway,
since the current instruction is sort-of-in-progress until the sync
vm_event is handled; it's also the strategy VMX single-step has employed).

>> Of course, this patch can be the basis of a future one for ARM if that
>> work makes sense (perhaps Tamas has more to say about this), or if an
>> ARM maintaner can point out what modifications should be done I can
>> compile-test for ARM with a cross-compiler, _hope_ it works, and
>> re-submit the patch.
> 
> Before pointing out the modifications, I need to understand what you
> exactly want to achieve with it. But then, I think such code should be
> tested before getting merged.
> 
> That's fine by me if you don't want to impl

[Xen-devel] [linux-3.18 test] 131192: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-examine   8 reboot   fail REGR. vs. 128858
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs. 
128858
 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 128858
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR. 
vs. 128858
 test-amd64-amd64-xl-multivcpu  7 xen-bootfail REGR. vs. 128858
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. 
vs. 128858
 test-amd64-i386-xl-qemuu-debianhvm-amd64  7 xen-boot fail REGR. vs. 128858
 test-amd64-i386-xl7 xen-boot fail REGR. vs. 128858
 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 128858
 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 128858
 test-amd64-amd64-xl-pvshim7 xen-boot fail REGR. vs. 128858
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 xen-boot  fail REGR. vs. 128858
 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 128858
 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 128858
 test-amd64-amd64-xl-xsm   7 xen-boot fail REGR. vs. 128858
 test-amd64-amd64-libvirt-pair 10 xen-boot/src_host   fail REGR. vs. 128858
 test-amd64-amd64-rumprun-amd64  7 xen-boot   fail REGR. vs. 128858
 test-amd64-amd64-libvirt-pair 11 xen-boot/dst_host   fail REGR. vs. 128858
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 xen-boot fail REGR. vs. 128858
 test-amd64-amd64-pair10 xen-boot/src_hostfail REGR. vs. 128858
 test-amd64-amd64-pair11 xen-boot/dst_hostfail REGR. vs. 128858

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-multivcpu 17 guest-start.2   fail in 131095 pass in 131192
 test-armhf-armhf-xl-cubietruck 12 guest-startfail in 131149 pass in 131192
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 16 
guest-start/debianhvm.repeat fail in 131149 pass in 131192
 test-armhf-armhf-xl-multivcpu 16 guest-start/debian.repeat fail in 131149 pass 
in 131192
 test-amd64-i386-rumprun-i386  7 xen-boot   fail pass in 131095
 test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail pass in 
131149

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-vhd  10 debian-di-install   fail in 131095 like 128841
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail in 
131149 like 128807
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail in 131149 like 
128858
 test-armhf-armhf-libvirt-raw 12 migrate-support-check fail in 131149 never pass
 test-amd64-amd64-examine  4 memdisk-try-append   fail  like 128807
 test-armhf-armhf-libvirt-raw 10 debian-di-installfail  like 128841
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 128858
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 128858
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 128858
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 128858
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 128858
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   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-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  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-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-amd64-amd64-libvirt-vhd 12 migrate-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-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   neve

[Xen-devel] Question about making system thread like kthread in Linux kernel

[Minjun Hong]

Hi. While I review the result of my research, suddenly a good idea comes
up, and I am looking for how to make threads in Xen like kthread in Linux
kernel.

However, after googling and searching for the source code by grep, I have
found only some information regarding stub domain and daemons, such as
xenconsoled and xenbus.

I want a simple thread in Xen to offload some works which is being executed
in the Credit scheduler.

Is there any data structure or API for that purpose in the Xen source code ?

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

Re: [Xen-devel] [PATCH] x86: remove out label in spurious_interrupt

[Jan Beulich]

>>> On 11.12.18 at 12:55,  wrote:
> The out label is followed by a semicolon only. Use return directly.
> 
> Signed-off-by: Wei Liu 

Acked-by: Jan Beulich 



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

Re: [Xen-devel] [Qemu-devel] [PATCH for-3.2 v5 07/19] hw: apply accel compat properties without touching globals

[Igor Mammedov]

On Tue,  4 Dec 2018 18:20:11 +0400
Marc-André Lureau  wrote:

> Instead of registering compat properties as globals, let's keep them
> in their own array, to avoid mixing with user globals.
> 
> Introduce object_apply_global_props() function, to apply compatibility
> properties from a GPtrArray.
> 
> Signed-off-by: Marc-André Lureau 
other than static leak looks fine, considering that we already
leak compat_props, it doesn't really matter, so:

Reviewed-by: Igor Mammedov 

> ---
>  include/hw/qdev-core.h | 10 ++
>  include/qom/object.h   |  3 +++
>  include/sysemu/accel.h |  4 +---
>  accel/accel.c  | 12 
>  hw/core/qdev.c |  9 +
>  hw/xen/xen-common.c|  9 ++---
>  qom/object.c   | 25 +
>  vl.c   |  1 -
>  8 files changed, 54 insertions(+), 19 deletions(-)
> 
> diff --git a/include/hw/qdev-core.h b/include/hw/qdev-core.h
> index a24d0dd566..aeaa6dbbb8 100644
> --- a/include/hw/qdev-core.h
> +++ b/include/hw/qdev-core.h
> @@ -267,6 +267,16 @@ typedef struct GlobalProperty {
>  Error **errp;
>  } GlobalProperty;
>  
> +static inline void
> +compat_props_add(GPtrArray *arr,
> + GlobalProperty props[], size_t nelem)
> +{
> +int i;
> +for (i = 0; i < nelem; i++) {
> +g_ptr_array_add(arr, (void *)&props[i]);
> +}
> +}
> +
>  /*** Board API.  This should go away once we have a machine config file.  
> ***/
>  
>  DeviceState *qdev_create(BusState *bus, const char *name);
> diff --git a/include/qom/object.h b/include/qom/object.h
> index 0139838b69..5183c587f3 100644
> --- a/include/qom/object.h
> +++ b/include/qom/object.h
> @@ -676,6 +676,9 @@ Object *object_new_with_propv(const char *typename,
>Error **errp,
>va_list vargs);
>  
> +void object_apply_global_props(Object *obj, const GPtrArray *props,
> +   Error **errp);
> +
>  /**
>   * object_set_props:
>   * @obj: the object instance to set properties on
> diff --git a/include/sysemu/accel.h b/include/sysemu/accel.h
> index 637358f430..f331d128e9 100644
> --- a/include/sysemu/accel.h
> +++ b/include/sysemu/accel.h
> @@ -49,7 +49,7 @@ typedef struct AccelClass {
>   * global properties may be overridden by machine-type
>   * compat_props or user-provided global properties.
>   */
> -GlobalProperty *global_props;
> +GPtrArray *compat_props;
>  } AccelClass;
>  
>  #define TYPE_ACCEL "accel"
> @@ -67,8 +67,6 @@ typedef struct AccelClass {
>  extern unsigned long tcg_tb_size;
>  
>  void configure_accelerator(MachineState *ms);
> -/* Register accelerator specific global properties */
> -void accel_register_compat_props(AccelState *accel);
>  /* Called just before os_setup_post (ie just before drop OS privs) */
>  void accel_setup_post(MachineState *ms);
>  
> diff --git a/accel/accel.c b/accel/accel.c
> index 3da26eb90f..6db5d8f4df 100644
> --- a/accel/accel.c
> +++ b/accel/accel.c
> @@ -119,18 +119,6 @@ void configure_accelerator(MachineState *ms)
>  }
>  }
>  
> -void accel_register_compat_props(AccelState *accel)
> -{
> -AccelClass *class = ACCEL_GET_CLASS(accel);
> -GlobalProperty *prop = class->global_props;
> -
> -for (; prop && prop->driver; prop++) {
> -/* Any compat_props must never cause error */
> -prop->errp = &error_abort;
> -qdev_prop_register_global(prop);
> -}
> -}
> -
>  void accel_setup_post(MachineState *ms)
>  {
>  AccelState *accel = ms->accelerator;
> diff --git a/hw/core/qdev.c b/hw/core/qdev.c
> index 6b3cc55b27..53b507164f 100644
> --- a/hw/core/qdev.c
> +++ b/hw/core/qdev.c
> @@ -972,6 +972,15 @@ static void device_initfn(Object *obj)
>  
>  static void device_post_init(Object *obj)
>  {
> +if (object_dynamic_cast(qdev_get_machine(), TYPE_MACHINE)) {
> +MachineState *m = MACHINE(qdev_get_machine());
> +AccelClass *ac = ACCEL_GET_CLASS(m->accelerator);
> +
> +if (ac->compat_props) {
> +object_apply_global_props(obj, ac->compat_props, &error_abort);
> +}
> +}
> +
>  qdev_prop_set_globals(DEVICE(obj));
>  }
>  
> diff --git a/hw/xen/xen-common.c b/hw/xen/xen-common.c
> index 6ec14c73ca..4532aa8632 100644
> --- a/hw/xen/xen-common.c
> +++ b/hw/xen/xen-common.c
> @@ -174,18 +174,21 @@ static GlobalProperty xen_compat_props[] = {
>  .driver = "migration",
>  .property = "send-section-footer",
>  .value = "off",
> -},
> -{ /* end of list */ },
> +}
>  };
>  
>  static void xen_accel_class_init(ObjectClass *oc, void *data)
>  {
>  AccelClass *ac = ACCEL_CLASS(oc);
> +
>  ac->name = "Xen";
>  ac->init_machine = xen_init;
>  ac->setup_post = xen_setup_post;
>  ac->allowed = &xen_allowed;
> -ac->global_props = xen_compat_props;
> +ac->compat_props = g_ptr_array_new();
> +
> +compat_props_add(ac->compat_props,
> + 

Re: [Xen-devel] Question about making system thread like kthread in Linux kernel

[Wei Liu]

On Tue, Dec 11, 2018 at 09:40:35PM +0900, Minjun Hong wrote:
> Hi. While I review the result of my research, suddenly a good idea comes
> up, and I am looking for how to make threads in Xen like kthread in Linux
> kernel.
> 
> However, after googling and searching for the source code by grep, I have
> found only some information regarding stub domain and daemons, such as
> xenconsoled and xenbus.
> 
> I want a simple thread in Xen to offload some works which is being executed
> in the Credit scheduler.
> 
> Is there any data structure or API for that purpose in the Xen source code ?

There is no concept of threads in Xen.  You may be able to offload work
to a softirq.

Because Xen deals with domains and vcpus, another idea is to create
"worker" domains / vcpus inside the hypervisor to carry out work. But
that would involve a lot of changes if you want to make the APIs
generic.

Wei.

> 
> Thanks!
> Regards.

> ___
> 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 v9 0/7] KVM: x86: Allow Qemu/KVM to use PVH entry point

[Borislav Petkov]

On Mon, Dec 10, 2018 at 11:05:34AM -0800, Maran Wilson wrote:
> For certain applications it is desirable to rapidly boot a KVM virtual
> machine. In cases where legacy hardware and software support within the
> guest is not needed, Qemu should be able to boot directly into the
> uncompressed Linux kernel binary without the need to run firmware.
> 
> There already exists an ABI to allow this for Xen PVH guests and the ABI
> is supported by Linux and FreeBSD:
> 
>https://xenbits.xen.org/docs/unstable/misc/pvh.html
> 
> This patch series would enable Qemu to use that same entry point for
> booting KVM guests.

How would I do that, practically?

Looking at those here:

>  * Qemu and qboot RFC patches have been posted to show one example of how
>this functionality can be used. Some preliminary numbers are available
>in those cover letters showing the KVM guest boot time improvement.
>   Qemu:
>   http://lists.nongnu.org/archive/html/qemu-devel/2018-12/msg00957.html
>   qboot:
>   http://lists.nongnu.org/archive/html/qemu-devel/2018-12/msg00953.html

I might still need to do some dancing to get stuff going.

Thx.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

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

Re: [Xen-devel] Question about making system thread like kthread in Linux kernel

[Wei Liu]

On Tue, Dec 11, 2018 at 01:17:06PM +, Wei Liu wrote:
> On Tue, Dec 11, 2018 at 09:40:35PM +0900, Minjun Hong wrote:
> > Hi. While I review the result of my research, suddenly a good idea comes
> > up, and I am looking for how to make threads in Xen like kthread in Linux
> > kernel.
> > 
> > However, after googling and searching for the source code by grep, I have
> > found only some information regarding stub domain and daemons, such as
> > xenconsoled and xenbus.
> > 
> > I want a simple thread in Xen to offload some works which is being executed
> > in the Credit scheduler.
> > 
> > Is there any data structure or API for that purpose in the Xen source code ?
> 
> There is no concept of threads in Xen.  You may be able to offload work
> to a softirq.

And there is also tasklet in Xen. Forgot to mention that in my previous
email.

Wei.

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

Re: [Xen-devel] [PATCH v9 1/7] xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and CONFIG_XEN_PVH

[Borislav Petkov]

On Mon, Dec 10, 2018 at 11:07:28AM -0800, Maran Wilson wrote:
> In order to pave the way for hypervisors other than Xen to use the PVH
> entry point for VMs, we need to factor the PVH entry code into Xen specific
> and hypervisor agnostic components. The first step in doing that, is to
> create a new config option for PVH entry that can be enabled
> independently from CONFIG_XEN.
> 
> Signed-off-by: Maran Wilson 
> Reviewed-by: Juergen Gross 
> ---
>  arch/x86/Kconfig  | 6 ++
>  arch/x86/kernel/head_64.S | 2 +-
>  arch/x86/xen/Kconfig  | 3 ++-
>  3 files changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 8689e794a43c..c2a22a74abee 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -796,6 +796,12 @@ config KVM_GUEST
> underlying device model, the host provides the guest with
> timing infrastructure such as time of day, and system time
>  
> +config PVH
> + bool "Support for running PVH guests"
> + ---help---
> +   This option enables the PVH entry point for guest virtual machines
> +   as specified in the x86/HVM direct boot ABI.
> +
>  config KVM_DEBUG_FS
>   bool "Enable debug information for KVM Guests in debugfs"
>   depends on KVM_GUEST && DEBUG_FS
> diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
> index 747c758f67b7..d1dbe8e4eb82 100644
> --- a/arch/x86/kernel/head_64.S
> +++ b/arch/x86/kernel/head_64.S
> @@ -386,7 +386,7 @@ NEXT_PAGE(early_dynamic_pgts)
>  
>   .data
>  
> -#if defined(CONFIG_XEN_PV) || defined(CONFIG_XEN_PVH)
> +#if defined(CONFIG_XEN_PV) || defined(CONFIG_PVH)
>  NEXT_PGD_PAGE(init_top_pgt)
>   .quad   level3_ident_pgt - __START_KERNEL_map + _KERNPG_TABLE_NOENC
>   .orginit_top_pgt + L4_PAGE_OFFSET*8, 0
> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> index 1ef391aa184d..e07abefd3d26 100644
> --- a/arch/x86/xen/Kconfig
> +++ b/arch/x86/xen/Kconfig
> @@ -74,6 +74,7 @@ config XEN_DEBUG_FS
> Enabling this option may incur a significant performance overhead.
>  
>  config XEN_PVH
> - bool "Support for running as a PVH guest"
> + bool "Support for running as a Xen PVH guest"
>   depends on XEN && XEN_PVHVM && ACPI
> + select PVH
>   def_bool n
> -- 

LGTM:

Acked-by: Borislav Petkov 

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

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

[Xen-devel] [xen-unstable test] 131198: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-xtf-amd64-amd64-3   69 xtf/test-hvm64-xsa-278   fail REGR. vs. 130985

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 130985
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 130985
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 130985
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 130985
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 130985
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 130985
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 130985
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 130985
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 130985
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-i386-libvirt-xsm  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-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   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-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-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-libvirt-raw 12 migrate-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-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail 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  58eb90a9650a8ea73533bc2b87c13b8ca7bbe35a
baseline version:
 xen  82855aba5bf91e50c81526167c11d4aeaf665e66

Last test of basis   130985  2018-12-03 17:11:24 Z7 days
Failing since131065  2018-12-05 19:14:18 Z5 days4 attempts
Testing same since   131155  2018-12-08 23:23:51 Z2 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Anthony PERARD 
  Doug Goldstein 
  Jan Beulich 
  Juergen Gross 
  Julien Grall 
  Kevin Tian 
  Oleksandr Tyshchenko 
  Roger Pau Monné 
  Wei Liu 

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  

Re: [Xen-devel] [PATCH 13/25] argo: implement the register op

[Julien Grall]

Hi Christoffer,

On 05/12/2018 22:35, Christopher Clark wrote:

On Wed, Dec 5, 2018 at 9:20 AM Julien Grall  wrote:

On 04/12/2018 09:08, Christopher Clark wrote:

On Sun, Dec 2, 2018 at 12:11 PM Julien Grall  wrote:

On 01/12/2018 01:32, Christopher Clark wrote:

diff --git a/xen/include/public/argo.h b/xen/include/public/argo.h
...
+/* pfn type: 64-bit on all architectures to aid avoiding a compat ABI */
+typedef uint64_t argo_pfn_t;


As you always use 64-bit, can we just use an address? This would make
the ABI agnostic to the hypervisor page granularity.


By address I meant guest physical address (and not guest virtual address).

Arm processors may support multiple page granularity (4KB, 16KB, 64KB). The
software is allowed to use different granularity at different level. This means
that the hypervisor could use 4KB page while the guest kernel would use 64KB
page (and vice versa). Some distros made the choice to only support one type of
page granularity (i.e 64KB for REHL, 4KB for Debian...).

At the moment the hypercall interface is based on the hypervisor page
granularity. Because Xen has always supported 4KB page-granularity, this
assumption was also hardcoded in the kernel.

What prevent us to get 64KB page support in Xen (and therefore support for
52-bit address) is the hypercall ABI. If you upgrade Xen to 64KB then the
hypercall interface would defact use 64KB frame. This would break any current
guest. It is also not possible to keep 4KB pages everywhere because you can only
map 64KB in Xen. So you may map a bit too much from another guest.

This makes me think that the frame is probably not the best in that situation.
Instead a pair of address/size would be more suitable.

The problem is much larger than this series. But I thought I would attempt to
convince the community using guest physical address over guest frame address
whenever it is possible.


Thanks, Julien -- that explanation is very helpful and your request makes sense.

So in concrete terms, with the change that you're advocating for to
this patch, the 64-bit value that is supplied by the guest in the
array passed as an argument to register_ring would encode the same
guest physical frame number as it currently does in the patch version
presented in this thread, but it would be bit-shifted to the position
used in a physical address.

In addition to that change, a page size indicator would be supplied
too -- for every page address supplied in the call.

Is there a method currently used within Xen (or relevant places
elsewhere) for encoding both the page address and size (ie. 4KB, 16KB
or 64KB) within the same 64-bits?
ie. Knowing that the smallest granularity of page is 4KB, and that all
pages are aligned to at least a 4KB boundary, there are low bits in
the address that are known to be zero, and those could be used to
indicate the page size when supplied to this call. It seems like such
an encoding would allow for avoiding doubling the size of the argument
array, but I'm not sure how inconvenient it would be to work with in
practice.

If so, such an interface change looks manageable and hopefully it
would be acceptable to only support 4KB pages in the current
implementation behind that new ABI for the time being. Let me know
what you think.


If you let the user the choice of the granularity, then, I believe, you will 
prevent the hypervisor to do some optimization.


For instance, if the guest supplies only 4KB page but the hypervisor is 64KB. 
There are no way to easily map them contiguously in the hypervisor (e.g using vmap).


Is there a particular reason to allow the ring buffer to be non-contiguous in 
the guest physical address?


Depending on the answer, there are different way to handle that:
	1) Request the guest to allocate memory using 64KB (on Arm) chunk and pass the 
base address for each chunk
	2) Request the guest to allocate contiguously the buffer and pass the base 
address and size


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [RFC 1/3] pvh: Add x86/HVM direct boot ABI header file

[Stefan Hajnoczi]

On Wed, Dec 05, 2018 at 10:37:24PM +, Liam Merwick wrote:
> From: Liam Merwick 
> 
> The x86/HVM direct boot ABI permits Qemu to be able to boot directly
> into the uncompressed Linux kernel binary without the need to run firmware.
> 
>   https://xenbits.xen.org/docs/unstable/misc/pvh.html
> 
> This commit adds the header file that defines the start_info struct
> that needs to be populated in order to use this ABI.
> 
> Signed-off-by: Maran Wilson 
> Signed-off-by: Liam Merwick 
> Reviewed-by: Konrad Rzeszutek Wilk 
> ---
>  include/hw/xen/start_info.h | 146 
> 
>  1 file changed, 146 insertions(+)
>  create mode 100644 include/hw/xen/start_info.h

Does it make sense to bring in Linux
include/xen/interface/hvm/start_info.h via QEMU's
include/standard-headers/?

QEMU has a script in scripts/update-linux-header.sh for syncing Linux
headers into include/standard-headers/.  This makes it easy to keep
Linux header files up-to-date.  We basically treat files in
include/standard-headers/ as auto-generated.

If you define start_info.h yourself without using
include/standard-headers/, then it won't be synced with Linux.


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

Re: [Xen-devel] [PATCH 23/25] argo: signal x86 HVM and ARM via VIRQ

[Julien Grall]

Hi Christopher,

On 04/12/2018 09:03, Christopher Clark wrote:

On Sun, Dec 2, 2018 at 11:55 AM Julien Grall  wrote:


Hi,

On 01/12/2018 01:33, Christopher Clark wrote:

* x86 PV domains are notified via event channel.

PV guests are known to have the event channel software present in the guest
kernel, so it is fine to depend on and use it.

* x86 HVM domains and all ARM domains are notified via VIRQ.

The intent is to remove the requirement for event channel software to be
installed within these guests in order to use Argo. VIRQ signalling is also
the method that has been in use for the longest period with this hypercall
in both XenClient and OpenXT.


I am a bit confused. vIRQs are based on event channel, so how do you
remove the requirement on event channel?


Are VIRQs always delivered via events in all cases? I was under the
impression that was not necessarily so with HVM guests but I haven't
checked and could well be incorrect.


It depends on your meaning of vIRQs. We seem to use it for two cases in the 
hypervisor.


In the context of send_guest_global_virq(), the interrupt will be 
para-virtualized as we delivered via events.


On Arm most of the virtual interrupts will goes through the virtual interrupt 
controller. They can be raised using vgic_inject_irq() and event channel are 
therefore not required. I think this is fairly similar on PVH/HVM but I will let 
the x86 folks confirm here.




A bit of context might help with how this multiple-method logic (as
submitted) was arrived at:

1) Both XenClient's original version of v4v, and that used in OpenXT,
deliver notifications to guests via VIRQ.
This logic has been performing fine for our uses cases, so there
hasn't really been a push to switch away from it.


From my understanding, VIRQ is just a convenience alias for the guest to 
receive the associated event. The guest only need to say "I want to bind VIRQ 
foo". In the other case, you would need to allocate the event channel in the 
hypervisor and then pass the information somehow to the guest.




2) The last version of v4v that was submitted to xen-devel for
iteration with the Xen community was intended to use event channels
instead, in response to a request from Jan at the time. Given that
expressed preference, I've added that, plumbing it in through via the
IPI event method exposed in patch #01, and then used in patch #05, of
the submitted series.

3) Bromium's uxen uses different logic for delivery of events to
non-PV guests: an edge-triggered, ISA IRQ, along these lines:

 #define ARGO_SIGNAL_ISA_IRQ 8
 hvm_isa_irq_assert(d, ARGO_SIGNAL_ISA_IRQ, NULL);
 hvm_isa_irq_deassert(d, ARGO_SIGNAL_ISA_IRQ);

I'm told that this avoids the need to EOI in the guest, reducing the
VMEXIT load, and using an ISA IRQ avoids some logic in Windows that
requires that a device be detected. I briefly looked into adding this
to Argo, but Linux wasn't immediately happy and I haven't had time to
look into it further given the proximity of the 4.12 release, with
other work still to complete.

Anyway: since method 3 isn't ready to submit, and if VIRQs don't have
an advantage over using event channels directly wrt. to needing
in-guest support to function, then I can drop this patch (#23) and
simplify the get_config op (#25), which will leave all notifications
being delivered as events.

Alternatively, if this is about which is the right delivery method for
ARM, with some valid reason to retain use of VIRQ for HVM x86, then
I'm happy to switch ARM over to deliver by the event method rather
than VIRQ if that makes more sense.


For Arm, 3) would look the right approach if you want to avoid the dependencies 
on the event channel driver.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [RFC 2/3] pc: Read PVH entry point from ELF note in kernel binary

[Stefan Hajnoczi]

On Wed, Dec 05, 2018 at 10:37:25PM +, Liam Merwick wrote:
> From: Liam Merwick 
> 
> Add support to read the PVH Entry address from an ELF note in the
> uncompressed kernel binary (as defined by the x86/HVM direct boot ABI).
> This 32-bit entry point will be used by QEMU to load the kernel in the
> guest and jump into the kernel entry point.
> 
> For now, a call to this function is added in pc_memory_init() to read the
> address - a future patch will use the entry point.
> 
> Signed-off-by: Liam Merwick 
> ---
>  hw/i386/pc.c  | 272 
> +-
>  include/elf.h |  10 +++
>  2 files changed, 281 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> index f095725dbab2..056aa46d99b9 100644
> --- a/hw/i386/pc.c
> +++ b/hw/i386/pc.c
> @@ -109,6 +109,9 @@ static struct e820_entry *e820_table;
>  static unsigned e820_entries;
>  struct hpet_fw_config hpet_cfg = {.count = UINT8_MAX};
>  
> +/* Physical Address of PVH entry point read from kernel ELF NOTE */
> +static size_t pvh_start_addr;
> +
>  void gsi_handler(void *opaque, int n, int level)
>  {
>  GSIState *s = opaque;
> @@ -834,6 +837,267 @@ struct setup_data {
>  uint8_t data[0];
>  } __attribute__((packed));
>  
> +/*
> + * Search through the ELF Notes for an entry with the given
> + * ELF Note type
> + */
> +static void *get_elf_note_type(void *ehdr, void *phdr, bool elf_is64,
> +size_t elf_note_type)

Generic ELF code.  Can you put it in hw/core/loader.c?

> +{
> +void *nhdr = NULL;
> +size_t nhdr_size = elf_is64 ? sizeof(Elf64_Nhdr) : sizeof(Elf32_Nhdr);
> +size_t elf_note_entry_sz = 0;
> +size_t phdr_off;
> +size_t phdr_align;
> +size_t phdr_memsz;
> +size_t nhdr_namesz;
> +size_t nhdr_descsz;
> +size_t note_type;

The macro tricks used by hw/core/loader.c are nasty, but I think they
get the types right.  Here the Elf64 on 32-bit host case is definitely
broken due to using size_t.  Perhaps 64-on-32 isn't supported, but
getting the types right is worth discussing.

> +
> +phdr_off = elf_is64 ?
> +((Elf64_Phdr *)phdr)->p_offset : ((Elf32_Phdr *)phdr)->p_offset;
> +phdr_align = elf_is64 ?
> +((Elf64_Phdr *)phdr)->p_align : ((Elf32_Phdr *)phdr)->p_align;
> +phdr_memsz = elf_is64 ?
> +((Elf64_Phdr *)phdr)->p_memsz : ((Elf32_Phdr *)phdr)->p_memsz;
> +
> +nhdr = ehdr + phdr_off;

The ELF file is untrusted.  All inputs must be validated.  phdr_off
could be an bogus/malicious value.

> +note_type = elf_is64 ?
> +((Elf64_Nhdr *)nhdr)->n_type : ((Elf32_Nhdr *)nhdr)->n_type;
> +nhdr_namesz = elf_is64 ?
> +((Elf64_Nhdr *)nhdr)->n_namesz : ((Elf32_Nhdr *)nhdr)->n_namesz;
> +nhdr_descsz = elf_is64 ?
> +((Elf64_Nhdr *)nhdr)->n_descsz : ((Elf32_Nhdr *)nhdr)->n_descsz;
> +
> +while (note_type != elf_note_type) {
> +elf_note_entry_sz = nhdr_size +
> +QEMU_ALIGN_UP(nhdr_namesz, phdr_align) +
> +QEMU_ALIGN_UP(nhdr_descsz, phdr_align);
> +
> +/*
> + * Verify that we haven't exceeded the end of the ELF Note section.
> + * If we have, then there is no note of the given type present
> + * in the ELF Notes.
> + */
> +if (phdr_off + phdr_memsz < ((nhdr - ehdr) + elf_note_entry_sz)) {
> +error_report("Note type (0x%lx) not found in ELF Note section",
> +elf_note_type);
> +return NULL;
> +}
> +
> +/* skip to the next ELF Note entry */
> +nhdr += elf_note_entry_sz;
> +note_type = elf_is64 ?
> +((Elf64_Nhdr *)nhdr)->n_type : ((Elf32_Nhdr *)nhdr)->n_type;
> +nhdr_namesz = elf_is64 ?
> +((Elf64_Nhdr *)nhdr)->n_namesz : ((Elf32_Nhdr *)nhdr)->n_namesz;
> +nhdr_descsz = elf_is64 ?
> +((Elf64_Nhdr *)nhdr)->n_descsz : ((Elf32_Nhdr *)nhdr)->n_descsz;
> +}
> +
> +return nhdr;
> +}
> +
> +/*
> + * The entry point into the kernel for PVH boot is different from
> + * the native entry point.  The PVH entry is defined by the x86/HVM
> + * direct boot ABI and is available in an ELFNOTE in the kernel binary.
> + * This function reads the ELF headers of the binary specified on the
> + * command line by -kernel (path contained in 'filename') and discovers
> + * the PVH entry address from the appropriate ELF Note.
> + *
> + * The address of the PVH entry point is saved to the 'pvh_start_addr'
> + * global variable. The ELF class of the binary is returned via 'elfclass'
> + * (although the entry point is 32-bit, the kernel binary can be either
> + * 32-bit or 64-bit).
> + */
> +static bool read_pvh_start_addr_elf_note(const char *filename,
> +unsigned char *elfclass)
> +{

Can this be integrated into ELF loading?  For example, could the elf
loader take a function pointer to perform additional logic (e.g.
extracting the PVH entry point)?  That avoids reparsing the input file.

> +void *

Re: [Xen-devel] [RFC 05/16] gic-vgic: Drop an excessive clear_lrs

[Julien Grall]

Hi Andrii,

On 28/11/2018 21:32, Andrii Anisov wrote:

From: Andrii Anisov 

This action is excessive because for an invalid LR there is no need
to write another invalid value to a register. So we can skip it here,
saving a peripheral register access.

Signed-off-by: Andrii Anisov 
---
  xen/arch/arm/gic-vgic.c | 1 -
  1 file changed, 1 deletion(-)

diff --git a/xen/arch/arm/gic-vgic.c b/xen/arch/arm/gic-vgic.c
index 869987a..4e18169 100644
--- a/xen/arch/arm/gic-vgic.c
+++ b/xen/arch/arm/gic-vgic.c
@@ -227,7 +227,6 @@ static void gic_update_one_lr(struct vcpu *v, int i)
  }
  else
  {
-gic_hw_ops->clear_lr(i);


I would actually prefer to keep this code for debug build. This makes easier to 
read the dumped LRs as you don't have to worry about invalid one.


With #ifndef NDEBUG and the appropriate comment:

Reviewed-by: Julien Grall 

Feel free to resent it alone so it can be merged to Xen 4.12.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [RFC 11/16] irq: skip action avalability check for guest's IRQ

[Julien Grall]

Hi Andrii,

On 28/11/2018 21:32, Andrii Anisov wrote:

From: Andrii Anisov 

An IRQ assigned to guest always has an action. This removes
another odd check on guest IRQ path.


And you can't see any potential race in that code happening in the future?


Also getting an unknown
interrupt is very unlikely on a non-debug platform.


I am tempted to keep the code at the same place but protect with an #ifndef 
NDEBUG. What do you think?


Like patch #5, feel free to resend the patch alone for Xen 4.12.

Cheers,



Signed-off-by: Andrii Anisov 
---
  xen/arch/arm/irq.c | 14 +++---
  1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index 596a8b8..5debfc5 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -205,13 +205,6 @@ void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, 
int is_fiq)
  spin_lock(&desc->lock);
  desc->handler->ack(desc);
  
-if ( !desc->action )

-{
-printk("Unknown %s %#3.3x\n",
-   is_fiq ? "FIQ" : "IRQ", irq);
-goto out;
-}
-
  if ( test_bit(_IRQ_GUEST, &desc->status) )
  {
  struct irq_guest *info = irq_get_guest_info(desc);
@@ -229,6 +222,13 @@ void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, 
int is_fiq)
  goto out_no_end;
  }
  
+if ( unlikely(!desc->action) )

+{
+printk("Unknown %s %#3.3x\n",
+   is_fiq ? "FIQ" : "IRQ", irq);
+goto out;
+}
+
  set_bit(_IRQ_PENDING, &desc->status);
  
  /*




--
Julien Grall

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

Re: [Xen-devel] [PATCH v5 1/7] xen/arm: introduce platform_smc

[Julien Grall]

Hi Stefano,

On 03/12/2018 21:03, Stefano Stabellini wrote:

From: "Edgar E. Iglesias" 

From: Edgar E. Iglesias 

Introduce platform_smc as a way to handle firmware calls that Xen does
not know about in a platform specific way. This is particularly useful
for implementing the SiP (SoC implementation specific) service calls.

Signed-off-by: Edgar E. Iglesias 
Signed-off-by: Stefano Stabellini 


Acked-by: Julien Grall 

Cheers,



---
Changes in v4:
- add likely
---
  xen/arch/arm/platform.c| 8 
  xen/arch/arm/vsmc.c| 4 
  xen/include/asm-arm/platform.h | 3 +++
  3 files changed, 15 insertions(+)

diff --git a/xen/arch/arm/platform.c b/xen/arch/arm/platform.c
index 6989e58..3426056 100644
--- a/xen/arch/arm/platform.c
+++ b/xen/arch/arm/platform.c
@@ -127,6 +127,14 @@ void platform_poweroff(void)
  platform->poweroff();
  }
  
+bool platform_smc(struct cpu_user_regs *regs)

+{
+if ( likely(platform && platform->smc) )
+return platform->smc(regs);
+
+return false;
+}
+
  bool platform_has_quirk(uint32_t quirk)
  {
  uint32_t quirks = 0;
diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
index c4ccae6..c72b9a0 100644
--- a/xen/arch/arm/vsmc.c
+++ b/xen/arch/arm/vsmc.c
@@ -25,6 +25,7 @@
  #include 
  #include 
  #include 
+#include 
  
  /* Number of functions currently supported by Hypervisor Service. */

  #define XEN_SMCCC_FUNCTION_COUNT 3
@@ -272,6 +273,9 @@ static bool vsmccc_handle_call(struct cpu_user_regs *regs)
  case ARM_SMCCC_OWNER_STANDARD:
  handled = handle_sssc(regs);
  break;
+case ARM_SMCCC_OWNER_SIP:
+handled = platform_smc(regs);
+break;
  }
  }
  
diff --git a/xen/include/asm-arm/platform.h b/xen/include/asm-arm/platform.h

index 2591d7b..dc55b6d 100644
--- a/xen/include/asm-arm/platform.h
+++ b/xen/include/asm-arm/platform.h
@@ -26,6 +26,8 @@ struct platform_desc {
  void (*reset)(void);
  /* Platform power-off */
  void (*poweroff)(void);
+/* Platform specific SMC handler */
+bool (*smc)(struct cpu_user_regs *regs);
  /*
   * Platform quirks
   * Defined has a function because a platform can support multiple
@@ -55,6 +57,7 @@ int platform_cpu_up(int cpu);
  #endif
  void platform_reset(void);
  void platform_poweroff(void);
+bool platform_smc(struct cpu_user_regs *regs);
  bool platform_has_quirk(uint32_t quirk);
  bool platform_device_is_blacklisted(const struct dt_device_node *node);
  



--
Julien Grall

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

Re: [Xen-devel] [PATCH v2] x86/hvm: Disallow moving the APIC MMIO window

[Jan Beulich]

>>> On 10.12.18 at 18:04,  wrote:
> See the code comment for a full discussion, but in short: guests which
> currently run under Xen don't move the window, because moving it has never
> worked properly.  Implementing support for moving the window is never going to
> work architecturally unless we switch to per-vcpu P2Ms (which seems very
> unlikely), and would still be a substantial quantity of work for a feature
> which is unused in practice.
> 
> Take the opportunity to rename vlapic_msr_set() to be consistent with the
> other MSR handling functions, and return X86EMUL_* constants.  Add logic to
> check for reserved bits, including refusing x2APIC mode if it has not been
> offered to the guest.  Move the guest_{rd,wr}msr_x2apic() declarations into
> vlapic.h which is a more appropriate place for them to live.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 



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

Re: [Xen-devel] [RFC 1/3] pvh: Add x86/HVM direct boot ABI header file

[Liam Merwick]

On 11/12/2018 14:01, Stefan Hajnoczi wrote:

On Wed, Dec 05, 2018 at 10:37:24PM +, Liam Merwick wrote:

From: Liam Merwick 

The x86/HVM direct boot ABI permits Qemu to be able to boot directly
into the uncompressed Linux kernel binary without the need to run firmware.

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

This commit adds the header file that defines the start_info struct
that needs to be populated in order to use this ABI.

Signed-off-by: Maran Wilson 
Signed-off-by: Liam Merwick 
Reviewed-by: Konrad Rzeszutek Wilk 
---
  include/hw/xen/start_info.h | 146 
  1 file changed, 146 insertions(+)
  create mode 100644 include/hw/xen/start_info.h


Does it make sense to bring in Linux
include/xen/interface/hvm/start_info.h via QEMU's
include/standard-headers/?

QEMU has a script in scripts/update-linux-header.sh for syncing Linux
headers into include/standard-headers/.  This makes it easy to keep
Linux header files up-to-date.  We basically treat files in
include/standard-headers/ as auto-generated.

If you define start_info.h yourself without using
include/standard-headers/, then it won't be synced with Linux.



That does seem better.  I will make that change.

One a related note, I'm trying to fix the mingw compilation errors [1] 
in this series also.  I can fix the format issues with PRIx64, etc but I 
can't seem to find an include file to provide a declaration of mmap() 
et. al. - has this been resolved before? A pointer to something similar 
to investigate would be very welcome.


Regards,
Liam

[1] 
http://patchew.org/logs/1544049446-6359-1-git-send-email-liam.merw...@oracle.com/testing.docker-mingw@fedora/?type=message


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

Re: [Xen-devel] [Qemu-devel] [RFC 1/3] pvh: Add x86/HVM direct boot ABI header file

[Daniel P . Berrangé]

On Tue, Dec 11, 2018 at 02:57:29PM +, Liam Merwick wrote:
> 
> 
> On 11/12/2018 14:01, Stefan Hajnoczi wrote:
> > On Wed, Dec 05, 2018 at 10:37:24PM +, Liam Merwick wrote:
> > > From: Liam Merwick 
> > > 
> > > The x86/HVM direct boot ABI permits Qemu to be able to boot directly
> > > into the uncompressed Linux kernel binary without the need to run 
> > > firmware.
> > > 
> > >   https://xenbits.xen.org/docs/unstable/misc/pvh.html
> > > 
> > > This commit adds the header file that defines the start_info struct
> > > that needs to be populated in order to use this ABI.
> > > 
> > > Signed-off-by: Maran Wilson 
> > > Signed-off-by: Liam Merwick 
> > > Reviewed-by: Konrad Rzeszutek Wilk 
> > > ---
> > >   include/hw/xen/start_info.h | 146 
> > > 
> > >   1 file changed, 146 insertions(+)
> > >   create mode 100644 include/hw/xen/start_info.h
> > 
> > Does it make sense to bring in Linux
> > include/xen/interface/hvm/start_info.h via QEMU's
> > include/standard-headers/?
> > 
> > QEMU has a script in scripts/update-linux-header.sh for syncing Linux
> > headers into include/standard-headers/.  This makes it easy to keep
> > Linux header files up-to-date.  We basically treat files in
> > include/standard-headers/ as auto-generated.
> > 
> > If you define start_info.h yourself without using
> > include/standard-headers/, then it won't be synced with Linux.
> > 
> 
> That does seem better.  I will make that change.
> 
> One a related note, I'm trying to fix the mingw compilation errors [1] in
> this series also.  I can fix the format issues with PRIx64, etc but I can't
> seem to find an include file to provide a declaration of mmap() et. al. -
> has this been resolved before? A pointer to something similar to investigate
> would be very welcome.

There is no mmap() on mingw, so you'll have to make sure that code is
conditionally compiled with  #ifndef WIN32 where appropriate.

> [1] 
> http://patchew.org/logs/1544049446-6359-1-git-send-email-liam.merw...@oracle.com/testing.docker-mingw@fedora/?type=message
> 

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

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

Re: [Xen-devel] [PATCH v5 2/7] xen/arm: zynqmp: Forward plaform specific firmware calls

[Julien Grall]

Hi Stefano,

On 03/12/2018 21:03, Stefano Stabellini wrote:

From: "Edgar E. Iglesias" 

From: Edgar E. Iglesias 

Introduce zynqmp_eemi: a function responsible for implementing access
controls over the firmware calls. Only calls that are allowed are
forwarded to the firmware.

Signed-off-by: Edgar E. Iglesias 
Signed-off-by: Stefano Stabellini 

---
Changes in v4:
- fix typo
- add header guard
- add emacs magic
- remove #includes that will only be used later
- add copyright notice to header
- remove SMCCC 1.1 check
---
  xen/arch/arm/platforms/Makefile|  1 +
  xen/arch/arm/platforms/xilinx-zynqmp-eemi.c| 34 ++
  xen/arch/arm/platforms/xilinx-zynqmp.c | 11 +++
  xen/include/asm-arm/platforms/xilinx-zynqmp-eemi.h | 30 +++
  4 files changed, 76 insertions(+)
  create mode 100644 xen/arch/arm/platforms/xilinx-zynqmp-eemi.c
  create mode 100644 xen/include/asm-arm/platforms/xilinx-zynqmp-eemi.h

diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile
index a79bdb9..fe8e0c7 100644
--- a/xen/arch/arm/platforms/Makefile
+++ b/xen/arch/arm/platforms/Makefile
@@ -9,3 +9,4 @@ obj-y += sunxi.o
  obj-$(CONFIG_ARM_64) += thunderx.o
  obj-$(CONFIG_ARM_64) += xgene-storm.o
  obj-$(CONFIG_MPSOC_PLATFORM)  += xilinx-zynqmp.o
+obj-$(CONFIG_MPSOC_PLATFORM)  += xilinx-zynqmp-eemi.o
diff --git a/xen/arch/arm/platforms/xilinx-zynqmp-eemi.c 
b/xen/arch/arm/platforms/xilinx-zynqmp-eemi.c
new file mode 100644
index 000..369bb3f
--- /dev/null
+++ b/xen/arch/arm/platforms/xilinx-zynqmp-eemi.c
@@ -0,0 +1,34 @@
+/*
+ * xen/arch/arm/platforms/xilinx-zynqmp-eemi.c
+ *
+ * Xilinx ZynqMP EEMI API
+ *
+ * Copyright (c) 2018 Xilinx Inc.
+ * Written by Edgar E. Iglesias 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms and conditions of the GNU General Public
+ * License, version 2, as published by the Free Software Foundation.
+ *
+ * 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.
+ */
+
+#include 
+#include 
+
+bool zynqmp_eemi(struct cpu_user_regs *regs)
+{
+return false;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/platforms/xilinx-zynqmp.c 
b/xen/arch/arm/platforms/xilinx-zynqmp.c
index d8ceded..9c174d2 100644
--- a/xen/arch/arm/platforms/xilinx-zynqmp.c
+++ b/xen/arch/arm/platforms/xilinx-zynqmp.c
@@ -18,6 +18,8 @@
   */
  
  #include 

+#include 
+#include 
  
  static const char * const zynqmp_dt_compat[] __initconst =

  {
@@ -32,8 +34,17 @@ static const struct dt_device_match zynqmp_blacklist_dev[] 
__initconst =
  { /* sentinel */ },
  };
  
+static bool zynqmp_smc(struct cpu_user_regs *regs)

+{
+if ( !is_64bit_domain(current->domain) )


Please document why you only expose eemi to 64-bit domain. What if the user 
start with 32-bit Dom0?



+return false;
+
+return  zynqmp_eemi(regs);


double space.


+}
+
  PLATFORM_START(xilinx_zynqmp, "Xilinx ZynqMP")
  .compatible = zynqmp_dt_compat,
+.smc = zynqmp_smc,
  .blacklist_dev = zynqmp_blacklist_dev,
  PLATFORM_END
  
diff --git a/xen/include/asm-arm/platforms/xilinx-zynqmp-eemi.h b/xen/include/asm-arm/platforms/xilinx-zynqmp-eemi.h

new file mode 100644
index 000..43cefb5
--- /dev/null
+++ b/xen/include/asm-arm/platforms/xilinx-zynqmp-eemi.h
@@ -0,0 +1,30 @@
+/*
+ * Copyright (c) 2018 Xilinx Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms and conditions of the GNU General Public
+ * License, version 2, as published by the Free Software Foundation.
+ *
+ * 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.
+ */
+
+#ifndef __ASM_ARM_PLATFORMS_ZYNQMP_H
+#define __ASM_ASM_PLATFORMS_ZYNQMP_H
+
+#include 
+
+extern bool zynqmp_eemi(struct cpu_user_regs *regs);
+
+#endif /* __ASM_ARM_PLATFORMS_ZYNQMP_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */



Cheers,

--
Julien Grall

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

Re: [Xen-devel] qemu assert in staging during HVM live migration

[Olaf Hering]

Am Fri, 23 Nov 2018 15:54:49 +
schrieb Anthony PERARD :

> On Thu, Nov 22, 2018 at 11:03:45AM +0100, Olaf Hering wrote:
> > qemu-system-i386: block/block-backend.c:903: blk_get_attached_dev_id: 
> > Assertion `!blk->legacy_dev' failed.
> xen-disk (qdisk) is currently using legacy stuff in QEMU, and this
> legacy stuff is going to disappear. Paul have a patch series to
> modernise it:

This assert triggers also without migration.

Do we want to get this fixed for qemu-3.1.0 and perhaps qemu-3.0.1, or shall we 
declare both broken until the mentioned series is eventually applied?

Olaf


pgpoTun_DGZP7.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 v2 1/2] x86/dom0: rename paging function

[Jan Beulich]

>>> On 05.12.18 at 15:54,  wrote:
> To note it's calculating the approximate amount of memory required by
> shadow paging.

I don't understand this logic, and ...

> @@ -325,7 +325,7 @@ unsigned long __init dom0_compute_nr_pages(
>  break;
>  
>  /* Reserve memory for shadow or HAP. */
> -avail -= dom0_paging_pages(d, nr_pages);
> +avail -= dom0_shadow_pages(d, nr_pages);
>  }

... the comment here (and lack of conditional restricting the
code to shadow mode) appear to support me: Have you
been mislead by the function having a comment referring
to libxl_get_required_shadow_memory()? I think if anything
that libxl function would want to be renamed (to replace
"shadow" by something more generic in its name).

Jan



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

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

[Anthony PERARD]

On Tue, Dec 11, 2018 at 10:47:03AM +, Paul Durrant wrote:
> 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 

Now we can add a xen-disk with vdev=xvdbgqcv :)

Reviewed-by: Anthony PERARD 

Thanks,

-- 
Anthony PERARD

___
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: improve paging memory usage calculations

[Jan Beulich]

>>> On 05.12.18 at 15:55,  wrote:
> +unsigned long __init dom0_hap_pages(const struct domain *d,
> +unsigned long nr_pages)
> +{
> +/*
> + * Attempt to account for at least some of the MMIO regions by adding the
> + * size of the holes in the memory map to the amount of pages to map. 
> Note
> + * this will obviously not account for MMIO regions that are past the 
> last
> + * RAM range in the memory map.
> + */
> +nr_pages += max_page - total_pages;
> +/*
> + * Approximate the memory required for the HAP/IOMMU page tables by
> + * pessimistically assuming each page will consume a 8 byte page table
> + * entry.
> + */
> +return DIV_ROUND_UP(nr_pages * 8, PAGE_SIZE << PAGE_ORDER_4K);

With enough memory handed to Dom0 the memory needed for
L2 and higher page tables will matter as well.

I'm anyway having difficulty seeing why HAP and shadow would
have to use different calculations, the more that shadow relies
on the same P2M code that shadow uses in the AMD/SVM case.

Plus, as iirc was said by someone else already, I don't think we
can (continue to) neglect the MMIO space needs for MMCFG
and PCI devices, especially with devices having multi-Gb BARs.

> +}
> +
> +

No double blank lines please.

> @@ -324,8 +342,13 @@ unsigned long __init dom0_compute_nr_pages(
>  if ( !need_paging )
>  break;
>  
> -/* Reserve memory for shadow or HAP. */
> -avail -= dom0_shadow_pages(d, nr_pages);
> +/* Reserve memory for CPU and IOMMU page tables. */
> +if ( paging_mode_hap(d) )
> +avail -= dom0_hap_pages(d, nr_pages) *
> + (iommu_hap_pt_share ? 1 : 2);

Use "<< !iommu_hap_pt_share" instead?

> +else
> +avail -= dom0_shadow_pages(d, nr_pages) +
> + dom0_hap_pages(d, nr_pages);
>  }

Doesn't dom0_shadow_pages() (mean to) already include the
amount needed for the P2M?

Jan



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

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

[Anthony PERARD]

On Tue, Dec 11, 2018 at 10:47:04AM +, Paul Durrant wrote:
> 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 
> ---
> 
> v3:
>  - Add transaction id parameters to xen-bus-helper functions
>  - Not added Anthony's R-b because of change
> 

Reviewed-by: Anthony PERARD 

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH v2 1/2] x86/dom0: rename paging function

[Roger Pau Monné]

On Tue, Dec 11, 2018 at 08:08:51AM -0700, Jan Beulich wrote:
> >>> On 05.12.18 at 15:54,  wrote:
> > To note it's calculating the approximate amount of memory required by
> > shadow paging.
> 
> I don't understand this logic, and ...
> 
> > @@ -325,7 +325,7 @@ unsigned long __init dom0_compute_nr_pages(
> >  break;
> >  
> >  /* Reserve memory for shadow or HAP. */
> > -avail -= dom0_paging_pages(d, nr_pages);
> > +avail -= dom0_shadow_pages(d, nr_pages);
> >  }
> 
> ... the comment here (and lack of conditional restricting the
> code to shadow mode) appear to support me: Have you
> been mislead by the function having a comment referring
> to libxl_get_required_shadow_memory()? I think if anything
> that libxl function would want to be renamed (to replace
> "shadow" by something more generic in its name).

But the logic in dom0_shadow_pages to calculate the size of the paging
memory pool is specifically for shadow AFAICT, I don't think HAP needs
to take the number of vCPUs into account, since there's only a
single p2m for the whole domain. OTOH shadow needs to take the number
of vCPUs into account because each one will have a different shadow.

Note that patch 2 in this series adds a function to calculate the size
of the paging memory pool for HAP, and a conditional is added to the
expression above that takes into account whether shadow or HAP is in
use when subtracting from the amount of available memory.

Thanks, Roger.

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

Re: [Xen-devel] [PATCH v5 3/7] xen/arm: zynqmp: introduce zynqmp specific defines

[Julien Grall]

Hi,

On 03/12/2018 21:03, Stefano Stabellini wrote:

From: "Edgar E. Iglesias" 

From: Edgar E. Iglesias 

Introduce zynqmp specific defines for the firmware calls.
See EEMI:
https://www.xilinx.com/support/documentation/user_guides/ug1200-eemi-api.pdf

The error codes are described, under XIlPM Error Codes:
https://www.xilinx.com/support/documentation/user_guides/ug1137-zynq-ultrascale-mpsoc-swdev.pdf

Signed-off-by: Edgar E. Iglesias 
Signed-off-by: Stefano Stabellini 

---

Although the amount of #defines has been significantly reduced in v5,
there is still a significant amount of static definitions:


I think the description below would be useful to have in the commit message.



- MM_*
These are the MMIO addresses of each resource to do permission checks.
Technically, they are also present on device tree, but using device tree
to get the mmio regions is not simple and not done in this series.
Xilinx plan to send a patch series in the future to extend the EEMI
functionalities and as part of that work, more device tree based
permission checking will be done, solving this problem.


As this is already present in the Device-Tree, there would be no issue to remove 
the hardcoded value, correct?



These
definitions could also be removed if we used a trivial "if dom0 -> yes,
otherwise no" permission checking.

- pm_api_id
These are the EEMI function IDs. Unavoidable.

- pm_ret_status
These are the EEMI return statuses. Unavoidable.

- pm_node_id
These are the EEMI function parameters for power management operations.
Today, it is not possible to get them from device tree as there is no
such information there. Even in the future when we add more power
domains info to device tree, the EEMI function parameters might remain
unique and different, requiring a table like this one.


Does it mean each Linux driver will have to hardcode the pm_node_id as well? 
What is the plan there?




- pm_reset
These are the EEMI function parameters for reset operations. Same as
pm_node_id.


Ditto.

Cheers,




---
Changes in v5:
- remove MMIO access related definitions

Changes in v4:
- define PM_MMIO_SHIFT
---
  xen/include/asm-arm/platforms/xilinx-zynqmp-eemi.h | 293 +
  1 file changed, 293 insertions(+)

diff --git a/xen/include/asm-arm/platforms/xilinx-zynqmp-eemi.h 
b/xen/include/asm-arm/platforms/xilinx-zynqmp-eemi.h
index 43cefb5..f6ad03b 100644
--- a/xen/include/asm-arm/platforms/xilinx-zynqmp-eemi.h
+++ b/xen/include/asm-arm/platforms/xilinx-zynqmp-eemi.h
@@ -16,6 +16,299 @@
  
  #include 
  
+#define MM_RPU	0xff9a0

+#define MM_RTC 0xffa60
+#define MM_ADMA_CH00xffa80
+
+#define MM_USB3_0_XHCI  0xfe200
+#define MM_USB3_1_XHCI  0xfe300
+
+#define MM_SATA_AHCI_HBA   0xfd0c0
+#define MM_AXIPCIE_MAIN0xfd0e0
+#define MM_CRF_APB 0xfd1a
+#define MM_PCIE_ATTRIB 0xfd480
+#define MM_DP  0xfd4a0
+#define MM_GPU 0xfd4b0
+#define MM_GDMA_CH00xfd500
+
+#define MM_UART0   0xff000
+#define MM_UART1   0xff010
+#define MM_I2C00xff020
+#define MM_I2C10xff030
+#define MM_SPI00xff040
+#define MM_SPI10xff050
+#define MM_CAN00xff060
+#define MM_CAN10xff070
+#define MM_GPIO0xff0a0
+#define MM_GEM00xff0b0
+#define MM_GEM10xff0c0
+#define MM_GEM20xff0d0
+#define MM_GEM30xff0e0
+#define MM_QSPI0xff0f0
+#define MM_NAND0xff100
+#define MM_TTC00xff110
+#define MM_TTC10xff120
+#define MM_TTC20xff130
+#define MM_TTC30xff140
+#define MM_SWDT0xff150
+#define MM_SD0 0xff160
+#define MM_SD1 0xff170
+
+/* Service calls.  */
+#define PM_GET_TRUSTZONE_VERSION   0xa03
+
+/* SMC function IDs for SiP Service queries */
+#define ZYNQMP_SIP_SVC_CALL_COUNT   0xff00
+#define ZYNQMP_SIP_SVC_UID  0xff01
+#define ZYNQMP_SIP_SVC_VERSION  0xff03


There are no need to define those. You can directly use ARM_SMCCC_CALL_* from 
asm-arm/smccc.h.



+
+#define PM_MMIO_SHIFT   32


You don't seem to use it at all. Did I miss anything?


+
+enum pm_api_id {
+   /* Miscellaneous API functions: */
+   PM_GET_API_VERSION = 1, /* Do not change or move */
+   PM_SET_CONFIGURATION,
+   PM_GET_NODE_STATUS,
+   PM_GET_OP_CHARACTERISTIC,
+   PM_REGISTER_NOTIFIER,
+   /* API for suspending of PUs: */
+   PM_REQ_SUSPEND,
+   PM_SELF_SUSPEND,
+   PM_FORCE_POWERDOWN,
+   PM_ABORT_SUSPEND,
+   PM_REQ_WAKEUP,
+   PM_SET_WAKEUP_SOURCE,
+   PM_SYSTEM_SHUTDOWN,
+   /* API for managing PM slaves: */
+   PM_REQ_NODE,
+   PM_RELEASE_NODE,
+   PM_SET_REQUIREMENT,
+   PM_SET_MAX_LATENCY,
+   /* Direct control API functions: */
+   PM_RESET_ASSERT,
+   PM_RESET_GET_STATUS,
+   PM_MMIO_WRITE,
+   PM_MMIO_READ,
+   PM_INIT,
+   PM_FPGA_LOAD,
+   PM_FPGA_GET_STATUS,
+   PM_GET_CHIPID,
+   /* ID 25 is been used by U-boot to process secure boot image

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

[Anthony PERARD]

On Tue, Dec 11, 2018 at 10:47:05AM +, Paul Durrant wrote:
> 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 

-- 
Anthony PERARD

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

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

[Anthony PERARD]

On Tue, Dec 11, 2018 at 10:47:07AM +, Paul Durrant wrote:
> 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: Stefano Stabellini 

When and where did this review happend? I can only find my review-by tag
on v2, which is missing here.

-- 
Anthony PERARD

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

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

[Anthony PERARD]

On Tue, Dec 11, 2018 at 10:47:09AM +, Paul Durrant wrote:
> v2:
>  - Leave existing boilerplate alone, other than removing the now-incorrect
>description
> ---
>  hw/block/dataplane/xen-block.c | 409 
> ++---
>  1 file changed, 16 insertions(+), 393 deletions(-)
> 
> diff --git a/hw/block/dataplane/xen-block.c b/hw/block/dataplane/xen-block.c
> index 9fae505..98f987d 100644
> --- a/hw/block/dataplane/xen-block.c
> +++ b/hw/block/dataplane/xen-block.c
> @@ -1,6 +1,4 @@
>  /*
> - *  xen paravirt block device backend
> - *
>   *  (c) Gerd Hoffmann 
>   *
>   *  This program is free software; you can redistribute it and/or modify
> @@ -19,26 +17,12 @@
>   *  GNU GPL, version 2 or (at your option) any later version.
>   */
>  
> +/*
> + * Copyright (c) 2018  Citrix Systems Inc.

Can you move this copyright line to the existing license boilerplate as
I've asked on v2?

> + *
> + * This work is licensed under the terms of the GNU GPL, version 2 or later.
> + * See the COPYING file in the top-level directory.

And this isn't needed as it just duplicate the already existing one.

> + */
>  

Thanks,

-- 
Anthony PERARD

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

[Xen-devel] memory leak in block/xen_disk in qemu-3.x

[Olaf Hering]

What are the live time rules of ioreq->buf?

In my testing the memory usage of qemu is constantly growing from about
250MB to several GB after a few days.

Some debugging shows that ioreq_runio_qemu_aio() overwrites ioreq->buf,
which contributes to the leak. In addition, ioreq_reset() also just
globbers iorew->buf. While this was observed with a backport of xen_disk
changes to qemu-2.9, the code in xen_disk.c did not change in this
regard. I changed the code to call qemu_vfree(ioreq->buf) in the few
places that globber the pointer, that fixes the leak for me.

Right now neither qemu-3.0 nor 3.1 for me, so I can not test
qemu.git#master if it eventually behaves different than
qemu.git#stable-2.9+backport.

Olaf


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

Re: [Xen-devel] [PATCH v2 1/2] x86/dom0: rename paging function

[Jan Beulich]

>>> On 11.12.18 at 16:19,  wrote:
> On Tue, Dec 11, 2018 at 08:08:51AM -0700, Jan Beulich wrote:
>> >>> On 05.12.18 at 15:54,  wrote:
>> > To note it's calculating the approximate amount of memory required by
>> > shadow paging.
>> 
>> I don't understand this logic, and ...
>> 
>> > @@ -325,7 +325,7 @@ unsigned long __init dom0_compute_nr_pages(
>> >  break;
>> >  
>> >  /* Reserve memory for shadow or HAP. */
>> > -avail -= dom0_paging_pages(d, nr_pages);
>> > +avail -= dom0_shadow_pages(d, nr_pages);
>> >  }
>> 
>> ... the comment here (and lack of conditional restricting the
>> code to shadow mode) appear to support me: Have you
>> been mislead by the function having a comment referring
>> to libxl_get_required_shadow_memory()? I think if anything
>> that libxl function would want to be renamed (to replace
>> "shadow" by something more generic in its name).
> 
> But the logic in dom0_shadow_pages to calculate the size of the paging
> memory pool is specifically for shadow AFAICT, I don't think HAP needs
> to take the number of vCPUs into account, since there's only a
> single p2m for the whole domain. OTOH shadow needs to take the number
> of vCPUs into account because each one will have a different shadow.

Yes, the vCPU count aspect is indeed shadow specific. However,
as said in reply to the other patch, the calculation here was at
least supposed to also take into account the P2M part of the
needed allocations. Yet the P2M part ought to be similar between
both modes.

> Note that patch 2 in this series adds a function to calculate the size
> of the paging memory pool for HAP, and a conditional is added to the
> expression above that takes into account whether shadow or HAP is in
> use when subtracting from the amount of available memory.

Well, assuming we can settle on what shape patch 2 should take
I can see the point in doing the rename here, but then with an
adjusted description: Especially in light of the code comment still
visible above you'll want to point out that the rename is in
preparation of splitting the calculations. Since I question the split,
though, the rename (in a separate patch) is questionable to me
too. If we used uniform P2M calculations and added just shadow's
per-vCPU extra on top, no rename in a separate patch would
seem warranted.

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: improve paging memory usage calculations

[Roger Pau Monné]

On Tue, Dec 11, 2018 at 08:19:34AM -0700, Jan Beulich wrote:
> >>> On 05.12.18 at 15:55,  wrote:
> > +unsigned long __init dom0_hap_pages(const struct domain *d,
> > +unsigned long nr_pages)
> > +{
> > +/*
> > + * Attempt to account for at least some of the MMIO regions by adding 
> > the
> > + * size of the holes in the memory map to the amount of pages to map. 
> > Note
> > + * this will obviously not account for MMIO regions that are past the 
> > last
> > + * RAM range in the memory map.
> > + */
> > +nr_pages += max_page - total_pages;
> > +/*
> > + * Approximate the memory required for the HAP/IOMMU page tables by
> > + * pessimistically assuming each page will consume a 8 byte page table
> > + * entry.
> > + */
> > +return DIV_ROUND_UP(nr_pages * 8, PAGE_SIZE << PAGE_ORDER_4K);
> 
> With enough memory handed to Dom0 the memory needed for
> L2 and higher page tables will matter as well.

The above calculation assumes all chunks will be mapped as 4KB
entries, but this is very unlikely, so there's some room for higher
page tables. If that doesn't seem enough I can add some extra space
here, maybe a +5% or +10%?

> I'm anyway having difficulty seeing why HAP and shadow would
> have to use different calculations, the more that shadow relies
> on the same P2M code that shadow uses in the AMD/SVM case.

For once shadow needs to take the number of vCPUs into account while
HAP doesn't.

> Plus, as iirc was said by someone else already, I don't think we
> can (continue to) neglect the MMIO space needs for MMCFG
> and PCI devices, especially with devices having multi-Gb BARs.

Well, there's the comment above that notes this approach only takes
into account the holes in the memory map as regions to be mapped. This
can be improved later on, but I think the important point here is to
know where this numbers come from in order to tweak it in the future.

> > +else
> > +avail -= dom0_shadow_pages(d, nr_pages) +
> > + dom0_hap_pages(d, nr_pages);
> >  }
> 
> Doesn't dom0_shadow_pages() (mean to) already include the
> amount needed for the P2M?

libxl code mentions: "plus 1 page per MiB of RAM for the P2M map," so
I guess the shadow calculation takes into account the memory used by
the IOMMU page tables?

Thanks, Roger.

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

Re: [Xen-devel] [PATCH v5 5/7] xen/arm: zynqmp: eemi access control

[Julien Grall]

Hi,

On 03/12/2018 21:03, Stefano Stabellini wrote:

From: "Edgar E. Iglesias" 

From: Edgar E. Iglesias 

Introduce data structs to implement basic access controls.
Introduce the following three functions:

domain_has_node_access: check access to the node
domain_has_reset_access: check access to the reset line
domain_has_mmio_access: check access to the register

Signed-off-by: Edgar E. Iglesias 
Signed-off-by: Stefano Stabellini 

---
Statically defines:

- pm_node_access
It encodes the relationship between a node id and the start of the MMIO
region of a device in the corresponding power domain. It is used for
permission checking. Although the MMIO region start address is available
on device tree and could be derived from there (we plan to improve that
in the future), the relationship between a node id and corresponding
devices is not described and needs to be hardcoded.

- pm_reset_access
Same as pm_node_access for reset lines.

---
Changes in v5:
- improve in-code comments
- use mfn_t in struct pm_access
- remove mmio_access table

Changes in v4:
- add #include as needed
- add #if 0 for bisectability
- use mfn_t in pm_check_access
- add wrap-around ASSERT in domain_has_mmio_access
- use GENMASK in domain_has_mmio_access
- proper bound checks (== ARRAY_SIZE is out of bound)
---
  xen/arch/arm/platforms/xilinx-zynqmp-eemi.c | 348 
  1 file changed, 348 insertions(+)

diff --git a/xen/arch/arm/platforms/xilinx-zynqmp-eemi.c 
b/xen/arch/arm/platforms/xilinx-zynqmp-eemi.c
index 369bb3f..92a02df 100644
--- a/xen/arch/arm/platforms/xilinx-zynqmp-eemi.c
+++ b/xen/arch/arm/platforms/xilinx-zynqmp-eemi.c
@@ -16,9 +16,357 @@
   * GNU General Public License for more details.
   */
  
+/*

+ *  EEMI Power Management API access
+ *
+ * Refs:
+ * https://www.xilinx.com/support/documentation/user_guides/ug1200-eemi-api.pdf
+ *
+ * Background:
+ * The ZynqMP has a subsystem named the PMU with a CPU and special devices
+ * dedicated to running Power Management Firmware. Other masters in the
+ * system need to send requests to the PMU in order to for example:
+ * * Manage power state
+ * * Configure clocks
+ * * Program bitstreams for the programmable logic
+ * * etc
+ *
+ * Although the details of the setup are configurable, in the common case
+ * the PMU lives in the Secure world. NS World cannot directly communicate
+ * with it and must use proxy services from ARM Trusted Firmware to reach
+ * the PMU.
+ *
+ * Power Management on the ZynqMP is implemented in a layered manner.
+ * The PMU knows about various masters and will enforce access controls
+ * based on a pre-configured partitioning. This configuration dictates
+ * which devices are owned by the various masters and the PMU FW makes sure
+ * that a given master cannot turn off a device that it does not own or that
+ * is in use by other masters.
+ *
+ * The PMU is not aware of multiple execution states in masters.
+ * For example, it treats the ARMv8 cores as single units and does not
+ * distinguish between Secure vs NS OS's nor does it know about Hypervisors
+ * and multiple guests. It is up to software on the ARMv8 cores to present
+ * a unified view of its power requirements.
+ *
+ * To implement this unified view, ARM Trusted Firmware at EL3 provides
+ * access to the PM API via SMC calls. ARM Trusted Firmware is responsible
+ * for mediating between the Secure and the NS world, rejecting SMC calls
+ * that request changes that are not allowed.
+ *
+ * Xen running above ATF owns the NS world and is responsible for presenting
+ * unified PM requests taking all guests and the hypervisor into account.
+ *
+ * Implementation:
+ * The PM API contains different classes of calls.
+ * Certain calls are harmless to expose to any guest.
+ * These include calls to get the PM API Version, or to read out the version
+ * of the chip we're running on.
+ *
+ * In order to correctly virtualize these calls, we need to know if
+ * guests issuing these calls have ownership of the given device.
+ * The approach taken here is to map PM API Nodes identifying
+ * a device into base addresses for registers that belong to that
+ * same device.
+ *
+ * If the guest has access to devices registers, we give the guest
+ * access to PM API calls that affect that device. This is implemented
+ * by pm_node_access and domain_has_node_access().
+ */
+
+#include 
+#include 
  #include 
  #include 
  
+#if 0

+struct pm_access
+{
+mfn_t mfn;
+bool hwdom_access;/* HW domain gets access regardless.  */
+};
+
+/*
+ * This table maps a node into a memory address.


Some of the nodes below don't have memory address. So this comment has to be 
updated.



+ * If a guest has access to the address, it has enough control
+ * over the node to grant it access to EEMI calls for that node.
+ */
+static const struct pm_access pm_node_access[] = {
+/* MM_RPU grants access to all RPU Nodes.  */
+[NODE_RPU] = { mfn_init(MM_RPU) },
+[NODE_RPU_0] = { mfn_init(

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

[Paul Durrant]

> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 11 December 2018 15:30
> To: Paul Durrant 
> Cc: qemu-de...@nongnu.org; qemu-bl...@nongnu.org; xen-
> de...@lists.xenproject.org; Kevin Wolf ; Stefano
> Stabellini ; Stefan Hajnoczi
> ; Max Reitz 
> Subject: Re: [Xen-devel] [PATCH v3 09/18] xen: remove unnecessary code
> from dataplane/xen-block.c
> 
> On Tue, Dec 11, 2018 at 10:47:09AM +, Paul Durrant wrote:
> > v2:
> >  - Leave existing boilerplate alone, other than removing the now-
> incorrect
> >description
> > ---
> >  hw/block/dataplane/xen-block.c | 409 ++
> ---
> >  1 file changed, 16 insertions(+), 393 deletions(-)
> >
> > diff --git a/hw/block/dataplane/xen-block.c b/hw/block/dataplane/xen-
> block.c
> > index 9fae505..98f987d 100644
> > --- a/hw/block/dataplane/xen-block.c
> > +++ b/hw/block/dataplane/xen-block.c
> > @@ -1,6 +1,4 @@
> >  /*
> > - *  xen paravirt block device backend
> > - *
> >   *  (c) Gerd Hoffmann 
> >   *
> >   *  This program is free software; you can redistribute it and/or
> modify
> > @@ -19,26 +17,12 @@
> >   *  GNU GPL, version 2 or (at your option) any later version.
> >   */
> >
> > +/*
> > + * Copyright (c) 2018  Citrix Systems Inc.
> 
> Can you move this copyright line to the existing license boilerplate as
> I've asked on v2?
> 

Oops. I thought I'd done this.

> > + *
> > + * This work is licensed under the terms of the GNU GPL, version 2 or
> later.
> > + * See the COPYING file in the top-level directory.
> 
> And this isn't needed as it just duplicate the already existing one.
> 

Sure. I'll send v4 with both these fixed.

  Paul

> > + */
> >
> 
> Thanks,
> 
> --
> Anthony PERARD

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

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

[Paul Durrant]

> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 11 December 2018 15:17
> To: Paul Durrant 
> Cc: qemu-de...@nongnu.org; qemu-bl...@nongnu.org; xen-
> de...@lists.xenproject.org; Kevin Wolf ; Max Reitz
> ; Stefano Stabellini 
> Subject: Re: [PATCH v3 03/18] xen: introduce 'xen-block', 'xen-disk' and
> 'xen-cdrom'
> 
> On Tue, Dec 11, 2018 at 10:47:03AM +, Paul Durrant wrote:
> > 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 
> 
> Now we can add a xen-disk with vdev=xvdbgqcv :)

Yep, you can keep going until xenstore explodes :-)

  Paul

> 
> Reviewed-by: Anthony PERARD 
> 
> Thanks,
> 
> --
> Anthony PERARD

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

Re: [Xen-devel] [PATCH v10] new config option vtsc_tolerance_khz to avoid TSC emulation

[Olaf Hering]

On Fri, Dec 07, Olaf Hering wrote:

> [ the math added to xen-tscmode.7 suggests that a domU should see a time
>   drift, which ntpd corrects. But the actual correction reported in
>   ntp.drift is entirely different than the one calculated in the
>   example. To me it is unclear why the example is wrong, more research
>   must be done. I'm sending this out just to get feedback about how
>   exactly the per-host knob must be implemented. ]
> 
> Add a knob to control when vTSC emulation will be activated for a domU
> with tsc_mode=default. Without such option each TSC access from domU
> will be emulated, which causes a significant perfomance drop for
> workloads that make use of rdtsc.

I wonder why this needs to be a config option at all.


I think that if a domU uses TSC as clocksoure it also must run NTP in
some way to avoid the potential drift what will most likely happen,
independent of any migration. And if it must do that, NTP will handle a
drift up to 500 PPM. This means 500us. But if a domU is moved from a
2.3GHz host to a 2.4GHz host the expected drift is much larger. The
clock will run slower, the amount of ticks representing a second happen
within a timespan of 0.958333 seonds. Adding the drift to that number
means an NTPd could correct up to 0.958833 seconds. This is out of
bounds either way.

If Xen already bases its decision to emulate TSC on bogus numbers,
shouldnt it automatically allow some tolerance for tsc_mode=default?
Xen itself can not know if the estimated value in cpu_khz is at the edge
or in the middle of the range of possible freqencies. If we assume the
total range is 200 KHz, and up to 500 PPM can be corrected, a possible
default tolerance would be like: [insert math here]


So I think the suggested vtsc_tolerance_khz should in fact add a local
static vtsc_tolerance_khz into xen/arch/x86/time.c, and tsc_set_info
should base the decision on this variable like it is already done in the
suggested patch. No admin tuning of this value is required IMO.

Olaf


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

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

[Paul Durrant]

> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 11 December 2018 15:25
> To: Paul Durrant 
> Cc: qemu-de...@nongnu.org; qemu-bl...@nongnu.org; xen-
> de...@lists.xenproject.org
> Subject: Re: [PATCH v3 07/18] xen: add event channel interface for
> XenDevice-s
> 
> On Tue, Dec 11, 2018 at 10:47:07AM +, Paul Durrant wrote:
> > 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: Stefano Stabellini 
> 
> When and where did this review happend? I can only find my review-by tag
> on v2, which is missing here.
> 

Oh, that must have been my mistake... I cut'n'pasted the wrong line. Apologies 
to Stefano and yourself... I'll fix it in v4.

  Paul

> --
> Anthony PERARD

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

Re: [Xen-devel] [PATCH v5 6/7] xen/arm: zynqmp: implement zynqmp_eemi

[Julien Grall]

Hi Stefano,

On 03/12/2018 21:03, Stefano Stabellini wrote:

From: "Edgar E. Iglesias" 

From: Edgar E. Iglesias 

zynqmp_eemi uses the defined functions and structs to decide whether to
make a call to the firmware, or to simply return a predefined value.

Signed-off-by: Edgar E. Iglesias 
Signed-off-by: Stefano Stabellini 
---
Changes in v5:
- remove mmio_access handling

Changes in v4:
- add #include as needed
- improve comment
- code style
---
  xen/arch/arm/platforms/xilinx-zynqmp-eemi.c | 181 +++-
  1 file changed, 125 insertions(+), 56 deletions(-)

diff --git a/xen/arch/arm/platforms/xilinx-zynqmp-eemi.c 
b/xen/arch/arm/platforms/xilinx-zynqmp-eemi.c
index 92a02df..9ecf286 100644
--- a/xen/arch/arm/platforms/xilinx-zynqmp-eemi.c
+++ b/xen/arch/arm/platforms/xilinx-zynqmp-eemi.c
@@ -76,10 +76,10 @@
  
  #include 

  #include 
+#include 
  #include 
  #include 
  
-#if 0

  struct pm_access
  {
  mfn_t mfn;
@@ -309,67 +309,136 @@ static bool domain_has_reset_access(struct domain *d, 
uint32_t rst)
  return pm_check_access(pm_reset_access, d, rst);
  }
  
-/*

- * Check if a given domain has access to perform an indirect
- * MMIO access.
- *
- * If the provided mask is invalid, it will be fixed up.
- */
-static bool domain_has_mmio_access(struct domain *d,
-   bool write, paddr_t addr,
-   uint32_t *mask)


Why do you remove code that you just introduced?


+bool zynqmp_eemi(struct cpu_user_regs *regs)
  {
-unsigned int i;
-bool ret = false;
-uint32_t prot_mask = 0;
-
-/*
- * The hardware domain gets read access to everything.
- * Lower layers will do further filtering.
- */
-if ( !write && is_hardware_domain(d) )
-return true;
+struct arm_smccc_res res;
+uint32_t fid = get_user_reg(regs, 0);
+uint32_t nodeid = get_user_reg(regs, 1);


You didn't address my concern regarding SMC32 vs SMC64 convention. As I said 
earlier on, at least CALL_COUNT, UID and VERSION are only accessible using the 
SMC32 convention.


I can't tell for the other as the EEMI spec does not seem to specify it. I would 
be surprised that EEMI would  ignore tops bits of the ID given they convey 
different information (e.g  fast/yielding call, 32/64-bit convention).


Looking at the branch you mentioned earlier on, zynqmp_pm_invoke_fn
(drivers/firmware/xilinx/zynqmp.c) is definitely using the SMC64 calling
convention as described in the documentation above the function.

So this needs to be fixed properly.



+unsigned int pm_fn = fid & 0x;
+enum pm_ret_status ret;
  
-/* Scan the ACL.  */

-for ( i = 0; i < ARRAY_SIZE(pm_mmio_access); i++ )
+switch ( pm_fn )
  {
-ASSERT(pm_mmio_access[i].start + pm_mmio_access[i].size >=
-   pm_mmio_access[i].start);
-
-if ( addr < pm_mmio_access[i].start )
-return false;
-if ( addr >= pm_mmio_access[i].start + pm_mmio_access[i].size )
-continue;
-
-if ( write && pm_mmio_access[i].readonly )
-return false;
-if ( pm_mmio_access[i].hwdom_access && !is_hardware_domain(d) )
-return false;
-if ( !domain_has_node_access(d, pm_mmio_access[i].node) )
-return false;
-
-/* We've got access to this reg (or parts of it).  */
-ret = true;
-
-/* Permit write access to selected bits.  */
-prot_mask |= pm_mmio_access[i].mask ?: GENMASK(31, 0);
-break;
-}
-
  /*
- * Masking only applies to writes: values are safe to read, but not
- * all bits are writeable.
+ * We can't allow CPUs to suspend without Xen knowing about it.
+ * We accept but ignore the request and wait for the guest to issue
+ * a WFI or PSCI call which Xen will trap and act accordingly upon.
   */
-if ( write )
-*mask &= prot_mask;
-
-return ret;
-}
-#endif
+case PM_SELF_SUSPEND:
+ret = XST_PM_SUCCESS;
+goto done;
+
+case PM_GET_NODE_STATUS:
+/* API for PUs.  */
+case PM_REQ_SUSPEND:
+case PM_FORCE_POWERDOWN:
+case PM_ABORT_SUSPEND:
+case PM_REQ_WAKEUP:
+case PM_SET_WAKEUP_SOURCE:
+/* API for slaves.  */
+case PM_REQ_NODE:
+case PM_RELEASE_NODE:
+case PM_SET_REQUIREMENT:
+case PM_SET_MAX_LATENCY:
+if ( !domain_has_node_access(current->domain, nodeid) )
+{
+gprintk(XENLOG_WARNING,
+"zynqmp-pm: fn=%u No access to node %u\n", pm_fn, nodeid);
+ret = XST_PM_NO_ACCESS;
+goto done;
+}
+goto forward_to_fw;
+
+case PM_RESET_ASSERT:
+case PM_RESET_GET_STATUS:
+if ( !domain_has_reset_access(current->domain, nodeid) )
+{
+gprintk(XENLOG_WARNING,
+"zynqmp-pm: fn=%u No access to reset %u\n", pm_fn, nodeid);
+ret = XST_PM_NO_ACCESS;
+goto done;
+}
+

[Xen-devel] [PATCH v4 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/qom29

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   |   11 +
 hw/block/xen-block.c|  847 +
 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|   69 ++
 hw/xen/xen-bus-helper.c |  184 ++
 hw/xen/xen-bus.c| 1189 +++
 hw/xen/xen-common.c |2 +-
 hw/xen/xen-legacy-backend.c |  853 +
 hw/xen/xen_backend.c|  845 -
 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|   26 +
 include/hw/xen/xen-block.h  |   79 +++
 include/hw/xen/xen-bus-helper.h |   45 ++
 include/hw/xen/xen-bus.h|  138 
 include/hw/xen/xen-legacy-backend.h |  104 +++
 include/hw/xen/xen_backend.h|   99 ---
 include/hw/xen/xen_pvdev.h  |   38 +-
 include/qemu/module.h   |3 +
 40 files changed, 4512 insertions(+), 2042 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
 create mode 100644 hw/xen/xen-legacy-backend.c
 delete mode 100644 hw/xen/xen_backend.c
 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
 create mode 100644 include/hw/xen/xen-legacy-backend.h
 delete mode 100644 include/hw/xen/xen_backend.h
---
Cc: Anthony Perard 
Cc: Eduardo Habkost 
Cc: Gerd Hoffmann 
Cc: Greg Kurz 
Cc: Jason Wang 
Cc: Kevin Wolf 
Cc: "Marc-André Lureau" 
Cc: Marcel Apf

[Xen-devel] [PATCH v4 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 faa9fd3..9443f27 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(&xendev->event_notifiers, &channel->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(&channel->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), &error_abort);
 }
 
+static void xen_device_event(void *opaque)
+{
+XenDevice *xendev = opaque;
+unsigned long port = xenevtchn_pending(xendev->xeh);
+
+notifier_list_notify(&xendev->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(&xendev->event_notifiers);
+qemu_set_fd_handler(xenevtchn_fd(xendev->xeh), xen_device_event, NULL,
+xendev);
+
 xen_device_backend_create(xendev, &local_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 63a09b6..f83a95c 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;
+ 

[Xen-devel] [PATCH v4 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 

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 4afbd62..89e2583 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 fa57bf1..5932672 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 = &blockdev->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 = &blockdev->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, &local_err);
+if (local_err) {
+error_propagate(errp, local_err);
+break;
+}
+
+xen_block_connect(xendev, &local_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, &local_err);
+if (local_err) {
+error_propagate(errp, local_err);
+break;
+}
+
+xen_device_backend_set_state(xendev, XenbusStateClose

[Xen-devel] [PATCH v4 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 1d63763..4497f75 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"
@@ -1479,6 +1480,8 @@ void xen_hvm_init(PCMachineState *pcms, MemoryRegion 
**ram_memory)
 QLIST_INIT(&state->dev_list);
 device_listener_register(&state->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 3f64a44..d9d6d7b 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 c7e7a3b..0172cd4 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 000..bc04da7
--- /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) {
+xendev_class->realize(

[Xen-devel] [PATCH v4 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 

v4:
 - Fix boilerplate

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

diff --git a/hw/block/dataplane/xen-block.c b/hw/block/dataplane/xen-block.c
index 9fae505..975a018 100644
--- a/hw/block/dataplane/xen-block.c
+++ b/hw/block/dataplane/xen-block.c
@@ -1,6 +1,5 @@
 /*
- *  xen paravirt block device backend
- *
+ *  Copyright (c) 2018  Citrix Systems Inc.
  *  (c) Gerd Hoffmann 
  *
  *  This program is free software; you can redistribute it and/or modify
@@ -19,27 +18,6 @@
  *  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(&ioreq->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 (ioreq->req.seg[i].first_sect > ioreq->req.seg[i].last_sect) {
-xen_pv_printf(xendev, 0, "error: first > last sector\n");
+error_report("error: first > last sector");
 goto err;
 }
 if (ioreq->req.seg[i].last_sect * BLOCK_SIZE >= XC_PAGE_SIZE) {
-xen_pv_printf(xendev, 0, "error: page crossing\n");
+error_report("error: page crossing");
 goto err;
 }
 
@@ -232,7 +202,7 @@ static int ioreq_parse(struct ioreq *ioreq)
 ioreq->size += len;
 }
 if (ioreq->start + ioreq->size > blkdev->file_size) {
-xen_pv_printf(xendev, 0, "error: access beyond end of file\n");
+error_report("error: access beyond end of file");
 goto err;
 }
 return 0;
@@ -278,8 +248,7 @@ static int ioreq_grant_copy(struct ioreq *ioreq)
 rc = xen_be_copy_grant_refs(xendev, to_domain, segs, count);
 
 if (rc) {
-xen_pv_printf(xendev, 0,
-  "failed to copy data %d\n", rc);
+error_report("failed to copy data %d", rc);
 ioreq->aio_errors++;
 return -1;
 }
@@ -298,8 +267,9 @@ static void qemu_aio_complete(void *opaque, int ret)
 aio_context_acquire(blkdev->ctx);
 
 if (ret != 0) {
-xen_pv_printf(xendev, 0, "%s I/O error\n",
-  ioreq->req.operation == BLKIF_OP_READ ? "read" : 
"write");
+error_report("%s I/O error",
+

[Xen-devel] [PATCH v4 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 5e19592..faa9fd3 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 = &segs[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 = &segs[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 = &segs[i];
+xengnttab_grant_copy_segment_t *xengnttab_seg = &xengnttab_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 = &xengnttab_segs[i];
+
+if (xengntta

[Xen-devel] [PATCH v4 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 

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 |  69 +
 5 files changed, 422 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 63effdc..dd728c3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -403,7 +403,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 53ce575..f34813a 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 335c092..4afbd62 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 000..c29acb0
--- /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 = &blockdev->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 = &blockdev->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) {
+blockdev_class->realize(blockdev, &local_err);
+if (local_err) {
+error_propagate(errp, local_err);
+}
+}
+}
+
+stati

[Xen-devel] [PATCH v4 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 

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 c29acb0..fa57bf1 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 = &blockdev->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 d9d6d7b..77c0868 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 0172cd4..75dc226 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 000..15b3ad8
--- /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),
+XS_STATE(XenbusStateInitialis

[Xen-devel] [PATCH v4 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 dd728c3..ab62ad4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -404,6 +404,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 000..9fae505
--- /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(&ioreq->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(&ioreq->list, 0, sizeof(ioreq->list));
+memset(&ioreq->acct, 0, sizeof(ioreq->acct))

[Xen-devel] [PATCH v4 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 +-
 hw/xen/xen-legacy-backend.c | 854 
 hw/xen/xen_backend.c| 845 ---
 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 +-
 include/hw/xen/xen-legacy-backend.h | 104 +
 include/hw/xen/xen_backend.h|  99 -
 include/hw/xen/xen_pvdev.h  |  38 +-
 24 files changed, 1059 insertions(+), 1041 deletions(-)
 create mode 100644 hw/xen/xen-legacy-backend.c
 delete mode 100644 hw/xen/xen_backend.c
 create mode 100644 include/hw/xen/xen-legacy-backend.h
 delete mode 100644 include/hw/xen/xen_backend.h

diff --git a/hw/9pfs/xen-9p-backend.c b/hw/9pfs/xen-9p-backend.c
index 3f54a21..3859a06 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 36eff94..75fe55f 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 ioreq {
 #define MAX_RING_PAGE_OR

[Xen-devel] [PATCH v4 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 ab62ad4..9875581 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -408,6 +408,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 e786f66..c6c68db 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 975a018..ddda264 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 = &blkdev->xendev;
 size_t len;
 int i;
 
@@ -177,7 +164,8 @@ static int ioreq_parse(struct ioreq *ioreq)
 goto err;
 };
 
-

[Xen-devel] [PATCH v4 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 
---
Cc: Stefano Stabellini 
Cc: Anthony Perard 
Cc: Kevin Wolf 
Cc: Max Reitz 

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 5932672..f3d21c6 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 = &blockdev->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 = &blockdev->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",
+  &order) != 1) {
+nr_ring_ref = 1;
+ring_ref = g_new(unsigned int, nr_ring_ref);
+
+if (xen_device_frontend_scanf(xendev, "ring-ref", "%u",
+  &ring_ref[0]) != 1) {
+error_setg(errp, "failed to read ring-ref");
+g_free(ring_ref);
+return;
+}
+} else if (order <= blockdev->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",
+  &ring_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",
+  &event_channel) != 1) {
+error_setg(errp, "failed to read event-channel");
+g_free(ring_ref);
+return;
+}
+
+if (xen_device_frontend_scanf(xendev, "protocol", "%ms",
+  &str) != 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);
 }
@@ -69,6 +144,7 @@ static void xen_block_realize(XenDevic

[Xen-devel] [PATCH v4 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 9875581..e6bd441 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -396,6 +396,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.1.4


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

[Xen-devel] [PATCH v4 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 a creator function to be called when a tool-
stack instantiates a new backend in this way.

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 
---
Cc: Anthony Perard 
Cc: Stefano Stabellini 
Cc: Anthony Perard 

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 |  69 +++
 hw/xen/xen-bus.c | 154 +++
 include/hw/xen/xen-backend.h |  26 
 include/hw/xen/xen-bus.h |   1 +
 include/qemu/module.h|   3 +
 7 files changed, 257 insertions(+), 1 deletion(-)
 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 77c0868..84df60a 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 d4651bd..f694462 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 000..d87e6ec
--- /dev/null
+++ b/hw/xen/xen-backend.c
@@ -0,0 +1,69 @@
+/*
+ * 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 "hw/xen/xen-backend.h"
+
+typedef struct XenBackendImpl {
+const char *type;
+XenBackendDeviceCreate create;
+} XenBackendImpl;
+
+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 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;
+
+xen_backend_table_add(impl);
+}
+
+void xen_backend_device_create(BusState *bus, const char *type,
+   const char *name, QDict *opts, Error **errp)
+{
+XenBackendImpl *impl = xen_backend_table_lookup(type);
+
+if (impl) {
+impl->create(bus, name, opts, errp);
+}
+}
diff --git a/hw/xen/xen-bus.c b/hw/xen/xen-bus.c
index a22aa49..7593d61 100644
--- a/hw/xen/xen-bus.c
+++ b/hw/xen/xen-bus.c
@@ -11,10 +11,12 @@
 #include "hw/hw.h"
 #include "hw/sysbus.h"
 #include "hw/xen/xen.h"
+#include "hw/xen/xen-backend.h"
 #include "hw/xen/xen-bus.h"
 #include "hw/xen/xen-bus-helper.h"
 #include "monitor/monito