Re: [Xen-devel] Interrupt injection with ISR set on Intel hardware
> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Thursday, October 25, 2018 9:58 PM > > >>> On 25.10.18 at 15:02, wrote: > > On 25/10/18 13:51, Jan Beulich wrote: > > On 15.10.18 at 14:06, wrote: > >>> From the debugging, we see that PPR/IRR/ISR appear to retain their > state > >>> across the mwait, and there is nothing in the manual which I can see > >>> discussing the interaction of LAPIC state and C states. > >> Is it perhaps a bad idea to go idle with an un-acked interrupt? > > > > Most likely. > > > > Then again, going idle with an un-acked line interrupt does appear to > > work. It is only un-acked edge interrupts which appear to hit this issue. > > Well, non-maskable MSI are the only ones (outside of "new" IO-APIC > ack mode, which should not be used on recent hardware because of > directed EOI presumably being available everywhere) where the ack > gets deferred until the .end hook (i.e. after the handler was run). > IOW AFAICT line interrupts would never be pending when we go idle. > > > Still - I'd prefer some guidance from the hardware folk as to what can > > realistically be expected here. > > Fully agree. Just sent a mail internally to get clarification. Thanks Kevin ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen-blkfront: fix kernel panic with negotiate_mq error path
On 29/10/2018 19:31, Manjunath Patil wrote:
> info->nr_rings isn't adjusted in case of ENOMEM error from
> negotiate_mq(). This leads to kernel panic in error path.
>
> Typical call stack involving panic -
> #8 page_fault at 8175936f
> [exception RIP: blkif_free_ring+33]
> RIP: a0149491 RSP: 8804f7673c08 RFLAGS: 00010292
> ...
> #9 blkif_free at a0149aaa [xen_blkfront]
> #10 talk_to_blkback at a014c8cd [xen_blkfront]
> #11 blkback_changed at a014ea8b [xen_blkfront]
> #12 xenbus_otherend_changed at 81424670
> #13 backend_changed at 81426dc3
> #14 xenwatch_thread at 81422f29
> #15 kthread at 810abe6a
> #16 ret_from_fork at 81754078
>
> Though either of my changes avoid the panic, I included both the
> changes. This issue got introduced with "7ed8ce1 xen-blkfront: move
> negotiate_mq to cover all cases of new VBDs"
Please us the correct format for specifying another commit.
> Signed-off-by: Manjunath Patil
Can you please add a "Fixes:" tag and "Cc: sta...@vger.kernel.org" ?
> ---
> drivers/block/xen-blkfront.c |7 +--
> 1 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 429d201..dc8fe25 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -1350,8 +1350,10 @@ static void blkif_free(struct blkfront_info *info, int
> suspend)
> if (info->rq)
> blk_mq_stop_hw_queues(info->rq);
>
> - for (i = 0; i < info->nr_rings; i++)
> - blkif_free_ring(&info->rinfo[i]);
> + if (info->rinfo) {
> + for (i = 0; i < info->nr_rings; i++)
> + blkif_free_ring(&info->rinfo[i]);
> + }
I'd drop this change.
>
> kfree(info->rinfo);
> info->rinfo = NULL;
> @@ -1919,6 +1921,7 @@ static int negotiate_mq(struct blkfront_info *info)
> GFP_KERNEL);
> if (!info->rinfo) {
> xenbus_dev_fatal(info->xbdev, -ENOMEM, "allocating ring_info
> structure");
> + info->nr_rings = 0;
> return -ENOMEM;
> }
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/4] x86/vvmx: Unconditionally initialise vmxon_region_pa during vcpu construction
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Thursday, October 25, 2018 11:37 PM > > This is a stopgap solution until the toolstack side of initialisation can be > sorted out, but it does result in the nvmx_vcpu_in_vmx() predicate working > correctly even when nested virt hasn't been enabled for the domain. > > Update nvmx_handle_vmx_insn() to include the in-vmx mode check (for all > instructions other than VMXON) to complete the set of #UD checks. > > In addition, sanity check that the nested vmexit handler has worked > correctly, > and that we are only providing emulation of the VT-x instructions to L1 > guests. > > Signed-off-by: Andrew Cooper Acked-by: Kevin Tian ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [Xen-users] [XEN][ARM] WiFi bridge creation
On Tue, 30 Oct 2018 10:03:22 +0530 Vikram K wrote: > Hello, > We are using Hikey960 with Debian as Dom0 and DomU. This board has only > WiFi interface. We want to create bridge between Dom0 and DomU so that DomU > has internet access. We tried to create bridge using brtcl command, but it > is not working. Please provide pointers. AFAIK, it's not working https://marc.info/?l=linux-wireless&m=136743495526905&w=2 "There is a proposed fix that is included in OpenWrt" https://marc.info/?l=linux-wireless&m=145591129008322&w=2 More details are avilable in OpenWrt WiKi https://wiki.openwrt.org/doc/recipes/relayclient HTH, -vlado pgp3XdC1zUHe1.pgp Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/4] x86/vvmx: Drop the now-obsolete vmx_inst_check_privilege()
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Thursday, October 25, 2018 11:39 PM > > Now that nvmx_handle_vmx_insn() performs all VT-x instruction checks, > there is > no need for redundant checking in vmx_inst_check_privilege(). Remove it, > and > take out the vmxon_check boolean which was plumbed through > decode_vmx_inst(). > > Signed-off-by: Andrew Cooper Acked-by: Kevin Tian ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 3/4] x86/vvmx: INVVPID instructions should be handled at by L1
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Thursday, October 25, 2018 11:39 PM > > Signed-off-by: Andrew Cooper Acked-by: Kevin Tian ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 4/4] x86/vvmx: Don't handle unknown nested vmexit reasons at L0
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Thursday, October 25, 2018 11:39 PM > > This is very dangerous from a security point of view, because a missing > entry > will cause L2's action to be interpreted as L1's action. > > Signed-off-by: Andrew Cooper Acked-by: Kevin Tian ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-next test] 129127: tolerable FAIL
flight 129127 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/129127/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemuu-debianhvm-amd64 7 xen-boot fail like 129105 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail like 129105 test-amd64-amd64-xl-rtds 7 xen-boot fail like 129105 test-amd64-amd64-xl-qcow2 7 xen-boot fail like 129105 test-amd64-amd64-xl-credit2 7 xen-boot fail like 129105 test-amd64-i386-xl-qemut-debianhvm-amd64 7 xen-boot fail like 129105 test-amd64-amd64-xl-qemut-ws16-amd64 7 xen-boot fail like 129105 test-amd64-i386-qemuu-rhel6hvm-intel 7 xen-boot fail like 129105 test-amd64-i386-rumprun-i386 7 xen-boot fail like 129105 test-amd64-i386-xl-qemuu-win10-i386 7 xen-boot fail like 129105 test-amd64-i386-freebsd10-i386 7 xen-bootfail like 129105 test-amd64-amd64-pair10 xen-boot/src_hostfail like 129105 test-amd64-amd64-pair11 xen-boot/dst_hostfail like 129105 test-amd64-amd64-qemuu-nested-intel 7 xen-boot fail like 129105 test-amd64-amd64-libvirt-xsm 7 xen-boot fail like 129105 test-amd64-amd64-xl-qemuu-debianhvm-amd64 7 xen-boot fail like 129105 test-amd64-i386-examine 8 reboot fail like 129105 test-amd64-i386-libvirt 7 xen-boot fail like 129105 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail like 129105 test-amd64-amd64-xl-qemut-win7-amd64 7 xen-boot fail like 129105 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 7 xen-boot fail like 129105 test-amd64-amd64-i386-pvgrub 7 xen-boot fail like 129105 test-amd64-amd64-xl-multivcpu 7 xen-boot fail like 129105 test-amd64-amd64-xl-qemuu-ovmf-amd64 7 xen-boot fail like 129105 test-amd64-amd64-xl-qemuu-ws16-amd64 7 xen-boot fail like 129105 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail like 129105 test-amd64-amd64-xl-shadow7 xen-boot fail like 129105 test-amd64-i386-xl-qemuu-ovmf-amd64 7 xen-boot fail like 129105 test-amd64-amd64-xl-qemut-win10-i386 7 xen-boot fail like 129105 test-amd64-i386-freebsd10-amd64 7 xen-boot fail like 129105 test-amd64-i386-xl7 xen-boot fail like 129105 test-amd64-i386-xl-raw7 xen-boot fail like 129105 test-amd64-i386-xl-qemut-win10-i386 7 xen-boot fail like 129105 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail like 129105 test-amd64-i386-pair 10 xen-boot/src_hostfail like 129105 test-amd64-i386-pair 11 xen-boot/dst_hostfail like 129105 test-amd64-amd64-qemuu-nested-amd 7 xen-boot fail like 129105 test-amd64-amd64-xl-pvhv2-amd 7 xen-boot fail like 129105 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail like 129105 test-amd64-i386-xl-qemut-ws16-amd64 7 xen-boot fail like 129105 test-amd64-i386-qemut-rhel6hvm-amd 7 xen-bootfail like 129105 test-amd64-i386-xl-shadow 7 xen-boot fail like 129105 test-amd64-amd64-xl-xsm 7 xen-boot fail like 129105 test-amd64-amd64-xl-credit1 7 xen-boot fail like 129105 test-amd64-amd64-xl 7 xen-boot fail like 129105 test-amd64-amd64-xl-pvhv2-intel 7 xen-boot fail like 129105 test-amd64-amd64-xl-pvshim7 xen-boot fail like 129105 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail like 129105 test-amd64-amd64-pygrub 7 xen-boot fail like 129105 test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-boot fail like 129105 test-amd64-i386-xl-xsm7 xen-boot fail like 129105 test-amd64-amd64-libvirt-pair 10 xen-boot/src_hostfail like 129105 test-amd64-amd64-libvirt-pair 11 xen-boot/dst_hostfail like 129105 test-amd64-amd64-libvirt 7 xen-boot fail like 129105 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail like 129105 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail like 129105 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 7 xen-boot fail like 129105 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail like 129105 test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail like 129105 test-amd64-i386-libvirt-xsm 7 xen-boot fail like 129105 test-amd
Re: [Xen-devel] [PATCH v2 5/5] x86: Reorganise and rename debug register fields in struct vcpu
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Monday, October 15, 2018 6:36 PM > > Reusing debugreg[5] for the PV emulated IO breakpoint information is > confusing > to read. Instead, introduce a dr7_emul field in pv_vcpu for the pupose. > > With the PV emulation out of the way, debugreg[4,5] are entirely unused > and > don't need to be stored. > > Rename debugreg[0..3] to dr[0..3] to reduce code volume, but keep them > as an > array because their behaviour is identical and this helps simplfy some of > the > PV handling. Introduce dr6 and dr7 fields to replace debugreg[6,7] which > removes the storage for debugreg[4,5]. > > In arch_get_info_guest(), handle the merging of emulated dr7 state > alongside > all other dr handling, rather than much later. > > Signed-off-by: Andrew Cooper Reviewed-by: Kevin Tian ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Interrupt injection with ISR set on Intel hardware
>>> On 29.10.18 at 18:06, wrote:
> On 29/10/18 16:58, Jan Beulich wrote:
> On 29.10.18 at 17:44, wrote:
>>> On 29/10/18 16:33, Jan Beulich wrote:
>>> On 15.10.18 at 12:30, wrote:
> (XEN) [22641] PUSH {sp 0, irq 30, vec 0x21}
This is the last push or pop.
> (XEN) [22650] WAKE PPR 0x0020
> (XEN)IRR
>>> 0200
> (XEN)ISR
>>> 0200
For one I'm having trouble understanding why IRR here is different
from ...
> (XEN) All LAPIC state:
> (XEN) [vector] ISR TMR IRR
> (XEN) [1f:00]
> (XEN) [3f:20] 0002
> (XEN) [5f:40]
> (XEN) [7f:60]
> (XEN) [9f:80]
> (XEN) [bf:a0]
> (XEN) [df:c0]
> (XEN) [ff:e0] 0400
... IRR here.
>>> You shouldn't expect them to be the same.
>>>
>>> The WAKE line is sampled before we enable interrupts, and the "All LAPIC
>>> state" is after we enable interrupts and (erroneously) accept vector
>>> 0x21 a second time.
>> Oh, right - I had overlooked that the debugging patch was actually
>> attached to Roger's mail.
>>
>>> In the meantime, a TLB flush has become pending, but interrupts are
>>> currently disabled so it has yet to be accepted. Remember that bits
>>> accumulate in IRR entirely asynchronously.
>> Well, bits newly set are of course to be expected at any time. My
>> issue was just with bit 0x21 having got cleared.
>
> What is unexpected about that?
>
> Accepting a vector clears it out of IRR and sets it in ISR. A second
> interrupt can then be queued in IRR while the first is being serviced.
"Unexpected" was meant in the sense of how the sequence of
logged lines looked, without having looked at how the debugging
patch actually produces them.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v1 1/6] x86/vvmx: introduce vvmcx_valid()
> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
> Sent: Friday, October 12, 2018 11:28 PM
>
> As a convenient helper function and refactor the code to use it.
>
> No functional change.
>
> Signed-off-by: Sergey Dyasli
since vmcx is hvm abstracted term, what about using this
helper in svm side too?
> ---
> xen/arch/x86/hvm/vmx/vvmx.c | 17 -
> xen/include/asm-x86/hvm/nestedhvm.h | 5 +
> 2 files changed, 13 insertions(+), 9 deletions(-)
>
> diff --git a/xen/arch/x86/hvm/vmx/vvmx.c
> b/xen/arch/x86/hvm/vmx/vvmx.c
> index 0e45db83e5..8eee6d0ea8 100644
> --- a/xen/arch/x86/hvm/vmx/vvmx.c
> +++ b/xen/arch/x86/hvm/vmx/vvmx.c
> @@ -521,8 +521,7 @@ static void vmfail(struct cpu_user_regs *regs, enum
> vmx_insn_errno errno)
> if ( errno == VMX_INSN_SUCCEED )
> return;
>
> -if ( vcpu_nestedhvm(current).nv_vvmcxaddr != INVALID_PADDR &&
> - errno != VMX_INSN_FAIL_INVALID )
> +if ( vvmcx_valid(current) && errno != VMX_INSN_FAIL_INVALID )
> vmfail_valid(regs, errno);
> else
> vmfail_invalid(regs);
> @@ -805,7 +804,7 @@ static void nvmx_purge_vvmcs(struct vcpu *v)
> int i;
>
> __clear_current_vvmcs(v);
> -if ( nvcpu->nv_vvmcxaddr != INVALID_PADDR )
> +if ( vvmcx_valid(v) )
> hvm_unmap_guest_frame(nvcpu->nv_vvmcx, 1);
> nvcpu->nv_vvmcx = NULL;
> nvcpu->nv_vvmcxaddr = INVALID_PADDR;
> @@ -1601,7 +1600,7 @@ static int nvmx_vmresume(struct vcpu *v, struct
> cpu_user_regs *regs)
> struct nestedvcpu *nvcpu = &vcpu_nestedhvm(v);
>
> /* check VMCS is valid and IO BITMAP is set */
> -if ( (nvcpu->nv_vvmcxaddr != INVALID_PADDR) &&
> +if ( vvmcx_valid(v) &&
> ((nvmx->iobitmap[0] && nvmx->iobitmap[1]) ||
> !(__n2_exec_control(v) & CPU_BASED_ACTIVATE_IO_BITMAP) ) )
> nvcpu->nv_vmentry_pending = 1;
> @@ -1622,7 +1621,7 @@ int nvmx_handle_vmresume(struct
> cpu_user_regs *regs)
> if ( rc != X86EMUL_OKAY )
> return rc;
>
> -if ( vcpu_nestedhvm(v).nv_vvmcxaddr == INVALID_PADDR )
> +if ( !vvmcx_valid(v) )
> {
> vmfail_invalid(regs);
> return X86EMUL_OKAY;
> @@ -1656,7 +1655,7 @@ int nvmx_handle_vmlaunch(struct cpu_user_regs
> *regs)
> if ( rc != X86EMUL_OKAY )
> return rc;
>
> -if ( vcpu_nestedhvm(v).nv_vvmcxaddr == INVALID_PADDR )
> +if ( !vvmcx_valid(v) )
> {
> vmfail_invalid(regs);
> return X86EMUL_OKAY;
> @@ -1709,7 +1708,7 @@ int nvmx_handle_vmptrld(struct cpu_user_regs
> *regs)
> if ( nvcpu->nv_vvmcxaddr != gpa )
> nvmx_purge_vvmcs(v);
>
> -if ( nvcpu->nv_vvmcxaddr == INVALID_PADDR )
> +if ( !vvmcx_valid(v) )
> {
> bool_t writable;
> void *vvmcx = hvm_map_guest_frame_rw(paddr_to_pfn(gpa), 1,
> &writable);
> @@ -1848,7 +1847,7 @@ int nvmx_handle_vmread(struct cpu_user_regs
> *regs)
> if ( rc != X86EMUL_OKAY )
> return rc;
>
> -if ( vcpu_nestedhvm(v).nv_vvmcxaddr == INVALID_PADDR )
> +if ( !vvmcx_valid(v) )
> {
> vmfail_invalid(regs);
> return X86EMUL_OKAY;
> @@ -1891,7 +1890,7 @@ int nvmx_handle_vmwrite(struct cpu_user_regs
> *regs)
> != X86EMUL_OKAY )
> return X86EMUL_EXCEPTION;
>
> -if ( vcpu_nestedhvm(v).nv_vvmcxaddr == INVALID_PADDR )
> +if ( !vvmcx_valid(v) )
> {
> vmfail_invalid(regs);
> return X86EMUL_OKAY;
> diff --git a/xen/include/asm-x86/hvm/nestedhvm.h b/xen/include/asm-
> x86/hvm/nestedhvm.h
> index 9d1c2742b5..e09fa9d47d 100644
> --- a/xen/include/asm-x86/hvm/nestedhvm.h
> +++ b/xen/include/asm-x86/hvm/nestedhvm.h
> @@ -92,4 +92,9 @@ static inline void nestedhvm_set_cr(struct vcpu *v,
> unsigned int cr,
> v->arch.hvm.nvcpu.guest_cr[cr] = value;
> }
>
> +static inline bool vvmcx_valid(const struct vcpu *v)
> +{
> +return vcpu_nestedhvm(v).nv_vvmcxaddr != INVALID_PADDR;
> +}
> +
> #endif /* _HVM_NESTEDHVM_H */
> --
> 2.17.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v1 2/6] x86/vvmx: correct vmfail() usage for vmptrld and vmclear
> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com] > Sent: Friday, October 12, 2018 11:28 PM > > Calling vmfail_valid() is correct only if vvmcx is valid. Modify > functions to use vmfail() instead which performs the necessary check. > > Signed-off-by: Sergey Dyasli Acked-by: Kevin Tian . btw Wei's suggestion on adding assert makes sense to me ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [GIT PULL] xen: fixes for 4.20-rc1
Linus, Please git pull the following tag: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-4.20a-rc1-tag xen: fixes for 4.20-rc1 It contains only several small fixes and cleanups this time. Thanks. Juergen MAINTAINERS| 1 + arch/x86/xen/platform-pci-unplug.c | 4 arch/x86/xen/spinlock.c| 33 - arch/x86/xen/xen-pvh.S | 2 +- drivers/xen/Kconfig| 13 ++--- drivers/xen/xen-balloon.c | 13 - drivers/xen/xenbus/xenbus_client.c | 6 ++ 7 files changed, 30 insertions(+), 42 deletions(-) Bartlomiej Zolnierkiewicz (1): xen: remove redundant 'default n' from Kconfig Boris Ostrovsky (1): xen/balloon: Support xend-based toolstack Geert Uytterhoeven (1): xen/balloon: Grammar s/Is it/It is/ Jason Andryuk (1): xen: Make XEN_BACKEND selectable by DomU Juergen Gross (4): xen: fix race in xen_qlock_wait() xen: make xen_qlock_wait() nestable xen/pvh: don't try to unplug emulated devices xen: drop writing error messages to xenstore Roger Pau Monne (1): xen/pvh: increase early stack size Stefano Stabellini (1): add myself as reviewer for Xen support in Linux ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v1 3/6] x86/vvmx: add VMX_INSN_VMPTRLD_WITH_VMXON_PTR errno
> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com] > Sent: Friday, October 12, 2018 11:28 PM > > And make nvmx_handle_vmptrld() return the new errno in case the > provided > address is the same as vmxon region address. > > While at it, correct the return value for not-4KB-aligned case. > > Signed-off-by: Sergey Dyasli Acked-by: Kevin Tian ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v1 4/6] x86/vvmx: add VMX_INSN_VMCLEAR_WITH_VMXON_PTR errno
> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
> Sent: Friday, October 12, 2018 11:28 PM
>
> And make nvmx_handle_vmclear() return the new errno in case the
> provided
> address is the same as vmxon region address.
>
> While at it, correct the return value for not-4KB-aligned case and for
> invalid physaddr.
>
> Signed-off-by: Sergey Dyasli
> ---
> xen/arch/x86/hvm/vmx/vvmx.c| 23 ++-
> xen/include/asm-x86/hvm/vmx/vmcs.h | 1 +
> 2 files changed, 19 insertions(+), 5 deletions(-)
>
> diff --git a/xen/arch/x86/hvm/vmx/vvmx.c
> b/xen/arch/x86/hvm/vmx/vvmx.c
> index 4caa5811a1..8b691bfc04 100644
> --- a/xen/arch/x86/hvm/vmx/vvmx.c
> +++ b/xen/arch/x86/hvm/vmx/vvmx.c
> @@ -1804,9 +1804,20 @@ int nvmx_handle_vmclear(struct cpu_user_regs
> *regs)
> return rc;
>
> BUILD_BUG_ON(X86EMUL_OKAY != VMSUCCEED); /* rc = VMSUCCEED;
> */
> +
> +if ( gpa == vcpu_2_nvmx(v).vmxon_region_pa )
> +{
> +vmfail(regs, VMX_INSN_VMCLEAR_WITH_VMXON_PTR);
> +goto out;
> +}
> +
> if ( gpa & 0xfff )
> -rc = VMFAIL_INVALID;
> -else if ( gpa == nvcpu->nv_vvmcxaddr )
> +{
> +vmfail(regs, VMX_INSN_VMCLEAR_INVALID_PHYADDR);
> +goto out;
> +}
> +
> +if ( gpa == nvcpu->nv_vvmcxaddr )
> {
> if ( cpu_has_vmx_vmcs_shadowing )
> nvmx_clear_vmcs_pointer(v, nvcpu->nv_vvmcx);
> @@ -1820,7 +1831,10 @@ int nvmx_handle_vmclear(struct cpu_user_regs
> *regs)
> bool_t writable;
>
> vvmcs = hvm_map_guest_frame_rw(paddr_to_pfn(gpa), 0, &writable);
> -if ( vvmcs )
> +
> +if ( !vvmcs )
> +rc = VMFAIL_VALID;
> +else
> {
> if ( writable )
> clear_vvmcs_launched(&nvmx->launched_list,
> @@ -1835,9 +1849,8 @@ int nvmx_handle_vmclear(struct cpu_user_regs
> *regs)
> vmsucceed(regs);
> else if ( rc == VMFAIL_VALID )
> vmfail(regs, VMX_INSN_VMCLEAR_INVALID_PHYADDR);
> -else
> -vmfail_invalid(regs);
>
there is only one place poking rc now. clearer to replace rc with direct
vmfail too. then above rc checks can be removed.
> +out:
> return X86EMUL_OKAY;
> }
>
> diff --git a/xen/include/asm-x86/hvm/vmx/vmcs.h b/xen/include/asm-
> x86/hvm/vmx/vmcs.h
> index cae1861610..e84d2e482b 100644
> --- a/xen/include/asm-x86/hvm/vmx/vmcs.h
> +++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
> @@ -529,6 +529,7 @@ enum vmx_insn_errno
> {
> VMX_INSN_SUCCEED = 0,
> VMX_INSN_VMCLEAR_INVALID_PHYADDR = 2,
> +VMX_INSN_VMCLEAR_WITH_VMXON_PTR= 3,
> VMX_INSN_VMLAUNCH_NONCLEAR_VMCS= 4,
> VMX_INSN_VMRESUME_NONLAUNCHED_VMCS = 5,
> VMX_INSN_INVALID_CONTROL_STATE = 7,
> --
> 2.17.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf test] 129171: all pass - PUSHED
flight 129171 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/129171/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 4222e8e7e421e9c8d2c2f319a3860dd3332d6255 baseline version: ovmf c87ac38cf280fa969f1033de3c5b7a157aac8cbc Last test of basis 129162 2018-10-30 01:40:57 Z0 days Testing same since 129171 2018-10-30 05:00:18 Z0 days1 attempts People who touched revisions under test: Jian J Wang Marvin H?user Marvin Haeuser jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 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/osstest/ovmf.git c87ac38cf2..4222e8e7e4 4222e8e7e421e9c8d2c2f319a3860dd3332d6255 -> xen-tested-master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v1 5/6] x86/vvmx: correctly report vvmcs size
> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
> Sent: Friday, October 12, 2018 11:28 PM
>
> The size of Xen's virtual vmcs region is 4096 bytes. Correctly report
> it to the guest in case when VMCS shadowing is not available instead of
> providing H/W value (which is usually smaller).
what is the problem of reporting smaller size even when actual
size is 4096? is L1 expected to access the portion beyond h/w
reported size?
>
> Signed-off-by: Sergey Dyasli
> ---
> xen/arch/x86/hvm/vmx/vvmx.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/xen/arch/x86/hvm/vmx/vvmx.c
> b/xen/arch/x86/hvm/vmx/vvmx.c
> index 8b691bfc04..2c2ba36d94 100644
> --- a/xen/arch/x86/hvm/vmx/vvmx.c
> +++ b/xen/arch/x86/hvm/vmx/vvmx.c
> @@ -2064,6 +2064,14 @@ int nvmx_msr_read_intercept(unsigned int msr,
> u64 *msr_content)
> data = (host_data & (~0ul << 32)) |
> (vmcs->vmcs_revision_id & 0x7fff);
> unmap_domain_page(vmcs);
> +
> +if ( !cpu_has_vmx_vmcs_shadowing )
> +{
> +/* Report vmcs_region_size as 4096 */
> +data &= ~VMX_BASIC_VMCS_SIZE_MASK;
> +data |= 1ULL << 44;
> +}
> +
> break;
> }
> case MSR_IA32_VMX_PINBASED_CTLS:
> --
> 2.17.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/4] xen/arm: gic: Ensure we have an ISB between ack and do_IRQ()
Hi, On 29.10.18 18:22, Julien Grall wrote: > What is the issue? Is it just your print or there a latent bug in > current vGIC? Ah, OK, that was the issue for me. > I actually prefer if we re-enable interrupts after > entry_hypervisor_head(). This makes the code working the same way > everywhere so less trouble to figure out problem. Good point. Actually I was confused by the reported behavior, because I overlooked those msr's with different arguments in entry.S and assumed enter_hypervisor_head() always runs with irqs disabled. -- *Andrii Anisov* ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [qemu-mainline test] 129131: tolerable FAIL - PUSHED
flight 129131 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/129131/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 129079 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 129079 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 129079 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 129079 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 129079 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 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-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-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-xl-qemuu-ws16-amd64 17 guest-stop 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: qemuu285278ca785f5fa9a570927e1c0958a2ca2b2150 baseline version: qemuu179f9ac887973c818b2578bd79fa3ed2522657d4 Last test of basis 129079 2018-10-28 01:34:21 Z2 days Testing same since 129131 2018-10-29 10:06:56 Z0 days1 attempts People who touched revisions under test: Fam Zheng Paolo Bonzini Peter Maydell Philippe Mathieu-Daudé Philippe Mathieu-Daudé jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt
Re: [Xen-devel] [PATCH] xen-swiotlb: exchange memory with Xen only when pages are contiguous
> -Original Message- > From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf > Of Joe Jin > Sent: 30 October 2018 02:52 > To: Boris Ostrovsky ; Konrad Rzeszutek Wilk > > Cc: John Sobecki ; DONGLI.ZHANG > ; linux-ker...@vger.kernel.org" ker...@vger.kernel.org>; kon...@kernel.org; xen- > de...@lists.xenproject.org; Christoph Helwig > Subject: Re: [Xen-devel] [PATCH] xen-swiotlb: exchange memory with Xen > only when pages are contiguous > > On 10/25/18 11:56 AM, Joe Jin wrote: > > I just discussed this patch with Boris in private, his opinions(Boris, > > please correct me if any misunderstood) are: > > > > 1. With/without the check, both are incorrect, he thought we need to > >prevented unalloc'd free at here. > > 2. On freeing, if upper layer already checked the memory was DMA-able, > >the checking at here does not make sense, we can remove all checks. > > 3. xen_create_contiguous_region() and xen_destroy_contiguous_region() > >to come in pairs. > I tried to added radix_tree to track allocating/freeing and I found some > memory only allocated but was not freed, I guess it caused by driver used > dma_pool, that means if lots of such requests, the list will consume lot > of memory for it. Will continue to work on it, if anyone have good idea > for it please let me know, I'd like to try it. > FWIW, in my Xen PV-IOMMU test patches, I have also tried keeping a list of ranges mapped for DMA and have discovered apparent issues with some drivers, particularly tg3, that seem to free mappings that have not been allocated (or possibly double-free). I've never fully tracked down the issue. Paul > Thanks, > Joe > > ___ > Xen-devel mailing list > Xen-devel@lists.xenproject.org > https://lists.xenproject.org/mailman/listinfo/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf baseline-only test] 75543: tolerable FAIL
This run is configured for baseline tests only. flight 75543 ovmf real [real] http://osstest.xensource.com/osstest/logs/75543/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: build-amd64-libvirt 6 libvirt-buildfail like 75537 build-i386-libvirt6 libvirt-buildfail like 75537 version targeted for testing: ovmf c87ac38cf280fa969f1033de3c5b7a157aac8cbc baseline version: ovmf c09b254bdc6050cc8b580a26558f692f958645d6 Last test of basis75537 2018-10-29 10:52:10 Z0 days Testing same since75543 2018-10-30 05:31:10 Z0 days1 attempts People who touched revisions under test: Ruiyu Ni jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt fail build-i386-libvirt fail build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xensource.com/osstest/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. commit c87ac38cf280fa969f1033de3c5b7a157aac8cbc Author: Ruiyu Ni Date: Mon Oct 29 11:54:45 2018 +0800 MdeModulePkg/UsbBusDxe: Add missing "return NULL" in UsbCreateDesc() When (Len < Offset) is TRUE, indicating the data to visit is beyond the boundary, the error message is printed but the function doesn't return NULL. It's a typo when modifying the commit 4c034bf62. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni Reviewed-by: Star Zeng ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] arm, smmu: backport "Disable stalling faults for all endpoints"
>>> On 29.10.18 at 22:14, wrote: > From: Stefano Stabellini > > Backport commit 3714ce1d6655098ee69ede632883e5874d67e4ab > "iommu/arm-smmu: Disable stalling faults for all endpoints" from the > Linux kernel. This works-around Erratum #842869. Btw, seeing this having gone in a few hours ago I got rather puzzled by there being a backport on the master branch. In the future, can such be titled just "port ..." as they're not really backports (which would imply a variant being available on a newer branch)? Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/8] viridian: move the code into its own sub-directory
>>> On 29.10.18 at 19:02, wrote: > Subsequent patches will introduce support for more viridian enlightenments > which will make a single source module quite lengthy. > > This patch therefore creates a new arch/x86/hvm/viridian sub-directory and > moves viridian.c into that. > > The patch also fixes some bad whitespace whilst moving the code. > > Signed-off-by: Paul Durrant Acked-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [Xen-users] [XEN][ARM] WiFi bridge creation
Hi, As per below link, it is possible to share Internet via WiFi between Dom0 and DomU,. https://wiki.xenproject.org/wiki/Xen_in_WiFi_networks Tried the suggested solution using ebtables, but it did not work. * ebtables -t nat -A POSTROUTING -s 00:60:00:00:00:01 \ -j snat --to-source 00:60:aa:bb:cc:dd* In the configurations file we have added below configuration in DomU config file. * vif = ['mac=00:16:3e:64:b8:40']* Apart from that do we need to add any addition configuration? On Tue, Oct 30, 2018 at 12:39 PM Vladimir Botka wrote: > On Tue, 30 Oct 2018 10:03:22 +0530 > Vikram K wrote: > > > Hello, > > We are using Hikey960 with Debian as Dom0 and DomU. This board has only > > WiFi interface. We want to create bridge between Dom0 and DomU so that > DomU > > has internet access. We tried to create bridge using brtcl command, but > it > > is not working. Please provide pointers. > > AFAIK, it's not working > https://marc.info/?l=linux-wireless&m=136743495526905&w=2 > "There is a proposed fix that is included in OpenWrt" > https://marc.info/?l=linux-wireless&m=145591129008322&w=2 > More details are avilable in OpenWrt WiKi > https://wiki.openwrt.org/doc/recipes/relayclient > > HTH, > > -vlado > -- Thanks & Regards Vikram KS -- This message contains confidential information and is intended only for the individual(s) named. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this mail and attached file/s is strictly prohibited. Please notify the sender immediately and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secured or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v5] arch/x86: Add registers to vm_event
This patch adds a couple of regs to the vm_event that are used by
the introspection. The base, limit and ar
bits are compressed into a uint64_t union so as not to enlarge the
vm_event.
Signed-off-by: Alexandru Isaila
---
Changes since V4:
- Change the comment into one line
- Pull the base out of x86_selector_reg
- Renamed x86_selector_reg_32,64 into x86_selector_reg.
---
xen/arch/x86/vm_event.c | 71 +++
xen/include/public/vm_event.h | 26 -
2 files changed, 87 insertions(+), 10 deletions(-)
diff --git a/xen/arch/x86/vm_event.c b/xen/arch/x86/vm_event.c
index 15de43c3e6..4e7b748010 100644
--- a/xen/arch/x86/vm_event.c
+++ b/xen/arch/x86/vm_event.c
@@ -122,11 +122,66 @@ void vm_event_monitor_next_interrupt(struct vcpu *v)
v->arch.monitor.next_interrupt_enabled = true;
}
+static void vm_event_pack_segment_register(enum x86_segment segment,
+ struct vm_event_regs_x86 *reg)
+{
+struct segment_register seg;
+
+hvm_get_segment_register(current, segment, &seg);
+
+switch ( segment )
+{
+case x86_seg_ss:
+reg->ss_base = seg.base;
+reg->ss.limit = seg.g ? seg.limit >> 12 : seg.limit;
+reg->ss.ar = seg.attr;
+reg->ss_sel = seg.sel;
+break;
+
+case x86_seg_fs:
+reg->fs_base = seg.base;
+reg->fs.limit = seg.g ? seg.limit >> 12 : seg.limit;
+reg->fs.ar = seg.attr;
+reg->fs_sel = seg.sel;
+break;
+
+case x86_seg_gs:
+reg->gs_base = seg.base;
+reg->gs.limit = seg.g ? seg.limit >> 12 : seg.limit;
+reg->gs.ar = seg.attr;
+reg->gs_sel = seg.sel;
+break;
+
+case x86_seg_cs:
+reg->cs_base = seg.base;
+reg->cs.limit = seg.g ? seg.limit >> 12 : seg.limit;
+reg->cs.ar = seg.attr;
+reg->cs_sel = seg.sel;
+break;
+
+case x86_seg_ds:
+reg->ds_base = seg.base;
+reg->ds.limit = seg.g ? seg.limit >> 12 : seg.limit;
+reg->ds.ar = seg.attr;
+reg->ds_sel = seg.sel;
+break;
+
+case x86_seg_es:
+reg->es_base = seg.base;
+reg->es.limit = seg.g ? seg.limit >> 12 : seg.limit;
+reg->es.ar = seg.attr;
+reg->es_sel = seg.sel;
+break;
+
+default:
+ASSERT_UNREACHABLE();
+}
+}
+
void vm_event_fill_regs(vm_event_request_t *req)
{
#ifdef CONFIG_HVM
const struct cpu_user_regs *regs = guest_cpu_user_regs();
-struct segment_register seg;
struct hvm_hw_cpu ctxt = {};
struct vcpu *curr = current;
@@ -170,14 +225,14 @@ void vm_event_fill_regs(vm_event_request_t *req)
req->data.regs.x86.msr_star = ctxt.msr_star;
req->data.regs.x86.msr_lstar = ctxt.msr_lstar;
-hvm_get_segment_register(curr, x86_seg_fs, &seg);
-req->data.regs.x86.fs_base = seg.base;
-
-hvm_get_segment_register(curr, x86_seg_gs, &seg);
-req->data.regs.x86.gs_base = seg.base;
+vm_event_pack_segment_register(x86_seg_fs, &req->data.regs.x86);
+vm_event_pack_segment_register(x86_seg_gs, &req->data.regs.x86);
+vm_event_pack_segment_register(x86_seg_cs, &req->data.regs.x86);
+vm_event_pack_segment_register(x86_seg_ss, &req->data.regs.x86);
+vm_event_pack_segment_register(x86_seg_ds, &req->data.regs.x86);
+vm_event_pack_segment_register(x86_seg_es, &req->data.regs.x86);
-hvm_get_segment_register(curr, x86_seg_cs, &seg);
-req->data.regs.x86.cs_arbytes = seg.attr;
+req->data.regs.x86.shadow_gs = ctxt.shadow_gs;
#endif
}
diff --git a/xen/include/public/vm_event.h b/xen/include/public/vm_event.h
index 36e3f4685d..b9ac009327 100644
--- a/xen/include/public/vm_event.h
+++ b/xen/include/public/vm_event.h
@@ -29,7 +29,7 @@
#include "xen.h"
-#define VM_EVENT_INTERFACE_VERSION 0x0003
+#define VM_EVENT_INTERFACE_VERSION 0x0004
#if defined(__XEN__) || defined(__XEN_TOOLS__)
@@ -157,6 +157,12 @@
#define VM_EVENT_X86_CR42
#define VM_EVENT_X86_XCR0 3
+/* The limit field is right-shifted by 12 bits if .ar.g is set. */
+struct x86_selector_reg {
+uint32_t limit :20;
+uint32_t ar :12;
+};
+
/*
* Using custom vCPU structs (i.e. not hvm_hw_cpu) for both x86 and ARM
* so as to not fill the vm_event ring buffer too quickly.
@@ -191,9 +197,25 @@ struct vm_event_regs_x86 {
uint64_t msr_efer;
uint64_t msr_star;
uint64_t msr_lstar;
+uint32_t cs_base;
+uint32_t ss_base;
+uint32_t ds_base;
+uint32_t es_base;
uint64_t fs_base;
uint64_t gs_base;
-uint32_t cs_arbytes;
+struct x86_selector_reg cs;
+struct x86_selector_reg ss;
+struct x86_selector_reg ds;
+struct x86_selector_reg es;
+struct x86_selector_reg fs;
+struct x86_selector_reg gs;
+uint64_t shadow_gs;
+uint16_t cs_sel;
+uint16_t ss_sel;
+uint16_t ds_sel;
+uint16_t es_sel;
+uint16_t fs_sel;
+uint16_t gs_sel;
uin
[Xen-devel] [PATCH 1/1] tools/ocaml: make type of Xsraw.sync more precise
The type of Xsraw.sync is made more precise: from val sync : (Xenbus.Xb.t -> 'a) -> con -> string to val sync : (Xenbus.Xb.t -> unit) -> con -> string The first argument is enforced to return unit rather than a value that is not used anyway. Signed-off-by: Christian Lindig --- tools/ocaml/libs/xs/xsraw.mli| 2 +- tools/ocaml/xenstored/process.ml | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/tools/ocaml/libs/xs/xsraw.mli b/tools/ocaml/libs/xs/xsraw.mli index 57e4fb0c90..374f0f9fad 100644 --- a/tools/ocaml/libs/xs/xsraw.mli +++ b/tools/ocaml/libs/xs/xsraw.mli @@ -33,7 +33,7 @@ val has_watchevents : con -> bool val get_watchevent : con -> string * string val read_watchevent : con -> string * string val sync_recv : Xenbus.Xb.Op.operation -> con -> string -val sync : (Xenbus.Xb.t -> 'a) -> con -> string +val sync : (Xenbus.Xb.t -> unit) -> con -> string val ack : string -> unit val validate_path : string -> unit val validate_watch_path : string -> unit diff --git a/tools/ocaml/xenstored/process.ml b/tools/ocaml/xenstored/process.ml index 977e7c11be..d813d7fd50 100644 --- a/tools/ocaml/xenstored/process.ml +++ b/tools/ocaml/xenstored/process.ml @@ -348,7 +348,7 @@ let transaction_replay c t doms cons = false ) (fun () -> - Connection.end_transaction c tid None + ignore @@ Connection.end_transaction c tid None ) let do_watch con t domains cons data = @@ -366,7 +366,7 @@ let do_unwatch con t domains cons data = | [node; token; ""] -> node, token | _ -> raise Invalid_Cmd_Args in - Connections.del_watch cons con node token + ignore @@ Connections.del_watch cons con node token let do_transaction_start con t domains cons data = if Transaction.get_id t <> Transaction.none then -- 2.19.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [Xen-users] [XEN][ARM] WiFi bridge creation
> On Tue, Oct 30, 2018 at 12:39 PM Vladimir Botka wrote: > > On Tue, 30 Oct 2018 10:03:22 +0530 > > Vikram K wrote: > > > Hello, > > > We are using Hikey960 with Debian as Dom0 and DomU. This board has only > > > WiFi interface. We want to create bridge between Dom0 and DomU so that > > > DomU > > > has internet access. We tried to create bridge using brtcl command, but > > > it > > > is not working. Please provide pointers. > > AFAIK, it's not working > > https://marc.info/?l=linux-wireless&m=136743495526905&w=2 > > "There is a proposed fix that is included in OpenWrt" > > https://marc.info/?l=linux-wireless&m=145591129008322&w=2 > > More details are avilable in OpenWrt WiKi > > https://wiki.openwrt.org/doc/recipes/relayclient > > -vlado On Tue, 30 Oct 2018 15:01:39 +0530 Vikram K wrote: > Hi, > As per below link, it is possible to share Internet via WiFi between Dom0 > and DomU,. > https://wiki.xenproject.org/wiki/Xen_in_WiFi_networks > Tried the suggested solution using ebtables, but it did not work. > * ebtables -t nat -A POSTROUTING -s 00:60:00:00:00:01 \ > -j snat --to-source 00:60:aa:bb:cc:dd* > In the configurations file we have added below configuration in DomU > config file. > * vif = ['mac=00:16:3e:64:b8:40']* > Apart from that do we need to add any addition configuration? NAT is a different story. Worked for me with Armbian(no XEN) and Atheros 9280 couple of years ago. I used Ansible to configure it. https://github.com/vbotka/ansible-linux-postinstall/blob/master/templates/router1-iptables.j2 HTH, - vlado pgpkiY_voPm7U.pgp Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen-blkfront: fix kernel panic with negotiate_mq error path
On Mon, Oct 29, 2018 at 11:31:56AM -0700, Manjunath Patil wrote:
> info->nr_rings isn't adjusted in case of ENOMEM error from
> negotiate_mq(). This leads to kernel panic in error path.
>
> Typical call stack involving panic -
> #8 page_fault at 8175936f
> [exception RIP: blkif_free_ring+33]
> RIP: a0149491 RSP: 8804f7673c08 RFLAGS: 00010292
> ...
> #9 blkif_free at a0149aaa [xen_blkfront]
> #10 talk_to_blkback at a014c8cd [xen_blkfront]
> #11 blkback_changed at a014ea8b [xen_blkfront]
> #12 xenbus_otherend_changed at 81424670
> #13 backend_changed at 81426dc3
> #14 xenwatch_thread at 81422f29
> #15 kthread at 810abe6a
> #16 ret_from_fork at 81754078
>
> Though either of my changes avoid the panic, I included both the
> changes. This issue got introduced with "7ed8ce1 xen-blkfront: move
> negotiate_mq to cover all cases of new VBDs"
>
> Signed-off-by: Manjunath Patil
> ---
> drivers/block/xen-blkfront.c |7 +--
> 1 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 429d201..dc8fe25 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -1350,8 +1350,10 @@ static void blkif_free(struct blkfront_info *info, int
> suspend)
> if (info->rq)
> blk_mq_stop_hw_queues(info->rq);
>
> - for (i = 0; i < info->nr_rings; i++)
> - blkif_free_ring(&info->rinfo[i]);
> + if (info->rinfo) {
> + for (i = 0; i < info->nr_rings; i++)
> + blkif_free_ring(&info->rinfo[i]);
> + }
I don't see the point in the if case here, you already fixed it by
setting the nr_rings value which I think it's the correct way of
fixing it.
Thanks, Roger.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [OSSTEST PATCH] production-config-cambridge: Use squid cache, not local apt proxy
debian.uk.xensource.com is no more (and the service name seems to have been discarded). There is repo.citrite.net instead but it is a proprietary appliance which - although it claims to be able to handle apt repositories - is not compatible with debian-installer; at least, jessie's d-i. Swap to ftp.uk.debian.org (and rely for caching on the squid cache which we have for non-apt stuff already). That works well enough for stable suites, at least. Signed-off-by: Ian Jackson --- production-config-cambridge | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/production-config-cambridge b/production-config-cambridge index 8647feb2..5c9a4a28 100644 --- a/production-config-cambridge +++ b/production-config-cambridge @@ -91,9 +91,14 @@ MicrocodeUpdateI386 microcode.x86.2015-06-12.cpio XenUsePath /usr/groups/xencore/systems/bin/xenuse XenUseUser osstest -# We use the IP address because Citrix can't manage reliable nameservice -#DebianMirrorHost debian.uk.xensource.com -DebianMirrorHost 10.80.16.196 +# Ideally we would use the IP address because Citrix can't manage +# reliable nameservice but this new proprietary mirror does not +# work if it doesn't get a suitable Host header. +#DebianMirrorHost repo.citrite.net +#DebianMirrorSubpath ctx-remote-deb-debian +# Also the proprietary mirror doesn't work because it redirects to http +# which d-i does not support. So use our squid. +DebianMirrorHost ftp.uk.debian.org HttpProxy http://osstest.xs.citrite.net:3128/ DebianMirrorProxy http://osstest.xs.citrite.net:3128/ -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 7/7] amd/pvh: enable ACPI C1E disable quirk on PVH Dom0
On Mon, Oct 29, 2018 at 08:19:20AM -0600, Jan Beulich wrote:
> >>> On 19.10.18 at 17:20, wrote:
> > --- a/xen/arch/x86/hvm/svm/svm.c
> > +++ b/xen/arch/x86/hvm/svm/svm.c
> > @@ -1272,6 +1272,24 @@ void svm_host_osvw_init()
> > spin_unlock(&osvw_lock);
> > }
> >
> > +static int acpi_c1e_quirk(int dir, unsigned int port, unsigned int bytes,
> > + uint32_t *val)
> > +{
> > +ASSERT(bytes == 1 && port == acpi_smi_cmd);
> > +
> > +if ( dir == IOREQ_READ )
> > +{
> > +*val = inb(port);
> > +return X86EMUL_OKAY;
> > +}
> > +
> > +outb(*val, port);
> > +if ( *val == acpi_enable_value )
> > + on_each_cpu(amd_disable_c1e, NULL, 1);
> > +
> > +return X86EMUL_OKAY;
> > +}
>
> Nothing in here nor ...
>
> > @@ -1284,6 +1302,9 @@ static int svm_domain_initialise(struct domain *d)
> >
> > svm_guest_osvw_init(d);
> >
> > +if ( amd_acpi_c1e_quirk )
> > +register_portio_handler(d, acpi_smi_cmd, 1, acpi_c1e_quirk);
>
> ... the registration here restricts this to Dom0.
Right, I got messed up with the permissions and completely forgot
about limiting to Dom0.
The above needs to have a '&& is_hardware_domain(d)' IMO. I prefer to
do this at hook registration rather than adding such check in the
handler itself.
Thanks. Roger.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC 07/16] xen/arm: p2m: Introduce p2m_is_valid and use it
Hi,
On 30/10/2018 00:21, Stefano Stabellini wrote:
On Mon, 8 Oct 2018, Julien Grall wrote:
The LPAE format allows to store information in an entry even with the
valid bit unset. In a follow-up patch, we will take advantage of this
feature to re-purpose the valid bit for generating a translation fault
even if an entry contains valid information.
So we need a different way to know whether an entry contains valid
information. It is possible to use the information hold in the p2m_type
to know for that purpose. Indeed all entries containing valid
information will have a valid p2m type (i.e p2m_type != p2m_invalid).
This patch introduces a new helper p2m_is_valid, which implements that
idea, and replace most of lpae_is_valid call with the new helper. The ones
remaining are for TLBs handling and entries accounting.
With the renaming there are 2 others changes required:
- Generate table entry with a valid p2m type
- Detect new mapping for proper stats accounting
Signed-off-by: Julien Grall
---
xen/arch/arm/p2m.c | 34 +++---
1 file changed, 23 insertions(+), 11 deletions(-)
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 6c76298ebc..2a1e7e9be2 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -220,17 +220,26 @@ static p2m_access_t p2m_mem_access_radix_get(struct
p2m_domain *p2m, gfn_t gfn)
}
/*
+ * In the case of the P2M, the valid bit is used for other purpose. Use
+ * the type to check whether an entry is valid.
+ */
+static inline bool p2m_is_valid(lpae_t pte)
+{
+return pte.p2m.type != p2m_invalid;
+}
+
+/*
* lpae_is_* helpers don't check whether the valid bit is set in the
* PTE. Provide our own overlay to check the valid bit.
*/
static inline bool p2m_is_mapping(lpae_t pte, unsigned int level)
{
-return lpae_is_valid(pte) && lpae_is_mapping(pte, level);
+return p2m_is_valid(pte) && lpae_is_mapping(pte, level);
}
static inline bool p2m_is_superpage(lpae_t pte, unsigned int level)
{
-return lpae_is_valid(pte) && lpae_is_superpage(pte, level);
+return p2m_is_valid(pte) && lpae_is_superpage(pte, level);
}
#define GUEST_TABLE_MAP_FAILED 0
@@ -264,7 +273,7 @@ static int p2m_next_level(struct p2m_domain *p2m, bool
read_only,
entry = *table + offset;
-if ( !lpae_is_valid(*entry) )
+if ( !p2m_is_valid(*entry) )
{
if ( read_only )
return GUEST_TABLE_MAP_FAILED;
@@ -356,7 +365,7 @@ mfn_t p2m_get_entry(struct p2m_domain *p2m, gfn_t gfn,
entry = table[offsets[level]];
-if ( lpae_is_valid(entry) )
+if ( p2m_is_valid(entry) )
{
*t = entry.p2m.type;
@@ -544,8 +553,11 @@ static lpae_t page_to_p2m_table(struct page_info *page)
/*
* The access value does not matter because the hardware will ignore
* the permission fields for table entry.
+ *
+ * We use p2m_ram_rw so the entry has a valid type. This is important
+ * for p2m_is_valid() to return valid on table entries.
*/
-return mfn_to_p2m_entry(page_to_mfn(page), p2m_invalid, p2m_access_rwx);
+return mfn_to_p2m_entry(page_to_mfn(page), p2m_ram_rw, p2m_access_rwx);
}
static inline void p2m_write_pte(lpae_t *p, lpae_t pte, bool clean_pte)
@@ -569,7 +581,7 @@ static int p2m_create_table(struct p2m_domain *p2m, lpae_t
*entry)
struct page_info *page;
lpae_t *p;
-ASSERT(!lpae_is_valid(*entry));
+ASSERT(!p2m_is_valid(*entry));
page = alloc_domheap_page(NULL, 0);
if ( page == NULL )
@@ -626,7 +638,7 @@ static int p2m_mem_access_radix_set(struct p2m_domain *p2m,
gfn_t gfn,
*/
static void p2m_put_l3_page(const lpae_t pte)
{
-ASSERT(lpae_is_valid(pte));
+ASSERT(p2m_is_valid(pte));
/*
* TODO: Handle other p2m types
@@ -654,11 +666,11 @@ static void p2m_free_entry(struct p2m_domain *p2m,
struct page_info *pg;
/* Nothing to do if the entry is invalid. */
-if ( !lpae_is_valid(entry) )
+if ( !p2m_is_valid(entry) )
return;
/* Nothing to do but updating the stats if the entry is a super-page. */
-if ( p2m_is_superpage(entry, level) )
+if ( level == 3 && entry.p2m.table )
Why?
Because p2m_is_superpage(...) contains p2m_is_valid(). So we would test twice
the validity of the p2m.
But I guess this is not a big deal, so I can remove it.
{
p2m->stats.mappings[level]--;
return;
@@ -951,7 +963,7 @@ static int __p2m_set_entry(struct p2m_domain *p2m,
else
p2m->need_flush = true;
}
-else /* new mapping */
+else if ( !p2m_is_valid(orig_pte) ) /* new mapping */
There are a couple of lpae_is_valid checks just above this line that you
missed, why haven't you changed them?
If you have a good reason, please explain in a comment and/or commit
message.
This is already explained in the commit message:
"This patch in
Re: [Xen-devel] [PATCH v2 2/7] x86/hvm: introduce a define for the debug output IO port
On Mon, Oct 29, 2018 at 10:51:07AM -0600, Jan Beulich wrote:
> >>> On 19.10.18 at 17:20, wrote:
> > No functional change intended.
> >
> > Signed-off-by: Roger Pau Monné
>
> Reviewed-by: Jan Beulich
> with one remark:
>
> > --- a/xen/include/public/arch-x86/xen.h
> > +++ b/xen/include/public/arch-x86/xen.h
> > @@ -346,6 +346,12 @@ struct xen_arch_domainconfig {
> > #define XEN_CPUID XEN_EMULATE_PREFIX "cpuid"
> > #endif
> >
> > +/*
> > + * Debug console IO port, also called "port E9 hack". Each character
> > written
> > + * to this IO port will be printed on the hypervisor console.
> > + */
> > +#define XEN_HVM_DEBUGCONS_IOPORT 0xe9
>
> Perhaps amend the comment with "..., subject to log level
> restrictions"? Easily done while committing.
Yes, that seems sensible, feel free to add it during commit.
> FTR I'm a little uneasy about adding this to the public
> interface, but otoh external components already use it as
> if it was part of it.
Given the current usage I think this should be part of the public
headers.
Thanks, Roger.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 22/25] xen/arm: Allow vpl011 to be used by DomU
On Mon, Oct 29, 2018 at 10:03 PM Stefano Stabellini
wrote:
>
> On Wed, 24 Oct 2018, Oleksandr Tyshchenko wrote:
> > Hi, Stefano
> >
> > On Tue, Oct 23, 2018 at 5:04 AM Stefano Stabellini
> > wrote:
> > >
> > > Make vpl011 being able to be used without a userspace component in Dom0.
> > > In that case, output is printed to the Xen serial and input is received
> > > from the Xen serial one character at a time.
> > >
> > > Call domain_vpl011_init during construct_domU if vpl011 is enabled.
> > >
> > > Introduce a new ring struct with only the ring array to avoid a waste of
> > > memory. Introduce separate read_data and write_data functions for
> > > initial domains: vpl011_write_data_xen is very simple and just writes
> > > to the console, while vpl011_read_data_xen is a duplicate of
> > > vpl011_read_data. Although textually almost identical, we are forced to
> > > duplicate the functions because the struct layout is different.
> > >
> > > Output characters are printed one by one, potentially leading to
> > > intermixed output of different domains on the console. A follow-up patch
> > > will solve the issue by introducing buffering.
> > >
> > > Signed-off-by: Stefano Stabellini
> > > Acked-by: Julien Grall
> > > ---
> > > Changes in v5:
> > > - renable call to vpl011_rx_char_xen from console.c
> > >
> > > Changes in v4:
> > > - code style
> > >
> > > Changes in v3:
> > > - add in-code comments
> > > - improve existing comments
> > > - remove ifdef around domain_vpl011_init in construct_domU
> > > - add ASSERT
> > > - use SBSA_UART_FIFO_SIZE for in buffer size
> > > - rename ring_enable to backend_in_domain
> > > - rename struct xencons_in to struct vpl011_xen_backend
> > > - rename inring field to xen
> > > - rename helper functions accordingly
> > > - remove unnecessary stub implementation of vpl011_rx_char
> > > - move vpl011_rx_char_xen within the file to avoid the need of a forward
> > > declaration of vpl011_data_avail
> > > - fix small bug in vpl011_rx_char_xen: increment in_prod before using it
> > > to check xencons_queued.
> > >
> > > Changes in v2:
> > > - only init if vpl011
> > > - rename vpl011_read_char to vpl011_rx_char
> > > - remove spurious change
> > > - fix coding style
> > > - use different ring struct
> > > - move the write_data changes to their own function
> > > (vpl011_write_data_noring)
> > > - duplicate vpl011_read_data
> > > ---
> > > xen/arch/arm/domain_build.c | 9 +-
> > > xen/arch/arm/vpl011.c| 200
> > > +--
> > > xen/drivers/char/console.c | 2 +-
> > > xen/include/asm-arm/vpl011.h | 8 ++
> > > 4 files changed, 193 insertions(+), 26 deletions(-)
> > >
> > > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > > index 6026b77..9ffd919 100644
> > > --- a/xen/arch/arm/domain_build.c
> > > +++ b/xen/arch/arm/domain_build.c
> > > @@ -2629,7 +2629,14 @@ static int __init construct_domU(struct domain *d,
> > > if ( rc < 0 )
> > > return rc;
> > >
> > > -return construct_domain(d, &kinfo);
> > > +rc = construct_domain(d, &kinfo);
> > > +if ( rc < 0 )
> > > +return rc;
> > > +
> > > +if ( kinfo.vpl011 )
> > > +rc = domain_vpl011_init(d, NULL);
> > > +
> > > +return rc;
> > > }
> > >
> > > void __init create_domUs(void)
> > > diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
> > > index 68452a8..131507e 100644
> > > --- a/xen/arch/arm/vpl011.c
> > > +++ b/xen/arch/arm/vpl011.c
> > > @@ -77,6 +77,91 @@ static void vpl011_update_interrupt_status(struct
> > > domain *d)
> > > #endif
> > > }
> > >
> > > +/*
> > > + * vpl011_write_data_xen writes chars from the vpl011 out buffer to the
> > > + * console. Only to be used when the backend is Xen.
> > > + */
> > > +static void vpl011_write_data_xen(struct domain *d, uint8_t data)
> > > +{
> > > +unsigned long flags;
> > > +struct vpl011 *vpl011 = &d->arch.vpl011;
> > > +
> > > +VPL011_LOCK(d, flags);
> > > +
> > > +printk("%c", data);
> > > +if (data == '\n')
> > > +printk("DOM%u: ", d->domain_id);
> > > +
> > > +vpl011->uartris |= TXI;
> > > +vpl011->uartfr &= ~TXFE;
> > > +vpl011_update_interrupt_status(d);
> > > +
> > > +VPL011_UNLOCK(d, flags);
> > > +}
> > > +
> > > +/*
> > > + * vpl011_read_data_xen reads data when the backend is xen. Characters
> > > + * are added to the vpl011 receive buffer by vpl011_rx_char_xen.
> > > + */
> > > +static uint8_t vpl011_read_data_xen(struct domain *d)
> > > +{
> > > +unsigned long flags;
> > > +uint8_t data = 0;
> > > +struct vpl011 *vpl011 = &d->arch.vpl011;
> > > +struct vpl011_xen_backend *intf = vpl011->backend.xen;
> > > +XENCONS_RING_IDX in_cons, in_prod;
> > > +
> > > +VPL011_LOCK(d, flags);
> > > +
> > > +in_cons = intf->in_cons;
> > > +in_prod = intf->in_prod;
> > > +
> > > +smp_rmb();
> > > +
> > > +/*
> > > + * It is expected that there will be data i
Re: [Xen-devel] [PATCH v2 3/7] x86/pvh: allow PVH Dom0 to use the debug IO port console
On Mon, Oct 29, 2018 at 11:03:37AM -0600, Jan Beulich wrote: > >>> On 29.10.18 at 17:53, wrote: > > On 19/10/18 16:20, Roger Pau Monne wrote: > >> Add an option to allow trapping accesses to IO port 0xe9 for a PVH > >> Dom0, so it can print to the HVM debug console. Note this is not > >> enabled by default in order to prevent clashes with hardware on the > >> system using 0xe9. > >> > >> Signed-off-by: Roger Pau Monné > >> --- > >> Cc: Jan Beulich > >> Cc: Andrew Cooper > >> Cc: Wei Liu > >> --- > >> Changes since v1: > >> - Use a define for 0xe9. > >> - Expand 'List of' in the Xen command doc. > > > > As said during v1, make this unconditional and do away the command line > > option. > > > > Noone with a PVH dom0 is going to have a real CoZet Info PC radio on an > > ISA bus. > > Oh, I'm sorry - I had forgotten about that request of yours, and > should hence not have given my R-b. I'm misread Andy's comment, will resend with the debug port always on. Thanks, Roger. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v8 0/8] Allow setting up shared memory areas between VMs from xl config files
Hi, Julien. On Wed, Oct 24, 2018 at 5:25 PM Julien Grall wrote: > > > > On 10/24/18 3:15 PM, Oleksandr Tyshchenko wrote: > > Hi, Stefano > > > > On Sat, Oct 20, 2018 at 12:07 AM Stefano Stabellini > > wrote: > >> > >> Hi Wei, > >> > >> Any chances you can review this series soon? I would love for it to be > >> merged before the 4.12 code freeze. > >> > >> FYI I am making progress upstreaming the device tree binding, they asked > >> for a very minor change, which I am happy to include in the next version > >> of the series: > >> > >> https://marc.info/?l=devicetree&m=153989826510707&w=2 > >> > >> > >> On Mon, 8 Oct 2018, Stefano Stabellini wrote: > >>> Hi, > >>> > >>> This series implements a new xl config entry. Users can use the new > >>> config entry to statically setup shared memory areas among VMs that > >>> don't have grant table support so that they could communicate with each > >>> other through the static shared memory areas. > >>> > >>> It was originally developed by Zhongze, I am just updating the last few > >>> issued that were address during the last round of reviews in January. I > >>> tested the feature on ARM and works fine. > >>> > >>> Cheers, > >>> > >>> Stefano > >>> > >>> > >>> Main changes in v8: > >>> - remove "add xen,dmabuf nodes" patch > >>> - add "map reserved-memory regions as normal memory in dom0" patch > >>> - send new device tree binding request to devicetree.org > >>> > >>> > >>> > >>> The following changes since commit > >>> 85b00385827e4e061b2ff38b549c03d0f1e66b6a: > >>> > >>>xen/sched: Drop set_current_state() (2018-10-08 18:34:55 +0100) > >>> > >>> are available in the git repository at: > >>> > >>> > >>> http://xenbits.xenproject.org/git-http/people/sstabellini/xen-unstable.git > >>> share_mem-v8 > >>> > >>> for you to fetch changes up to fc00e34ce9924b5915deacd881ae7cd6888510ba: > >>> > >>>xen/arm: map reserved-memory regions as normal memory in dom0 > >>> (2018-10-08 16:34:09 -0700) > >>> > >>> > >>> Stefano Stabellini (2): > >>>xen/arm: export shared memory regions as reserved-memory on device > >>> tree > >>>xen/arm: map reserved-memory regions as normal memory in dom0 > >>> > >>> Zhongze Liu (6): > >>>xen: xsm: flask: introduce XENMAPSPACE_gmfn_share for memory > >>> sharing > >>>libxl: introduce a new structure to represent static shared memory > >>> regions > >>>libxl: support mapping static shared memory areas during domain > >>> creation > >>>libxl: support unmapping static shared memory areas during domain > >>> destruction > >>>libxl:xl: add parsing code to parse "libxl_static_sshm" from xl > >>> config files > >>>docs: documentation about static shared memory regions > >>> > >>> docs/man/xl-static-shm-configuration.pod.5 | 264 +++ > >>> docs/man/xl.cfg.pod.5.in | 8 + > >>> docs/misc/xenstore-paths.markdown | 47 +++ > >>> tools/flask/policy/modules/xen.if | 2 + > >>> tools/libxl/Makefile | 5 +- > >>> tools/libxl/libxl.h| 8 + > >>> tools/libxl/libxl_arch.h | 8 +- > >>> tools/libxl/libxl_arm.c| 76 - > >>> tools/libxl/libxl_create.c | 27 ++ > >>> tools/libxl/libxl_dom.c| 2 +- > >>> tools/libxl/libxl_domain.c | 5 + > >>> tools/libxl/libxl_internal.h | 16 + > >>> tools/libxl/libxl_sshm.c | 512 > >>> + > >>> tools/libxl/libxl_types.idl| 32 +- > >>> tools/libxl/libxl_x86.c| 21 +- > >>> tools/libxl/libxlu_sshm.c | 206 > >>> tools/libxl/libxlutil.h| 6 + > >>> tools/xl/xl_parse.c| 25 +- > >>> xen/arch/arm/domain_build.c| 7 + > >>> xen/arch/arm/mm.c | 7 +- > >>> xen/include/public/memory.h| 8 + > >>> xen/include/xsm/dummy.h| 14 + > >>> xen/include/xsm/xsm.h | 6 + > >>> xen/xsm/dummy.c| 1 + > >>> xen/xsm/flask/hooks.c | 9 + > >>> xen/xsm/flask/policy/access_vectors| 5 + > >>> 26 files changed, 1315 insertions(+), 12 deletions(-) > >>> create mode 100644 docs/man/xl-static-shm-configuration.pod.5 > >>> create mode 100644 tools/libxl/libxl_sshm.c > >>> create mode 100644 tools/libxl/libxlu_sshm.c > >>> > >> > >> ___ > >> Xen-devel mailing list > >> Xen-devel@lists.xenproject.org > >> https://lists.xenproject.org/mailman/listinfo/xen-devel > > > > I have question regarding format of "begin", "size" and "offset" properties. > > Wouldn't be better to operate with page numbers rather
[Xen-devel] [PATCH 1/1] tools/ocaml: Re-introduce Xenctrl.with_intf wrapper
Commit 81946a73dc975a7dafe9017a8e61d1e64fdbedbf removed
Xenctrl.with_intf based on its undesirable behaviour of opening and
closing a Xenctrl connection with every invocation. This commit
re-introduces with_intf but with an updated behaviour: it maintains a
global Xenctrl connection which is opened upon first usage and kept
open. This handle can be obtained by clients using new functions
get_handle() and close_handle().
The main motivation of re-introducing with_intf is that otherwise
clients will have to implement this functionality individually.
Signed-off-by: Christian Lindig
---
tools/ocaml/libs/xc/xenctrl.ml | 22 ++
tools/ocaml/libs/xc/xenctrl.mli | 10 ++
2 files changed, 32 insertions(+)
diff --git a/tools/ocaml/libs/xc/xenctrl.ml b/tools/ocaml/libs/xc/xenctrl.ml
index 955dd92546..44857a2d1c 100644
--- a/tools/ocaml/libs/xc/xenctrl.ml
+++ b/tools/ocaml/libs/xc/xenctrl.ml
@@ -141,6 +141,28 @@ type handle
external interface_open: unit -> handle = "stub_xc_interface_open"
external interface_close: handle -> unit = "stub_xc_interface_close"
+let handle = ref None
+
+let get_handle () = !handle
+
+let close_handle () =
+ match !handle with
+ | Some h -> interface_close h
+ | None -> ()
+
+let with_intf f =
+ match !handle with
+ | Some h -> f h
+ | None ->
+ let h =
+ try interface_open () with
+ | e ->
+ let msg = Printexc.to_string e in
+ failwith ("failed to open xenctrl: "^msg)
+ in
+ handle := Some h;
+ f h
+
external domain_create: handle -> domctl_create_config -> domid
= "stub_xc_domain_create"
diff --git a/tools/ocaml/libs/xc/xenctrl.mli b/tools/ocaml/libs/xc/xenctrl.mli
index eeed24fa96..b31d7fefe5 100644
--- a/tools/ocaml/libs/xc/xenctrl.mli
+++ b/tools/ocaml/libs/xc/xenctrl.mli
@@ -109,6 +109,16 @@ type handle
external interface_open : unit -> handle = "stub_xc_interface_open"
external interface_close : handle -> unit = "stub_xc_interface_close"
+(** [with_intf f] runs [f] with a global handle that is opened on demand
+ * and kept open. A client should use either [interface_open]
+ * or [with_intf] but not mix both.
+ *)
+val with_intf : (handle -> 'a) -> 'a
+(** [get_handle] returns the global handle used by [with_intf] *)
+val get_handle: unit -> handle option
+(** [close handle] closes the handle maintained by [with_intf] *)
+val close_handle: unit -> unit
+
external domain_create : handle -> domctl_create_config -> domid
= "stub_xc_domain_create"
external domain_sethandle : handle -> domid -> string -> unit =
"stub_xc_domain_sethandle"
--
2.19.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 12/18] xen: setup Xen specific data for PVH
On Mon, Oct 29, 2018 at 03:19:34PM +0100, Juergen Gross wrote:
> On 29/10/2018 13:57, Roger Pau Monné wrote:
> > On Fri, Oct 19, 2018 at 06:39:50PM +0200, Juergen Gross wrote:
> >> On 19/10/2018 18:10, Roger Pau Monné wrote:
> >>> On Tue, Oct 09, 2018 at 01:03:11PM +0200, Juergen Gross wrote:
> Initialize the needed Xen specific data. This is:
>
> - the Xen start of day page containing the console and Xenstore ring
> page PFN and event channel
> - the grant table
> - the shared info page
>
> Set the RSDP address for the guest from the start_info page passed
> as boot parameter.
>
> Signed-off-by: Juergen Gross
> ---
> grub-core/kern/i386/xen/pvh.c | 107
> ++
> 1 file changed, 107 insertions(+)
>
> diff --git a/grub-core/kern/i386/xen/pvh.c
> b/grub-core/kern/i386/xen/pvh.c
> index b4933b454..93ed68245 100644
> --- a/grub-core/kern/i386/xen/pvh.c
> +++ b/grub-core/kern/i386/xen/pvh.c
> @@ -24,6 +24,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> struct xen_machine_mmap_entry
> @@ -39,6 +40,7 @@ static struct { char _entry[32]; } hypercall_page[128]
> __attribute__ ((aligned (GRUB_XEN_PAGE_SIZE)));
>
> static grub_uint32_t xen_cpuid_base;
> +static struct start_info grub_xen_start_page;
> static struct xen_machine_mmap_entry map[128];
> static unsigned int nr_map_entries;
>
> @@ -104,6 +106,36 @@ grub_xen_hypercall (grub_uint32_t callno,
> grub_uint32_t a0,
> return __res;
> }
>
> +static grub_uint32_t
> +grub_xen_get_param (int idx)
> +{
> + struct xen_hvm_param xhv;
> + int r;
> +
> + xhv.domid = DOMID_SELF;
> + xhv.index = idx;
> + r = grub_xen_hypercall (__HYPERVISOR_hvm_op, HVMOP_get_param,
> + (grub_uint32_t) (&xhv), 0, 0, 0, 0);
> + if (r < 0)
> +grub_xen_early_halt ();
> + return xhv.value;
> +}
> +
> +static void *
> +grub_xen_add_physmap (unsigned int space, void *addr)
> +{
> + struct xen_add_to_physmap xatp;
> +
> + xatp.domid = DOMID_SELF;
> + xatp.idx = 0;
> + xatp.space = space;
> + xatp.gpfn = (grub_addr_t) addr >> GRUB_XEN_LOG_PAGE_SIZE;
> + if (grub_xen_hypercall (__HYPERVISOR_memory_op, XENMEM_add_to_physmap,
> + (grub_uint32_t) (&xatp), 0, 0, 0, 0))
> +grub_xen_early_halt ();
> + return addr;
> +}
> +
> static void
> grub_xen_sort_mmap (void)
> {
> @@ -190,12 +222,87 @@ grub_xen_get_mmap (void)
> grub_xen_sort_mmap ();
> }
>
> +static grub_uint64_t
> +grub_xen_find_page (grub_uint64_t start)
> +{
> + unsigned int i, j;
> + grub_uint64_t last = start;
> +
> + /* Try to find a e820 map hole below 4G. */
> >>>
> >>> Doing this is kind of dangerous, what if you end up placing something
> >>> on top of an MMIO region (either emulated or from a real passthrough
> >>> device)?
> >>
> >> Shouldn't those be marked as "Reserved" in the memory map?
> >
> > I don't think BARs are guaranteed to be in areas marked as reserved in
> > the memory map. Unless you also scan for PCI devices and make sure
> > there's no device with a BAR in the area you are attempting to
> > populate I think the above is not safe.
>
> So either I can add scanning the PCI bus (which wouldn't be too
> hard IMO), or we require Xen tools to add memory map entries with
> "Reserved" attribute for passed-through PCI device's MMIO-areas
> (we can still do that as PCI pass-through for PVH isn't possible
> yet AFAIK).
Ideally (and that's kind of far away from what we are now), I would
like to have an interface to request Xen for a range of gfns available
to map stuff in them (grants/foreign mappings/shared page...). That
interface could be a simple hypercall that would return such range, or
an hypercall that could be used to fetch something akin to an
'extended memory map' with specific Xen information (like such
regions).
In both cases this requires Xen having a clearer picture of the p2m,
because any of the above solutions cannot rely on scanning the p2m
table in order to figure out what's where.
So the only change I would request is that if you use a RAM page you
update the memory map stored in Xen to match the new layout, by using
the XENMEM_set_memory_map hypercall.
Thanks, Roger.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PULL v2 01/20] configs/alpha: Remove unused CONFIG_PARALLEL_ISA switch
From: Thomas Huth We don't use CONFIG_PARALLEL_ISA in any of our Makefiles, so this is just a dead config option which can be removed. Fixes: a4cb773928e047b137c6998209cf2eec857fac6b Signed-off-by: Thomas Huth Acked-by: Richard Henderson Reviewed-by: Philippe Mathieu-Daudé Message-Id: <1540376314-5727-1-git-send-email-th...@redhat.com> Signed-off-by: Laurent Vivier --- default-configs/alpha-softmmu.mak | 1 - 1 file changed, 1 deletion(-) diff --git a/default-configs/alpha-softmmu.mak b/default-configs/alpha-softmmu.mak index eb58b40254..4d654eaa0b 100644 --- a/default-configs/alpha-softmmu.mak +++ b/default-configs/alpha-softmmu.mak @@ -8,7 +8,6 @@ CONFIG_I82374=y CONFIG_I8254=y CONFIG_I8257=y CONFIG_PARALLEL=y -CONFIG_PARALLEL_ISA=y CONFIG_FDC=y CONFIG_PCKBD=y CONFIG_VGA_CIRRUS=y -- 2.17.2 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PULL v2 16/20] tests/bios-tables-test: Remove an useless cast
From: Philippe Mathieu-Daudé
Patch created mechanically by rerunning:
$ spatch --sp-file scripts/coccinelle/typecast.cocci \
--macro-file scripts/cocci-macro-file.h \
--dir . --in-place
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Markus Armbruster
Acked-by: Michael S. Tsirkin
Message-Id: <20180705155811.20366-5-f4...@amsat.org>
Signed-off-by: Laurent Vivier
---
tests/bios-tables-test.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/bios-tables-test.c b/tests/bios-tables-test.c
index af4b1fb6bd..02e77ec811 100644
--- a/tests/bios-tables-test.c
+++ b/tests/bios-tables-test.c
@@ -319,7 +319,7 @@ static bool load_asl(GArray *sdts, AcpiSdtTable *sdt)
ret = g_spawn_command_line_sync(command_line->str, &out, &out_err, NULL,
&error);
g_assert_no_error(error);
if (ret) {
-ret = g_file_get_contents(sdt->asl_file, (gchar **)&sdt->asl,
+ret = g_file_get_contents(sdt->asl_file, &sdt->asl,
&sdt->asl_len, &error);
g_assert(ret);
g_assert_no_error(error);
--
2.17.2
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PULL v2 13/20] configure: Support pkg-config for zlib
From: Stefan Weil
This is needed for builds with the mingw64-* packages from Cygwin,
but also works for Linux.
Move the zlib test also more to the end because users should
get information on the really important missing packages
(which also require zlib) first.
Signed-off-by: Stefan Weil
Reviewed-by: Stefan Hajnoczi
Message-Id: <20180712192603.11599-1...@weilnetz.de>
Signed-off-by: Laurent Vivier
---
configure | 40 +++-
1 file changed, 23 insertions(+), 17 deletions(-)
diff --git a/configure b/configure
index 1ee09bd112..a02df30dde 100755
--- a/configure
+++ b/configure
@@ -2151,23 +2151,6 @@ EOF
fi
fi
-#
-# zlib check
-
-if test "$zlib" != "no" ; then
-cat > $TMPC << EOF
-#include
-int main(void) { zlibVersion(); return 0; }
-EOF
-if compile_prog "" "-lz" ; then
-:
-else
-error_exit "zlib check failed" \
-"Make sure to have the zlib libs and headers installed."
-fi
-fi
-LIBS="$LIBS -lz"
-
##
# lzo check
@@ -3479,6 +3462,29 @@ if ! compile_prog "$glib_cflags -Werror" "$glib_libs" ;
then
fi
fi
+#
+# zlib check
+
+if test "$zlib" != "no" ; then
+if $pkg_config --exists zlib; then
+zlib_cflags=$($pkg_config --cflags zlib)
+zlib_libs=$($pkg_config --libs zlib)
+QEMU_CFLAGS="$zlib_cflags $QEMU_CFLAGS"
+LIBS="$zlib_libs $LIBS"
+else
+cat > $TMPC << EOF
+#include
+int main(void) { zlibVersion(); return 0; }
+EOF
+if compile_prog "" "-lz" ; then
+LIBS="$LIBS -lz"
+else
+error_exit "zlib check failed" \
+"Make sure to have the zlib libs and headers installed."
+fi
+fi
+fi
+
##
# SHA command probe for modules
if test "$modules" = yes; then
--
2.17.2
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PULL v2 03/20] memory.h: fix typos in comments
From: Li Qiang Signed-off-by: Li Qiang Reviewed-by: Peter Maydell Message-Id: <1539080467-2976-1-git-send-email-liq...@gmail.com> [lv: s/types/typos/] Signed-off-by: Laurent Vivier --- include/exec/memory.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/include/exec/memory.h b/include/exec/memory.h index 667466b8f3..d0c7f0d9e9 100644 --- a/include/exec/memory.h +++ b/include/exec/memory.h @@ -935,7 +935,7 @@ uint64_t memory_region_size(MemoryRegion *mr); /** * memory_region_is_ram: check whether a memory region is random access * - * Returns %true is a memory region is random access. + * Returns %true if a memory region is random access. * * @mr: the memory region being queried */ @@ -947,7 +947,7 @@ static inline bool memory_region_is_ram(MemoryRegion *mr) /** * memory_region_is_ram_device: check whether a memory region is a ram device * - * Returns %true is a memory region is a device backed ram region + * Returns %true if a memory region is a device backed ram region * * @mr: the memory region being queried */ @@ -1161,7 +1161,7 @@ uint8_t memory_region_get_dirty_log_mask(MemoryRegion *mr); /** * memory_region_is_rom: check whether a memory region is ROM * - * Returns %true is a memory region is read-only memory. + * Returns %true if a memory region is read-only memory. * * @mr: the memory region being queried */ -- 2.17.2 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PULL v2 12/20] tests: Fix typos in comments and help message (found by codespell)
From: Stefan Weil
Fix also a grammar issue.
Signed-off-by: Stefan Weil
Reviewed-by: Alex Bennée
Message-Id: <20180713054755.23323-1...@weilnetz.de>
Signed-off-by: Laurent Vivier
---
tests/bios-tables-test.c | 2 +-
tests/docker/Makefile.include | 2 +-
tests/docker/docker.py| 4 ++--
tests/guest-debug/test-gdbstub.py | 2 +-
tests/qemu-iotests/common.qemu| 2 +-
tests/tcg/Makefile.include| 2 +-
tests/tcg/Makefile.probe | 2 +-
tests/tcg/mips/mips64-dsp/subq_s_pw.c | 2 +-
8 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/tests/bios-tables-test.c b/tests/bios-tables-test.c
index 4e24930c4b..af4b1fb6bd 100644
--- a/tests/bios-tables-test.c
+++ b/tests/bios-tables-test.c
@@ -390,7 +390,7 @@ try_again:
if (g_file_test(aml_file, G_FILE_TEST_EXISTS)) {
exp_sdt.aml_file = aml_file;
} else if (*ext != '\0') {
-/* try fallback to generic (extention less) expected file */
+/* try fallback to generic (extension less) expected file */
ext = "";
g_free(aml_file);
goto try_again;
diff --git a/tests/docker/Makefile.include b/tests/docker/Makefile.include
index 6e03235ab9..9467e9d088 100644
--- a/tests/docker/Makefile.include
+++ b/tests/docker/Makefile.include
@@ -41,7 +41,7 @@ docker-qemu-src: $(DOCKER_SRC_COPY)
docker-image: ${DOCKER_TARGETS}
# General rule for building docker images. If we are a sub-make
-# invoked with SKIP_DOCKER_BUILD we still check the image is upto date
+# invoked with SKIP_DOCKER_BUILD we still check the image is up to date
# though
ifdef SKIP_DOCKER_BUILD
docker-image-%: $(DOCKER_FILES_DIR)/%.docker
diff --git a/tests/docker/docker.py b/tests/docker/docker.py
index 44d5f7493b..02d8a83847 100755
--- a/tests/docker/docker.py
+++ b/tests/docker/docker.py
@@ -97,7 +97,7 @@ def _get_so_libs(executable):
return libs
def _copy_binary_with_libs(src, dest_dir):
-"""Copy a binary executable and all its dependant libraries.
+"""Copy a binary executable and all its dependent libraries.
This does rely on the host file-system being fairly multi-arch
aware so the file don't clash with the guests layout."""
@@ -284,7 +284,7 @@ class SubCommand(object):
name = None # Subcommand name
def shared_args(self, parser):
parser.add_argument("--quiet", action="store_true",
-help="Run quietly unless an error occured")
+help="Run quietly unless an error occurred")
def args(self, parser):
"""Setup argument parser"""
diff --git a/tests/guest-debug/test-gdbstub.py
b/tests/guest-debug/test-gdbstub.py
index 474d2c5c65..0e4ac01426 100644
--- a/tests/guest-debug/test-gdbstub.py
+++ b/tests/guest-debug/test-gdbstub.py
@@ -122,7 +122,7 @@ class CatchBreakpoint(gdb.Breakpoint):
def run_test():
-"Run throught the tests one by one"
+"Run through the tests one by one"
print ("Checking we can step the first few instructions")
step_ok = 0
diff --git a/tests/qemu-iotests/common.qemu b/tests/qemu-iotests/common.qemu
index f285484951..dadde2a266 100644
--- a/tests/qemu-iotests/common.qemu
+++ b/tests/qemu-iotests/common.qemu
@@ -257,7 +257,7 @@ function _launch_qemu()
}
-# Silenty kills the QEMU process
+# Silently kills the QEMU process
#
# If $wait is set to anything other than the empty string, the process will not
# be killed but only waited for, and any output will be forwarded to stdout. If
diff --git a/tests/tcg/Makefile.include b/tests/tcg/Makefile.include
index 57470b2a2c..c581bd6ffc 100644
--- a/tests/tcg/Makefile.include
+++ b/tests/tcg/Makefile.include
@@ -2,7 +2,7 @@
#
# TCG tests (per-target rules)
#
-# This Makefile fragement is included from the per-target
+# This Makefile fragment is included from the per-target
# Makefile.target so will be invoked for each linux-user program we
# build. We have two options for compiling, either using a configured
# guest compiler or calling one of our docker images to do it for us.
diff --git a/tests/tcg/Makefile.probe b/tests/tcg/Makefile.probe
index 15c0412657..9dc654663d 100644
--- a/tests/tcg/Makefile.probe
+++ b/tests/tcg/Makefile.probe
@@ -2,7 +2,7 @@
#
# TCG Compiler Probe
#
-# This Makefile fragement is included multiple times in the main make
+# This Makefile fragment is included multiple times in the main make
# script to probe for available compilers. This is used to build up a
# selection of required docker targets before we invoke a sub-make for
# each target.
diff --git a/tests/tcg/mips/mips64-dsp/subq_s_pw.c
b/tests/tcg/mips/mips64-dsp/subq_s_pw.c
index e8e0b0567e..4c080b785a 100644
--- a/tests/tcg/mips/mips64-dsp/subq_s_pw.c
+++ b/tests/tcg/mips/mips64-dsp/subq_s_pw.c
@@ -24,7 +24,7 @@ int main(void)
rt = 0x123456789ABCDEF1;
rs = 0x123456789ABCDEF2;
result = 0x0001;
-/* This time we do
[Xen-devel] [PULL v2 04/20] tests/tcg/README: fix location for lm32 tests
From: Cleber Rosa Point to the right and obvious location for lm32 tests. Signed-off-by: Cleber Rosa Reviewed-by: Thomas Huth Acked-by: Alex Bennée Message-Id: <20181004161852.11673-3-cr...@redhat.com> Signed-off-by: Laurent Vivier --- tests/tcg/README | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/tcg/README b/tests/tcg/README index a5643d33e7..2a58f9a058 100644 --- a/tests/tcg/README +++ b/tests/tcg/README @@ -10,6 +10,6 @@ with "make test-cris". LM32 -The testsuite for LM32 is in tests/tcg/cris. You can run it +The testsuite for LM32 is in tests/tcg/lm32. You can run it with "make test-lm32". -- 2.17.2 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PULL v2 05/20] qemu-iotests: fix filename containing checks
From: Cleber Rosa Commit cce293a2945 moved some functions from common.config to common.rc, but the error messages still reference the old file location. Signed-off-by: Cleber Rosa Reviewed-by: Max Reitz Reviewed-by: Philippe Mathieu-Daudé Message-Id: <20181004161852.11673-5-cr...@redhat.com> Signed-off-by: Laurent Vivier --- tests/qemu-iotests/common.rc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tests/qemu-iotests/common.rc b/tests/qemu-iotests/common.rc index 44bee16a5e..70ca65b49b 100644 --- a/tests/qemu-iotests/common.rc +++ b/tests/qemu-iotests/common.rc @@ -170,7 +170,7 @@ if [ ! -e "$TEST_DIR" ]; then fi if [ ! -d "$TEST_DIR" ]; then -echo "common.config: Error: \$TEST_DIR ($TEST_DIR) is not a directory" +echo "common.rc: Error: \$TEST_DIR ($TEST_DIR) is not a directory" exit 1 fi @@ -179,7 +179,7 @@ if [ -z "$REMOTE_TEST_DIR" ]; then fi if [ ! -d "$SAMPLE_IMG_DIR" ]; then -echo "common.config: Error: \$SAMPLE_IMG_DIR ($SAMPLE_IMG_DIR) is not a directory" +echo "common.rc: Error: \$SAMPLE_IMG_DIR ($SAMPLE_IMG_DIR) is not a directory" exit 1 fi -- 2.17.2 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PULL v2 02/20] vga_int: remove unused function protype
From: yuchenlin Signed-off-by: yuchenlin Reviewed-by: Philippe Mathieu-Daudé Message-Id: <20181022080053.9379-1-yuchen...@synology.com> Signed-off-by: Laurent Vivier --- hw/display/vga_int.h | 1 - 1 file changed, 1 deletion(-) diff --git a/hw/display/vga_int.h b/hw/display/vga_int.h index 6e4fa48a79..55c418eab5 100644 --- a/hw/display/vga_int.h +++ b/hw/display/vga_int.h @@ -166,7 +166,6 @@ MemoryRegion *vga_init_io(VGACommonState *s, Object *obj, const MemoryRegionPortio **vbe_ports); void vga_common_reset(VGACommonState *s); -void vga_sync_dirty_bitmap(VGACommonState *s); void vga_dirty_log_start(VGACommonState *s); void vga_dirty_log_stop(VGACommonState *s); -- 2.17.2 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PULL v2 08/20] scripts/qemu.py: remove trailing quotes on docstring
From: Cleber Rosa Signed-off-by: Cleber Rosa Reviewed-by: Philippe Mathieu-Daudé Message-Id: <20181004161852.11673-11-cr...@redhat.com> Signed-off-by: Laurent Vivier --- scripts/qemu.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/qemu.py b/scripts/qemu.py index f099ce7278..b0b2f12ce6 100644 --- a/scripts/qemu.py +++ b/scripts/qemu.py @@ -87,7 +87,7 @@ class QEMUMachine(object): @param name: prefix for socket and log file names (default: qemu-PID) @param test_dir: where to create socket and log file @param monitor_address: address for QMP monitor -@param socket_scm_helper: helper program, required for send_fd_scm()" +@param socket_scm_helper: helper program, required for send_fd_scm() @note: Qemu process is not started until launch() is used. ''' if args is None: -- 2.17.2 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PULL v2 11/20] cpu.h: fix a typo in comment
From: Li Qiang Found by reading the code. Signed-off-by: Li Qiang Message-Id: <1536150548-2797-1-git-send-email-liq...@gmail.com> Signed-off-by: Laurent Vivier --- include/qom/cpu.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/qom/cpu.h b/include/qom/cpu.h index 4e238b0d9f..def0c64308 100644 --- a/include/qom/cpu.h +++ b/include/qom/cpu.h @@ -852,7 +852,7 @@ extern CPUInterruptHandler cpu_interrupt_handler; /** * cpu_interrupt: * @cpu: The CPU to set an interrupt on. - * @mask: The interupts to set. + * @mask: The interrupts to set. * * Invokes the interrupt handler. */ -- 2.17.2 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PULL v2 14/20] qobject: Catch another straggler for use of qdict_put_str()
From: Philippe Mathieu-Daudé
Patch created mechanically by rerunning:
$ spatch --sp-file scripts/coccinelle/qobject.cocci \
--macro-file scripts/cocci-macro-file.h \
--dir . --in-place
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Markus Armbruster
Acked-by: Michael S. Tsirkin
Message-Id: <20180705155811.20366-2-f4...@amsat.org>
Signed-off-by: Laurent Vivier
---
qobject/block-qdict.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/qobject/block-qdict.c b/qobject/block-qdict.c
index 42054cc274..1487cc5dd8 100644
--- a/qobject/block-qdict.c
+++ b/qobject/block-qdict.c
@@ -577,7 +577,7 @@ static QObject *qdict_crumple_for_keyval_qiv(QDict *src,
Error **errp)
if (!tmp) {
tmp = qdict_clone_shallow(src);
}
-qdict_put(tmp, ent->key, qstring_from_str(s));
+qdict_put_str(tmp, ent->key, s);
g_free(buf);
}
--
2.17.2
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PULL v2 17/20] hw/pci-host: Remove useless parenthesis around DIV_ROUND_UP macro
From: Philippe Mathieu-Daudé
Patch created mechanically by rerunning:
$ spatch --sp-file scripts/coccinelle/round.cocci \
--macro-file scripts/cocci-macro-file.h \
--dir . --in-place
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Markus Armbruster
Acked-by: Michael S. Tsirkin
Message-Id: <20180705155811.20366-7-f4...@amsat.org>
Signed-off-by: Laurent Vivier
---
hw/pci-host/piix.c | 2 +-
hw/pci-host/q35.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/pci-host/piix.c b/hw/pci-host/piix.c
index da73743fa2..47293a3915 100644
--- a/hw/pci-host/piix.c
+++ b/hw/pci-host/piix.c
@@ -144,7 +144,7 @@ static void i440fx_update_memory_mappings(PCII440FXState *d)
memory_region_transaction_begin();
for (i = 0; i < 13; i++) {
pam_update(&d->pam_regions[i], i,
- pd->config[I440FX_PAM + (DIV_ROUND_UP(i, 2))]);
+ pd->config[I440FX_PAM + DIV_ROUND_UP(i, 2)]);
}
memory_region_set_enabled(&d->smram_region,
!(pd->config[I440FX_SMRAM] & SMRAM_D_OPEN));
diff --git a/hw/pci-host/q35.c b/hw/pci-host/q35.c
index 8ce1e09932..966a7cf92d 100644
--- a/hw/pci-host/q35.c
+++ b/hw/pci-host/q35.c
@@ -356,7 +356,7 @@ static void mch_update_pam(MCHPCIState *mch)
memory_region_transaction_begin();
for (i = 0; i < 13; i++) {
pam_update(&mch->pam_regions[i], i,
- pd->config[MCH_HOST_BRIDGE_PAM0 + (DIV_ROUND_UP(i, 2))]);
+ pd->config[MCH_HOST_BRIDGE_PAM0 + DIV_ROUND_UP(i, 2)]);
}
memory_region_transaction_commit();
}
--
2.17.2
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PULL v2 15/20] xen: Use the PCI_DEVICE macro
From: Philippe Mathieu-Daudé
TYPE_XEN_PT_DEVICE is a subclass of TYPE_PCI_DEVICE, the clean way
to access the PCIDevice pointer is using the PCI_DEVICE() macro.
Suggested-by: Peter Maydell
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Markus Armbruster
Acked-by: Anthony PERARD
Acked-by: Michael S. Tsirkin
Message-Id: <20180705155811.20366-4-f4...@amsat.org>
Signed-off-by: Laurent Vivier
---
hw/xen/xen_pt_config_init.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/hw/xen/xen_pt_config_init.c b/hw/xen/xen_pt_config_init.c
index aee31c62bb..47f9010c75 100644
--- a/hw/xen/xen_pt_config_init.c
+++ b/hw/xen/xen_pt_config_init.c
@@ -358,7 +358,7 @@ static uint64_t xen_pt_get_bar_size(PCIIORegion *r)
static XenPTBarFlag xen_pt_bar_reg_parse(XenPCIPassthroughState *s,
int index)
{
-PCIDevice *d = &s->dev;
+PCIDevice *d = PCI_DEVICE(s);
XenPTRegion *region = NULL;
PCIIORegion *r;
@@ -469,7 +469,7 @@ static int xen_pt_bar_reg_write(XenPCIPassthroughState *s,
XenPTReg *cfg_entry,
{
XenPTRegInfo *reg = cfg_entry->reg;
XenPTRegion *base = NULL;
-PCIDevice *d = &s->dev;
+PCIDevice *d = PCI_DEVICE(s);
const PCIIORegion *r;
uint32_t writable_mask = 0;
uint32_t bar_emu_mask = 0;
@@ -543,7 +543,7 @@ static int
xen_pt_exp_rom_bar_reg_write(XenPCIPassthroughState *s,
{
XenPTRegInfo *reg = cfg_entry->reg;
XenPTRegion *base = NULL;
-PCIDevice *d = (PCIDevice *)&s->dev;
+PCIDevice *d = PCI_DEVICE(s);
uint32_t writable_mask = 0;
uint32_t throughable_mask = get_throughable_mask(s, reg, valid_mask);
pcibus_t r_size = 0;
@@ -1587,7 +1587,7 @@ static int xen_pt_pcie_size_init(XenPCIPassthroughState
*s,
const XenPTRegGroupInfo *grp_reg,
uint32_t base_offset, uint8_t *size)
{
-PCIDevice *d = &s->dev;
+PCIDevice *d = PCI_DEVICE(s);
uint8_t version = get_capability_version(s, base_offset);
uint8_t type = get_device_type(s, base_offset);
uint8_t pcie_size = 0;
--
2.17.2
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PULL v2 10/20] linux-user: fix comment s/atomic_write/atomic_set/
From: "Emilio G. Cota"
Signed-off-by: Emilio G. Cota
Message-Id: <20180811211011.6277-1-c...@braap.org>
Signed-off-by: Laurent Vivier
---
linux-user/qemu.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/linux-user/qemu.h b/linux-user/qemu.h
index 1beb6a2cfc..dde3f26f5a 100644
--- a/linux-user/qemu.h
+++ b/linux-user/qemu.h
@@ -143,7 +143,7 @@ typedef struct TaskState {
/* Nonzero if process_pending_signals() needs to do something (either
* handle a pending signal or unblock signals).
* This flag is written from a signal handler so should be accessed via
- * the atomic_read() and atomic_write() functions. (It is not accessed
+ * the atomic_read() and atomic_set() functions. (It is not accessed
* from multiple threads.)
*/
int signal_pending;
--
2.17.2
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PULL v2 06/20] docs/devel/testing.rst: add missing newlines after code block
From: Cleber Rosa The line immediate following a ".. code::" block is considered to contains arguments to the "code directive". The lack of a new line gives me during at parse time: testing.rst:63: (ERROR/3) Error in "code" directive: maximum 1 argument(s) allowed, 3 supplied. .. code:: make check-unit V=1 testing.rst:120: (ERROR/3) Error in "code" directive: maximum 1 argument(s) allowed, 3 supplied. .. code:: make check-qtest V=1 Let's add the missing newlines, both for consistency and to avoid the parsing errors. Signed-off-by: Cleber Rosa Reviewed-by: John Snow Message-Id: <20181004161852.11673-6-cr...@redhat.com> Signed-off-by: Laurent Vivier --- docs/devel/testing.rst | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/devel/testing.rst b/docs/devel/testing.rst index fcfad87614..a227754f86 100644 --- a/docs/devel/testing.rst +++ b/docs/devel/testing.rst @@ -59,6 +59,7 @@ variable (which affects memory reclamation and catches invalid pointers better) and gtester options. If necessary, you can run .. code:: + make check-unit V=1 and copy the actual command line which executes the unit test, then run @@ -116,6 +117,7 @@ and using gdb on the test is still simple to do: find out the actual command from the output of .. code:: + make check-qtest V=1 which you can run manually. -- 2.17.2 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PULL v2 00/20] Qemu trivial for 3.1 patches
The following changes since commit 808ebd66e467f77c0d1f8c6346235f81e9c99cf2: Merge remote-tracking branch 'remotes/riscv/tags/riscv-for-master-3.1-sf0' into staging (2018-10-25 17:41:03 +0100) are available in the Git repository at: git://github.com/vivier/qemu.git tags/qemu-trivial-for-3.1-pull-request for you to fetch changes up to 7b2b797cf0addac789ba858fdbd95c55128d72d5: milkymist-minimac2: Use qemu_log_mask(GUEST_ERROR) instead of error_report (2018-10-30 09:13:31 +0100) QEMU trivial patches collected between June and October 2018 (Thank you to Thomas Huth) v2: fix 32bit build with updated patch (v3) from Philippe Mathieu-Daudé built in a 32bit debian sid chroot Cleber Rosa (6): tests/tcg/README: fix location for lm32 tests qemu-iotests: fix filename containing checks docs/devel/testing.rst: add missing newlines after code block scripts/decodetree.py: remove unused imports scripts/qemu.py: remove trailing quotes on docstring qemu-iotests: make 218 executable Emilio G. Cota (1): linux-user: fix comment s/atomic_write/atomic_set/ Li Qiang (2): memory.h: fix typos in comments cpu.h: fix a typo in comment Paolo Bonzini (1): ppc: move at24c to its own CONFIG_ symbol Philippe Mathieu-Daudé (6): qobject: Catch another straggler for use of qdict_put_str() xen: Use the PCI_DEVICE macro tests/bios-tables-test: Remove an useless cast hw/pci-host: Remove useless parenthesis around DIV_ROUND_UP macro hw/intc/gicv3: Remove useless parenthesis around DIV_ROUND_UP macro milkymist-minimac2: Use qemu_log_mask(GUEST_ERROR) instead of error_report Stefan Weil (2): tests: Fix typos in comments and help message (found by codespell) configure: Support pkg-config for zlib Thomas Huth (1): configs/alpha: Remove unused CONFIG_PARALLEL_ISA switch yuchenlin (1): vga_int: remove unused function protype configure | 40 +++ default-configs/alpha-softmmu.mak | 1 - default-configs/ppc-softmmu.mak | 1 + docs/devel/testing.rst| 2 ++ hw/display/vga_int.h | 1 - hw/net/milkymist-minimac2.c | 15 ++ hw/nvram/Makefile.objs| 2 +- hw/pci-host/piix.c| 2 +- hw/pci-host/q35.c | 2 +- hw/xen/xen_pt_config_init.c | 8 +++--- include/exec/memory.h | 6 ++-- include/hw/intc/arm_gicv3_common.h| 2 +- include/qom/cpu.h | 2 +- linux-user/qemu.h | 2 +- qobject/block-qdict.c | 2 +- scripts/decodetree.py | 2 -- scripts/qemu.py | 2 +- tests/bios-tables-test.c | 4 +-- tests/docker/Makefile.include | 2 +- tests/docker/docker.py| 4 +-- tests/guest-debug/test-gdbstub.py | 2 +- tests/qemu-iotests/218| 0 tests/qemu-iotests/common.qemu| 2 +- tests/qemu-iotests/common.rc | 4 +-- tests/tcg/Makefile.include| 2 +- tests/tcg/Makefile.probe | 2 +- tests/tcg/README | 2 +- tests/tcg/mips/mips64-dsp/subq_s_pw.c | 2 +- 28 files changed, 64 insertions(+), 54 deletions(-) mode change 100644 => 100755 tests/qemu-iotests/218 -- 2.17.2 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PULL v2 09/20] qemu-iotests: make 218 executable
From: Cleber Rosa Commit 990dc39c made all tests executable at the time, but 218 came in later, and missing those permissions. Signed-off-by: Cleber Rosa Message-Id: <20181004161852.11673-4-cr...@redhat.com> Signed-off-by: Laurent Vivier --- tests/qemu-iotests/218 | 0 1 file changed, 0 insertions(+), 0 deletions(-) mode change 100644 => 100755 tests/qemu-iotests/218 diff --git a/tests/qemu-iotests/218 b/tests/qemu-iotests/218 old mode 100644 new mode 100755 -- 2.17.2 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC 08/16] xen/arm: p2m: Handle translation fault in get_page_from_gva
On 30/10/2018 00:47, Stefano Stabellini wrote:
On Mon, 8 Oct 2018, Julien Grall wrote:
+return NULL;
+}
+
+/*
+ * Check permission that are assumed by the caller. For instance
+ * in case of guestcopy, the caller assumes that the translated
+ * page can be accessed with the requested permissions. If this
+ * is not the case, we should fail.
+ *
+ * Please note that we do not check for the GV2M_EXEC
+ * permission. This is fine because the hardware-based translation
+ * instruction does not test for execute permissions.
+ */
+if ( (flags & GV2M_WRITE) && !(perms & GV2M_WRITE) )
+return NULL;
+
+mfn = p2m_lookup(d, gaddr_to_gfn(ipa), &t);
+if ( mfn_eq(INVALID_MFN, mfn) )
+return NULL;
+
+/* We consider that RAM is always mapped read-write */
Is the RW assumption required? I can think of a case where RAM is mapped
RO at stage2.
Just laziness for a first implementation. I will see how I can fix it.
}
+else
+mfn = maddr_to_mfn(maddr);
-if ( !mfn_valid(maddr_to_mfn(maddr)) )
+if ( !mfn_valid(mfn) )
{
dprintk(XENLOG_G_DEBUG, "%pv: Invalid MFN %#"PRI_mfn"\n",
-v, mfn_x(maddr_to_mfn(maddr)));
+v, mfn_x(mfn));
return NULL;
}
-page = mfn_to_page(maddr_to_mfn(maddr));
+page = mfn_to_page(mfn);
ASSERT(page);
if ( unlikely(!get_page(page, d)) )
--
2.11.0
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PULL v2 18/20] hw/intc/gicv3: Remove useless parenthesis around DIV_ROUND_UP macro
From: Philippe Mathieu-Daudé Patch created mechanically by rerunning: $ spatch --sp-file scripts/coccinelle/round.cocci \ --macro-file scripts/cocci-macro-file.h \ --dir . --in-place Signed-off-by: Philippe Mathieu-Daudé Acked-by: Michael S. Tsirkin Message-Id: <20180705155811.20366-8-f4...@amsat.org> Signed-off-by: Laurent Vivier --- include/hw/intc/arm_gicv3_common.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/hw/intc/arm_gicv3_common.h b/include/hw/intc/arm_gicv3_common.h index b798486ecf..31ec9a1ae4 100644 --- a/include/hw/intc/arm_gicv3_common.h +++ b/include/hw/intc/arm_gicv3_common.h @@ -62,7 +62,7 @@ * avoids bugs where we forget to subtract GIC_INTERNAL from an * interrupt number. */ -#define GICV3_BMP_SIZE (DIV_ROUND_UP(GICV3_MAXIRQ, 32)) +#define GICV3_BMP_SIZE DIV_ROUND_UP(GICV3_MAXIRQ, 32) #define GIC_DECLARE_BITMAP(name) \ uint32_t name[GICV3_BMP_SIZE] -- 2.17.2 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PULL v2 07/20] scripts/decodetree.py: remove unused imports
From: Cleber Rosa Signed-off-by: Cleber Rosa Reviewed-by: Philippe Mathieu-Daudé Message-Id: <20181004161852.11673-8-cr...@redhat.com> Signed-off-by: Laurent Vivier --- scripts/decodetree.py | 2 -- 1 file changed, 2 deletions(-) diff --git a/scripts/decodetree.py b/scripts/decodetree.py index 277f9a9bba..457cffea90 100755 --- a/scripts/decodetree.py +++ b/scripts/decodetree.py @@ -149,12 +149,10 @@ # trans_addl_i(ctx, &arg_opi, insn) # -import io import os import re import sys import getopt -import pdb insnwidth = 32 insnmask = 0x -- 2.17.2 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PULL v2 19/20] ppc: move at24c to its own CONFIG_ symbol
From: Paolo Bonzini AT24c EEPROM is currently gated by CONFIG_I2C, and as such it is being included in all emulators that use I2C, even if they do not really need it. Separate it and, since it was added for the e500 machines, add it to qemu-system-ppc and qemu-system-ppc64. Signed-off-by: Paolo Bonzini Reviewed-by: Philippe Mathieu-Daudé Reviewed-by: Thomas Huth Message-Id: <20180522191743.12872-1-pbonz...@redhat.com> [lv: rebase] Signed-off-by: Laurent Vivier --- default-configs/ppc-softmmu.mak | 1 + hw/nvram/Makefile.objs | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/default-configs/ppc-softmmu.mak b/default-configs/ppc-softmmu.mak index 3181bbf163..23d871fb3e 100644 --- a/default-configs/ppc-softmmu.mak +++ b/default-configs/ppc-softmmu.mak @@ -28,6 +28,7 @@ CONFIG_SM501=y CONFIG_DDC=y CONFIG_IDE_SII3112=y CONFIG_I2C=y +CONFIG_AT24C=y CONFIG_BITBANG_I2C=y CONFIG_M41T80=y CONFIG_VGA_CIRRUS=y diff --git a/hw/nvram/Makefile.objs b/hw/nvram/Makefile.objs index a912d25391..b318e53a43 100644 --- a/hw/nvram/Makefile.objs +++ b/hw/nvram/Makefile.objs @@ -1,6 +1,6 @@ common-obj-$(CONFIG_DS1225Y) += ds1225y.o common-obj-y += eeprom93xx.o -common-obj-$(CONFIG_I2C) += eeprom_at24c.o +common-obj-$(CONFIG_AT24C) += eeprom_at24c.o common-obj-y += fw_cfg.o common-obj-y += chrp_nvram.o common-obj-$(CONFIG_MAC_NVRAM) += mac_nvram.o -- 2.17.2 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PULL v2 20/20] milkymist-minimac2: Use qemu_log_mask(GUEST_ERROR) instead of error_report
From: Philippe Mathieu-Daudé
qemu_log_mask(GUEST_ERROR) is more appropriate:
$ qemu -d help
Log items (comma separated):
guest_errorslog when the guest OS does something invalid (eg accessing a
non-existent register)
Signed-off-by: Philippe Mathieu-Daudé
Acked-by: Michael Walle
Message-Id: <20181029130034.26750-1-f4...@amsat.org>
Signed-off-by: Laurent Vivier
---
hw/net/milkymist-minimac2.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/hw/net/milkymist-minimac2.c b/hw/net/milkymist-minimac2.c
index 3eaa19dfde..664ac34f25 100644
--- a/hw/net/milkymist-minimac2.c
+++ b/hw/net/milkymist-minimac2.c
@@ -30,6 +30,7 @@
#include "hw/sysbus.h"
#include "trace.h"
#include "net/net.h"
+#include "qemu/log.h"
#include "qemu/error-report.h"
#include
@@ -214,7 +215,8 @@ static size_t assemble_frame(uint8_t *buf, size_t size,
uint32_t crc;
if (size < payload_size + 12) {
-error_report("milkymist_minimac2: received too big ethernet frame");
+qemu_log_mask(LOG_GUEST_ERROR, "milkymist_minimac2: frame too big "
+ "(%zd bytes)\n", payload_size);
return 0;
}
@@ -347,8 +349,9 @@ minimac2_read(void *opaque, hwaddr addr, unsigned size)
break;
default:
-error_report("milkymist_minimac2: read access to unknown register 0x"
-TARGET_FMT_plx, addr << 2);
+qemu_log_mask(LOG_GUEST_ERROR,
+ "milkymist_minimac2_rd%d: 0x%" HWADDR_PRIx "\n",
+ size, addr << 2);
break;
}
@@ -413,8 +416,10 @@ minimac2_write(void *opaque, hwaddr addr, uint64_t value,
break;
default:
-error_report("milkymist_minimac2: write access to unknown register 0x"
-TARGET_FMT_plx, addr << 2);
+qemu_log_mask(LOG_GUEST_ERROR,
+ "milkymist_minimac2_wr%d: 0x%" HWADDR_PRIx
+ " = 0x%" PRIx64 "\n",
+ size, addr << 2, value);
break;
}
}
--
2.17.2
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5] arch/x86: Add registers to vm_event
>>> On 30.10.18 at 11:07, wrote:
> --- a/xen/include/public/vm_event.h
> +++ b/xen/include/public/vm_event.h
> @@ -29,7 +29,7 @@
>
> #include "xen.h"
>
> -#define VM_EVENT_INTERFACE_VERSION 0x0003
> +#define VM_EVENT_INTERFACE_VERSION 0x0004
>
> #if defined(__XEN__) || defined(__XEN_TOOLS__)
>
> @@ -157,6 +157,12 @@
> #define VM_EVENT_X86_CR42
> #define VM_EVENT_X86_XCR0 3
>
> +/* The limit field is right-shifted by 12 bits if .ar.g is set. */
> +struct x86_selector_reg {
I'm sorry for not having noticed this earlier, but this needs proper
prefixing: Matching struct vm_event_regs_x86, it should at least
be prefixed by vm_event_. Strictly speaking xen_ as the very
first thing would also be required, but I'll leave that to the VM
event maintainers to decide. With this
Reviewed-by: Jan Beulich
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] x86/pv: Fix crash when using `xl set-parameter pcid=...`
"pcid=" is registered as a runtime parameter, which means that parse_pcid()
must not reside in .init, or the following happens when parse_params() tries
to call an unmapped function pointer.
(XEN) [ Xen-4.12-unstable x86_64 debug=y Not tainted ]
(XEN) CPU:0
(XEN) RIP:e008:[] 82d080407fb3
(XEN) RFLAGS: 00010292 CONTEXT: hypervisor (d0v1)
(XEN) rax: 82d080407fb3 rbx: 82d0803cf270 rcx:
(XEN) rdx: 8300abe67fff rsi: 000a rdi: 8300abe67bfd
(XEN) rbp: 8300abe67ca8 rsp: 8300abe67ba0 r8: 83084d98
(XEN) r9: r10: r11:
(XEN) r12: 8300abe67bfd r13: 82d0803cb628 r14:
(XEN) r15: 8300abe67bf8 cr0: 80050033 cr4: 00172660
(XEN) cr3: 000828efd000 cr2: 82d080407fb3
(XEN) fsb: 7fb810d4b780 gsb: 88007ce2 gss:
(XEN) ds: es: fs: gs: ss: e010 cs: e008
(XEN) Xen code around (82d080407fb3) [fault on access]:
(XEN) -- -- -- -- -- -- -- -- <--> -- -- -- -- -- -- -- -- -- -- -- -- -- --
--
(XEN) Xen stack trace from rsp=8300abe67ba0:
(XEN)82d080217f61 830826db0f09 8300abe67bf8 82d0803cf1e0
(XEN)7cff54198409 8300abe67bf0 010001d0
(XEN)82d0803cf288 8300abe67c88 82d0805a09c0 616c620064696370
(XEN)0068 0296 82d08023d60e
(XEN)83084d9b4000 8300abe67c68 82d08024940e 83083736e000
(XEN)0080 007a 000a 82d08045e61c
(XEN)82d080573d80 8300abe67cb8 82d080249805 8007fce54067
(XEN)fff2 830826db0f00 8300abfa7000 82d08045e61c
(XEN)82d080573d80 8300abe67cb8 82d08021801e 8300abe67e48
(XEN)82d08023f60a 83083736e000 8300abe67d58
(XEN)82d080293d90 0092 82d08023d60e 820040006ae0
(XEN) 7fb810d5c010 83083736e248
(XEN)0286 8300abe67d58 82e010521b00
(XEN)0206 8300abe67e48
(XEN)82d080295270 83083736e000 8300abe67e48
(XEN)820040006ae0 8300abe67d98 0012001c 7fb810d5d010
(XEN)0009 0002 0001 7fb810b53260
(XEN)0001 00638bc0 7fb81066a748
(XEN)7ffe11087881 0002 0001 7fb810b53260
(XEN)00638b60 7fb8100322a0 82d08035d444
(XEN) Xen call trace:
(XEN)[] kernel.c#parse_params+0x34a/0x3eb
(XEN)[] runtime_parse+0x1c/0x1e
(XEN)[] do_sysctl+0x108d/0x1241
(XEN)[] pv_hypercall+0x1ac/0x4c5
(XEN)[] lstar_enter+0x112/0x120
(XEN)
(XEN) Pagetable walk from 82d080407fb3:
(XEN) L4[0x105] = abe5c063
(XEN) L3[0x142] = abe59063
(XEN) L2[0x002] = 00084d9bf063
(XEN) L1[0x007] =
(XEN)
(XEN)
(XEN) Panic on CPU 0:
(XEN) FATAL PAGE FAULT
(XEN) [error_code=0010]
(XEN) Faulting linear address: 82d080407fb3
(XEN)
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Juergen Gross
This fix wants backporting to 4.10 which is when runtime parameters were
introduced.
---
xen/arch/x86/pv/domain.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c
index ac85d11..4c95bf3 100644
--- a/xen/arch/x86/pv/domain.c
+++ b/xen/arch/x86/pv/domain.c
@@ -22,7 +22,7 @@ static __read_mostly enum {
PCID_NOXPTI
} opt_pcid = PCID_XPTI;
-static __init int parse_pcid(const char *s)
+static int parse_pcid(const char *s)
{
int rc = 0;
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 7/7] amd/pvh: enable ACPI C1E disable quirk on PVH Dom0
>>> On 30.10.18 at 12:00, wrote:
> On Mon, Oct 29, 2018 at 08:19:20AM -0600, Jan Beulich wrote:
>> >>> On 19.10.18 at 17:20, wrote:
>> > --- a/xen/arch/x86/hvm/svm/svm.c
>> > +++ b/xen/arch/x86/hvm/svm/svm.c
>> > @@ -1272,6 +1272,24 @@ void svm_host_osvw_init()
>> > spin_unlock(&osvw_lock);
>> > }
>> >
>> > +static int acpi_c1e_quirk(int dir, unsigned int port, unsigned int bytes,
>> > + uint32_t *val)
>> > +{
>> > +ASSERT(bytes == 1 && port == acpi_smi_cmd);
>> > +
>> > +if ( dir == IOREQ_READ )
>> > +{
>> > +*val = inb(port);
>> > +return X86EMUL_OKAY;
>> > +}
>> > +
>> > +outb(*val, port);
>> > +if ( *val == acpi_enable_value )
>> > + on_each_cpu(amd_disable_c1e, NULL, 1);
>> > +
>> > +return X86EMUL_OKAY;
>> > +}
>>
>> Nothing in here nor ...
>>
>> > @@ -1284,6 +1302,9 @@ static int svm_domain_initialise(struct domain *d)
>> >
>> > svm_guest_osvw_init(d);
>> >
>> > +if ( amd_acpi_c1e_quirk )
>> > +register_portio_handler(d, acpi_smi_cmd, 1, acpi_c1e_quirk);
>>
>> ... the registration here restricts this to Dom0.
>
> Right, I got messed up with the permissions and completely forgot
> about limiting to Dom0.
>
> The above needs to have a '&& is_hardware_domain(d)' IMO. I prefer to
> do this at hook registration rather than adding such check in the
> handler itself.
Of course. No point to register a handler that does nothing.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/pv: Fix crash when using `xl set-parameter pcid=...`
>>> On 30.10.18 at 12:35, wrote: > "pcid=" is registered as a runtime parameter, which means that parse_pcid() > must not reside in .init, or the following happens when parse_params() tries > to call an unmapped function pointer. > > (XEN) [ Xen-4.12-unstable x86_64 debug=y Not tainted ] > (XEN) CPU:0 > (XEN) RIP:e008:[] 82d080407fb3 > (XEN) RFLAGS: 00010292 CONTEXT: hypervisor (d0v1) > (XEN) rax: 82d080407fb3 rbx: 82d0803cf270 rcx: > (XEN) rdx: 8300abe67fff rsi: 000a rdi: 8300abe67bfd > (XEN) rbp: 8300abe67ca8 rsp: 8300abe67ba0 r8: 83084d98 > (XEN) r9: r10: r11: > (XEN) r12: 8300abe67bfd r13: 82d0803cb628 r14: > (XEN) r15: 8300abe67bf8 cr0: 80050033 cr4: 00172660 > (XEN) cr3: 000828efd000 cr2: 82d080407fb3 > (XEN) fsb: 7fb810d4b780 gsb: 88007ce2 gss: > (XEN) ds: es: fs: gs: ss: e010 cs: e008 > (XEN) Xen code around (82d080407fb3) [fault on > access]: > (XEN) -- -- -- -- -- -- -- -- <--> -- -- -- -- -- -- -- -- -- -- -- -- -- > -- -- > (XEN) Xen stack trace from rsp=8300abe67ba0: > (XEN)82d080217f61 830826db0f09 8300abe67bf8 82d0803cf1e0 > (XEN)7cff54198409 8300abe67bf0 010001d0 > (XEN)82d0803cf288 8300abe67c88 82d0805a09c0 616c620064696370 > (XEN)0068 0296 82d08023d60e > (XEN)83084d9b4000 8300abe67c68 82d08024940e 83083736e000 > (XEN)0080 007a 000a 82d08045e61c > (XEN)82d080573d80 8300abe67cb8 82d080249805 8007fce54067 > (XEN)fff2 830826db0f00 8300abfa7000 82d08045e61c > (XEN)82d080573d80 8300abe67cb8 82d08021801e 8300abe67e48 > (XEN)82d08023f60a 83083736e000 8300abe67d58 > (XEN)82d080293d90 0092 82d08023d60e 820040006ae0 > (XEN) 7fb810d5c010 83083736e248 > (XEN)0286 8300abe67d58 82e010521b00 > (XEN)0206 8300abe67e48 > (XEN)82d080295270 83083736e000 8300abe67e48 > (XEN)820040006ae0 8300abe67d98 0012001c 7fb810d5d010 > (XEN)0009 0002 0001 7fb810b53260 > (XEN)0001 00638bc0 7fb81066a748 > (XEN)7ffe11087881 0002 0001 7fb810b53260 > (XEN)00638b60 7fb8100322a0 82d08035d444 > (XEN) Xen call trace: > (XEN)[] kernel.c#parse_params+0x34a/0x3eb > (XEN)[] runtime_parse+0x1c/0x1e > (XEN)[] do_sysctl+0x108d/0x1241 > (XEN)[] pv_hypercall+0x1ac/0x4c5 > (XEN)[] lstar_enter+0x112/0x120 > (XEN) > (XEN) Pagetable walk from 82d080407fb3: > (XEN) L4[0x105] = abe5c063 > (XEN) L3[0x142] = abe59063 > (XEN) L2[0x002] = 00084d9bf063 > (XEN) L1[0x007] = > (XEN) > (XEN) > (XEN) Panic on CPU 0: > (XEN) FATAL PAGE FAULT > (XEN) [error_code=0010] > (XEN) Faulting linear address: 82d080407fb3 > (XEN) > > 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] [PATCH v5 07/25] xen/arm: don't add duplicate boot modules, introduce domU flag
Hi Stefano,
On 23/10/2018 03:02, Stefano Stabellini wrote:
Don't add duplicate boot modules (same kind and same start address),
they are freed later, we don't want to introduce double-free errors.
Introduce a domU flag in struct bootmodule and struct bootcmdline. Set
it for kernels and ramdisks of "xen,domain" nodes to avoid getting
confused in kernel_probe, where we try to guess which is the dom0 kernel
and initrd to be compatible with all versions of the multiboot spec.
boot_module_find_by_kind and boot_cmdline_find_by_kind automatically
check for !domU entries (they are only used for non-domU modules).
Signed-off-by: Stefano Stabellini
---
Changes in v5:
- improve commit message
- add in-code comments
Changes in v4:
- use unsigned int
- better commit message
- introduce domU flag and usage
Changes in v2:
- new patch
---
xen/arch/arm/bootfdt.c | 11 +++
xen/arch/arm/setup.c| 30 +-
xen/include/asm-arm/setup.h | 12 ++--
3 files changed, 42 insertions(+), 11 deletions(-)
diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index cb6f77d..c325b6e 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -175,6 +175,7 @@ static void __init process_multiboot_node(const void *fdt,
int node,
int len = sizeof("/chosen");
char path[8]; /* sizeof "/chosen" */
int parent_node, ret;
+bool domU;
parent_node = fdt_parent_offset(fdt, node);
ASSERT(parent_node >= 0);
@@ -229,12 +230,14 @@ static void __init process_multiboot_node(const void
*fdt, int node,
kind = BOOTMOD_XSM;
}
-add_boot_module(kind, start, size);
+domU = fdt_node_check_compatible(fdt, parent_node, "xen,domain") == 0;
+add_boot_module(kind, start, size, domU);
prop = fdt_get_property(fdt, node, "bootargs", &len);
if ( !prop )
return;
-add_boot_cmdline(fdt_get_name(fdt, parent_node, &len), prop->data, kind);
+add_boot_cmdline(fdt_get_name(fdt, parent_node, &len), prop->data,
+ kind, domU);
}
static void __init process_chosen_node(const void *fdt, int node,
@@ -280,7 +283,7 @@ static void __init process_chosen_node(const void *fdt, int
node,
printk("Initrd %"PRIpaddr"-%"PRIpaddr"\n", start, end);
-add_boot_module(BOOTMOD_RAMDISK, start, end-start);
+add_boot_module(BOOTMOD_RAMDISK, start, end-start, false);
}
static int __init early_scan_node(const void *fdt,
@@ -351,7 +354,7 @@ size_t __init boot_fdt_info(const void *fdt, paddr_t paddr)
if ( ret < 0 )
panic("No valid device tree\n");
-add_boot_module(BOOTMOD_FDT, paddr, fdt_totalsize(fdt));
+add_boot_module(BOOTMOD_FDT, paddr, fdt_totalsize(fdt), false);
device_tree_for_each_node((void *)fdt, early_scan_node, NULL);
early_print_info();
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 2098591..72b12f9 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -201,10 +201,12 @@ void __init dt_unreserved_regions(paddr_t s, paddr_t e,
}
struct bootmodule __init *add_boot_module(bootmodule_kind kind,
- paddr_t start, paddr_t size)
+ paddr_t start, paddr_t size,
+ bool domU)
{
struct bootmodules *mods = &bootinfo.modules;
struct bootmodule *mod;
+unsigned int i;
if ( mods->nr_mods == MAX_MODULES )
{
@@ -212,15 +214,29 @@ struct bootmodule __init *add_boot_module(bootmodule_kind
kind,
boot_module_kind_as_string(kind), start, start + size);
return NULL;
}
+for ( i = 0 ; i < mods->nr_mods ; i++ )
+{
+mod = &mods->module[i];
+if ( mod->kind == kind && mod->start == start )
+{
+if ( !domU )
+mod->domU = false;
+return mod;
+}
+}
mod = &mods->module[mods->nr_mods++];
mod->kind = kind;
mod->start = start;
mod->size = size;
+mod->domU = domU;
return mod;
}
+/*
+ * This function is only used to find dom0 modules, so check for !mod->domU
This comment is misleading. The function is used not only to find Dom0 Modules
but also XSM & co.
How about:
"boot_module_find_by_kind can only be used to return Xen modules (e.g XSM, DTB)
or Dom0 modules. This is not suitable for looking up for guest modules."
+ */
struct bootmodule * __init boot_module_find_by_kind(bootmodule_kind kind)
{
struct bootmodules *mods = &bootinfo.modules;
@@ -229,14 +245,14 @@ struct bootmodule * __init
boot_module_find_by_kind(bootmodule_kind kind)
for (i = 0 ; i < mods->nr_mods ; i++ )
{
mod = &mods->module[i];
-if ( mod->kind == kind )
+if ( mod->kind == kind && !mod->domU )
return mod;
}
return NULL;
}
void __init add_b
[Xen-devel] [distros-debian-snapshot test] 75544: trouble: broken/fail/pass
flight 75544 distros-debian-snapshot real [real] http://osstest.xensource.com/osstest/logs/75544/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-i386-current-netinst-pygrubbroken Tests which did not succeed, but are not blocking: test-amd64-amd64-i386-current-netinst-pygrub 4 host-install(4) broken blocked in 75485 test-amd64-i386-i386-current-netinst-pygrub 6 xen-install fail blocked in 75485 test-amd64-amd64-i386-daily-netboot-pygrub 11 guest-start fail blocked in 75485 test-amd64-i386-i386-weekly-netinst-pygrub 10 debian-di-install fail blocked in 75485 test-amd64-amd64-i386-weekly-netinst-pygrub 10 debian-di-install fail blocked in 75485 test-amd64-i386-amd64-current-netinst-pygrub 10 debian-di-install fail blocked in 75485 test-amd64-i386-amd64-weekly-netinst-pygrub 10 debian-di-install fail blocked in 75485 test-amd64-amd64-amd64-weekly-netinst-pygrub 10 debian-di-install fail blocked in 75485 test-amd64-i386-i386-daily-netboot-pvgrub 10 debian-di-install fail blocked in 75485 test-amd64-i386-amd64-daily-netboot-pygrub 10 debian-di-install fail blocked in 75485 test-amd64-amd64-amd64-current-netinst-pygrub 10 debian-di-install fail blocked in 75485 test-amd64-amd64-amd64-daily-netboot-pvgrub 10 debian-di-install fail blocked in 75485 test-armhf-armhf-armhf-daily-netboot-pygrub 10 debian-di-install fail blocked in 75485 baseline version: flight 75485 jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-amd64-daily-netboot-pvgrub fail test-amd64-i386-i386-daily-netboot-pvgrubfail test-amd64-i386-amd64-daily-netboot-pygrub fail test-armhf-armhf-armhf-daily-netboot-pygrub fail test-amd64-amd64-i386-daily-netboot-pygrub fail test-amd64-amd64-amd64-current-netinst-pygrubfail test-amd64-i386-amd64-current-netinst-pygrub fail test-amd64-amd64-i386-current-netinst-pygrub broken test-amd64-i386-i386-current-netinst-pygrub fail test-amd64-amd64-amd64-weekly-netinst-pygrub fail test-amd64-i386-amd64-weekly-netinst-pygrub fail test-amd64-amd64-i386-weekly-netinst-pygrub fail test-amd64-i386-i386-weekly-netinst-pygrub fail sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xensource.com/osstest/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 08/25] xen/arm: probe domU kernels and initrds
Hi Stefano,
On 23/10/2018 03:02, Stefano Stabellini wrote:
Find addresses, sizes on device tree from kernel_probe.
Find the cmdline from the bootcmdlines array.
Introduce a new boot_module_find_by_addr_and_kind function to match not
just on boot module kind, but also by address so that we can support
multiple domains.
Introduce a boot_cmdline_find_by_name function to find the right struct
cmdline based on the device tree node name of the "xen,domain"
compatible node.
Set command line for dom0 too for consistency.
I was expecting you to remove the assignment in construct_dom0 to avoid the
duplication.
[...]
diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index da8410e..d56f776 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -421,22 +421,72 @@ static int __init kernel_zimage32_probe(struct
kernel_info *info,
return 0;
}
-int __init kernel_probe(struct kernel_info *info)
+int __init kernel_probe(struct kernel_info *info,
+const struct dt_device_node *domain)
{
-struct bootmodule *mod = boot_module_find_by_kind(BOOTMOD_KERNEL);
+struct bootmodule *mod = NULL;
+struct bootcmdline *cmd = NULL;
+struct dt_device_node *node;
+u64 kernel_addr, initrd_addr, size;
int rc;
+/* domain is NULL only for the hardware_domain */
NIT: No need to the _.
The rest of the code looks good to me.
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 12/18] xen: setup Xen specific data for PVH
On 30/10/2018 12:23, Roger Pau Monné wrote:
> On Mon, Oct 29, 2018 at 03:19:34PM +0100, Juergen Gross wrote:
>> On 29/10/2018 13:57, Roger Pau Monné wrote:
>>> On Fri, Oct 19, 2018 at 06:39:50PM +0200, Juergen Gross wrote:
On 19/10/2018 18:10, Roger Pau Monné wrote:
> On Tue, Oct 09, 2018 at 01:03:11PM +0200, Juergen Gross wrote:
>> Initialize the needed Xen specific data. This is:
>>
>> - the Xen start of day page containing the console and Xenstore ring
>> page PFN and event channel
>> - the grant table
>> - the shared info page
>>
>> Set the RSDP address for the guest from the start_info page passed
>> as boot parameter.
>>
>> Signed-off-by: Juergen Gross
>> ---
>> grub-core/kern/i386/xen/pvh.c | 107
>> ++
>> 1 file changed, 107 insertions(+)
>>
>> diff --git a/grub-core/kern/i386/xen/pvh.c
>> b/grub-core/kern/i386/xen/pvh.c
>> index b4933b454..93ed68245 100644
>> --- a/grub-core/kern/i386/xen/pvh.c
>> +++ b/grub-core/kern/i386/xen/pvh.c
>> @@ -24,6 +24,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>>
>> struct xen_machine_mmap_entry
>> @@ -39,6 +40,7 @@ static struct { char _entry[32]; } hypercall_page[128]
>>__attribute__ ((aligned (GRUB_XEN_PAGE_SIZE)));
>>
>> static grub_uint32_t xen_cpuid_base;
>> +static struct start_info grub_xen_start_page;
>> static struct xen_machine_mmap_entry map[128];
>> static unsigned int nr_map_entries;
>>
>> @@ -104,6 +106,36 @@ grub_xen_hypercall (grub_uint32_t callno,
>> grub_uint32_t a0,
>>return __res;
>> }
>>
>> +static grub_uint32_t
>> +grub_xen_get_param (int idx)
>> +{
>> + struct xen_hvm_param xhv;
>> + int r;
>> +
>> + xhv.domid = DOMID_SELF;
>> + xhv.index = idx;
>> + r = grub_xen_hypercall (__HYPERVISOR_hvm_op, HVMOP_get_param,
>> + (grub_uint32_t) (&xhv), 0, 0, 0, 0);
>> + if (r < 0)
>> +grub_xen_early_halt ();
>> + return xhv.value;
>> +}
>> +
>> +static void *
>> +grub_xen_add_physmap (unsigned int space, void *addr)
>> +{
>> + struct xen_add_to_physmap xatp;
>> +
>> + xatp.domid = DOMID_SELF;
>> + xatp.idx = 0;
>> + xatp.space = space;
>> + xatp.gpfn = (grub_addr_t) addr >> GRUB_XEN_LOG_PAGE_SIZE;
>> + if (grub_xen_hypercall (__HYPERVISOR_memory_op, XENMEM_add_to_physmap,
>> + (grub_uint32_t) (&xatp), 0, 0, 0, 0))
>> +grub_xen_early_halt ();
>> + return addr;
>> +}
>> +
>> static void
>> grub_xen_sort_mmap (void)
>> {
>> @@ -190,12 +222,87 @@ grub_xen_get_mmap (void)
>>grub_xen_sort_mmap ();
>> }
>>
>> +static grub_uint64_t
>> +grub_xen_find_page (grub_uint64_t start)
>> +{
>> + unsigned int i, j;
>> + grub_uint64_t last = start;
>> +
>> + /* Try to find a e820 map hole below 4G. */
>
> Doing this is kind of dangerous, what if you end up placing something
> on top of an MMIO region (either emulated or from a real passthrough
> device)?
Shouldn't those be marked as "Reserved" in the memory map?
>>>
>>> I don't think BARs are guaranteed to be in areas marked as reserved in
>>> the memory map. Unless you also scan for PCI devices and make sure
>>> there's no device with a BAR in the area you are attempting to
>>> populate I think the above is not safe.
>>
>> So either I can add scanning the PCI bus (which wouldn't be too
>> hard IMO), or we require Xen tools to add memory map entries with
>> "Reserved" attribute for passed-through PCI device's MMIO-areas
>> (we can still do that as PCI pass-through for PVH isn't possible
>> yet AFAIK).
>
> Ideally (and that's kind of far away from what we are now), I would
> like to have an interface to request Xen for a range of gfns available
> to map stuff in them (grants/foreign mappings/shared page...). That
> interface could be a simple hypercall that would return such range, or
> an hypercall that could be used to fetch something akin to an
> 'extended memory map' with specific Xen information (like such
> regions).
>
> In both cases this requires Xen having a clearer picture of the p2m,
> because any of the above solutions cannot rely on scanning the p2m
> table in order to figure out what's where.
>
> So the only change I would request is that if you use a RAM page you
> update the memory map stored in Xen to match the new layout, by using
> the XENMEM_set_memory_map hypercall.
Okay, this is simple.
Nevertheless I'm adding the already finished patch for scanning the
PCI devices to find MMIO areas.
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-d
Re: [Xen-devel] [PATCH v5 11/25] xen/arm: introduce allocate_memory
Hi,
On 23/10/2018 03:02, Stefano Stabellini wrote:
Introduce an allocate_memory function able to allocate memory for DomUs
and map it at the right guest addresses, according to the guest memory
map: GUEST_RAM0_BASE and GUEST_RAM1_BASE.
This is under #if 0 as not used for now.
Signed-off-by: Stefano Stabellini
---
Changes in v5:
- improve commit message
- code style
- remove unneeded local var
- while loop in allocate_bank_memory to allocate memory so that it
doesn't have to be contiguos
- combile while loops in allocate_memory
Changes in v4:
- move earlier, add #if 0
- introduce allocate_bank_memory, remove insert_bank
- allocate_bank_memory allocate memory and inserts the bank, while
allocate_memory specifies where to do that
Changes in v3:
- new patch
---
xen/arch/arm/domain_build.c | 99 +
1 file changed, 99 insertions(+)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index c61a27f..146d81e 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -368,6 +368,105 @@ static void __init allocate_memory_11(struct domain *d,
}
}
+#if 0
+static bool __init allocate_bank_memory(struct domain *d,
+struct kernel_info *kinfo,
+gfn_t sgfn,
+unsigned int order)
I don't think your implementation below is equivalent to the one I suggested
earlier on ([1]). While you handled the contiguous problem, you didn't address
the 2 others points:
1) The memory specify by the user may not be in power of 2 pages. For
instance, a user can specify 40KB. With your algo, we will end to
allocate 32KB in the first bank and 8KB in the second bank. However what
we want is allocate 40KB in a single bank.
2) You don't check whether the leftover memory is bigger than the size
of the second bank.
Because of 1), you can't reason in term of order here. You have to reason in
bytes or number of pages.
+{
+int res;
+struct page_info *pg;
+struct membank *bank;
+paddr_t size = pfn_to_paddr(1UL << order);
+gfn_t _sgfn = sgfn;
+gfn_t _egfn = gfn_add(sgfn, 1UL << order);
+
+while ( gfn_x(_sgfn) < gfn_x(_egfn) )
+{
+pg = alloc_domheap_pages(d, order, 0);
+if ( pg != NULL )
+{
+res = guest_physmap_add_page(d, _sgfn, page_to_mfn(pg), order);
+if ( res )
+{
+dprintk(XENLOG_ERR, "Failed map pages to DOMU: %d", res);
+goto fail;
+}
+_sgfn = gfn_add(_sgfn, 1UL << order);
+}
+else
+{
+order--;
order may be equal to 0. So here you will underflow.
Overall, it would be best if you re-use the code I sent. While not tested, it
addresses all the problems. Fixing the potential bug in that patch so be quite
easily.
+if ( order == 0 )
+{
+dprintk(XENLOG_ERR, "Failed to allocated DOMU memory");
+goto fail;
+}
+}
+}
+
+bank = &kinfo->mem.bank[kinfo->mem.nr_banks];
+bank->start = gfn_to_gaddr(sgfn);
+bank->size = size;
+kinfo->mem.nr_banks++;
+kinfo->unassigned_mem -= size;
+
+return true;
+
+fail:
+/*
+ * Fatal failure, don't attempt to free memory.
+ */
+return false;
+}
+
+static void __init allocate_memory(struct domain *d, struct kernel_info *kinfo)
+{
+unsigned int order = get_allocation_size(kinfo->unassigned_mem);
+unsigned int order_req;
+unsigned int i;
+
+dprintk(XENLOG_INFO, "Allocating mappings totalling %ldMB for dom%d:\n",
+/* Don't want format this as PRIpaddr (16 digit hex) */
+(unsigned long)(kinfo->unassigned_mem >> 20), d->domain_id);
+
+kinfo->mem.nr_banks = 0;
+
+order = get_allocation_size(kinfo->unassigned_mem);
+if ( order > get_order_from_bytes(GUEST_RAM0_SIZE) )
+order_req = get_order_from_bytes(GUEST_RAM0_SIZE);
+else
+order_req = order;
+if ( !allocate_bank_memory(d, kinfo, gaddr_to_gfn(GUEST_RAM0_BASE),
order_req) )
+goto fail;
+
+order -= order_req;
+if ( order > 0 &&
+ !allocate_bank_memory(d, kinfo, gaddr_to_gfn(GUEST_RAM1_BASE), order)
)
+goto fail;
+
+for( i = 0; i < kinfo->mem.nr_banks; i++ )
+{
+dprintk(XENLOG_INFO, "Dom%d BANK[%d] %#"PRIpaddr"-%#"PRIpaddr"
(%ldMB)\n",
+d->domain_id,
+i,
+kinfo->mem.bank[i].start,
+kinfo->mem.bank[i].start + kinfo->mem.bank[i].size,
+/* Don't want format this as PRIpaddr (16 digit hex) */
+(unsigned long)(kinfo->mem.bank[i].size >> 20));
+}
+
+return;
+
+fail:
+dprintk(XENLOG_ERR, "Failed to allocate requested domain memory."
+/* Don't want format this as PRIpaddr (16 digit hex) */
+
Re: [Xen-devel] [PATCH v5] arch/x86: Add registers to vm_event
On 10/30/18 1:33 PM, Jan Beulich wrote:
On 30.10.18 at 11:07, wrote:
>> --- a/xen/include/public/vm_event.h
>> +++ b/xen/include/public/vm_event.h
>> @@ -29,7 +29,7 @@
>>
>> #include "xen.h"
>>
>> -#define VM_EVENT_INTERFACE_VERSION 0x0003
>> +#define VM_EVENT_INTERFACE_VERSION 0x0004
>>
>> #if defined(__XEN__) || defined(__XEN_TOOLS__)
>>
>> @@ -157,6 +157,12 @@
>> #define VM_EVENT_X86_CR42
>> #define VM_EVENT_X86_XCR0 3
>>
>> +/* The limit field is right-shifted by 12 bits if .ar.g is set. */
>> +struct x86_selector_reg {
>
> I'm sorry for not having noticed this earlier, but this needs proper
> prefixing: Matching struct vm_event_regs_x86, it should at least
> be prefixed by vm_event_. Strictly speaking xen_ as the very
> first thing would also be required, but I'll leave that to the VM
> event maintainers to decide. With this
> Reviewed-by: Jan Beulich
I am fine with either approach (so leaving it as it is not a problem),
so we'll go with Tamas' preference. Tamas, what's your opinion?
Thanks,
Razvan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v1 5/6] x86/vvmx: correctly report vvmcs size
On 30/10/2018 08:06, Tian, Kevin wrote:
>> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
>> Sent: Friday, October 12, 2018 11:28 PM
>>
>> The size of Xen's virtual vmcs region is 4096 bytes. Correctly report
>> it to the guest in case when VMCS shadowing is not available instead of
>> providing H/W value (which is usually smaller).
>
> what is the problem of reporting smaller size even when actual
> size is 4096? is L1 expected to access the portion beyond h/w
> reported size?
>
Here's the code snippet from kvm-unit-tests:
vmcs[0]->hdr.revision_id = basic.revision;
assert(!vmcs_clear(vmcs[0]));
assert(!make_vmcs_current(vmcs[0]));
set_all_vmcs_fields(0x86);
assert(!vmcs_clear(vmcs[0]));
memcpy(vmcs[1], vmcs[0], basic.size);
assert(!make_vmcs_current(vmcs[1]));
report("test vmclear flush (current VMCS)",
check_all_vmcs_fields(0x86));
set_all_vmcs_fields() vmwrites almost 4k, but memcpy() copies only 1024
bytes and vmreads get incorrect values.
>>
>> Signed-off-by: Sergey Dyasli
>> ---
>> xen/arch/x86/hvm/vmx/vvmx.c | 8
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/xen/arch/x86/hvm/vmx/vvmx.c
>> b/xen/arch/x86/hvm/vmx/vvmx.c
>> index 8b691bfc04..2c2ba36d94 100644
>> --- a/xen/arch/x86/hvm/vmx/vvmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vvmx.c
>> @@ -2064,6 +2064,14 @@ int nvmx_msr_read_intercept(unsigned int msr,
>> u64 *msr_content)
>> data = (host_data & (~0ul << 32)) |
>> (vmcs->vmcs_revision_id & 0x7fff);
>> unmap_domain_page(vmcs);
>> +
>> +if ( !cpu_has_vmx_vmcs_shadowing )
>> +{
>> +/* Report vmcs_region_size as 4096 */
>> +data &= ~VMX_BASIC_VMCS_SIZE_MASK;
>> +data |= 1ULL << 44;
>> +}
>> +
>> break;
>> }
>> case MSR_IA32_VMX_PINBASED_CTLS:
>> --
>> 2.17.1
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v1 1/6] x86/vvmx: introduce vvmcx_valid()
On 30/10/2018 07:41, Tian, Kevin wrote: >> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com] >> Sent: Friday, October 12, 2018 11:28 PM >> >> As a convenient helper function and refactor the code to use it. >> >> No functional change. >> >> Signed-off-by: Sergey Dyasli > > since vmcx is hvm abstracted term, what about using this > helper in svm side too? I couldn't find any code in nestedsvm.c that would benefit from this new helper. -- Thanks, Sergey ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5] arch/x86: Add registers to vm_event
>>> On 30.10.18 at 13:26, wrote:
> On 10/30/18 1:33 PM, Jan Beulich wrote:
> On 30.10.18 at 11:07, wrote:
>>> --- a/xen/include/public/vm_event.h
>>> +++ b/xen/include/public/vm_event.h
>>> @@ -29,7 +29,7 @@
>>>
>>> #include "xen.h"
>>>
>>> -#define VM_EVENT_INTERFACE_VERSION 0x0003
>>> +#define VM_EVENT_INTERFACE_VERSION 0x0004
>>>
>>> #if defined(__XEN__) || defined(__XEN_TOOLS__)
>>>
>>> @@ -157,6 +157,12 @@
>>> #define VM_EVENT_X86_CR42
>>> #define VM_EVENT_X86_XCR0 3
>>>
>>> +/* The limit field is right-shifted by 12 bits if .ar.g is set. */
>>> +struct x86_selector_reg {
>>
>> I'm sorry for not having noticed this earlier, but this needs proper
>> prefixing: Matching struct vm_event_regs_x86, it should at least
>> be prefixed by vm_event_. Strictly speaking xen_ as the very
>> first thing would also be required, but I'll leave that to the VM
>> event maintainers to decide. With this
>> Reviewed-by: Jan Beulich
>
> I am fine with either approach (so leaving it as it is not a problem),
> so we'll go with Tamas' preference. Tamas, what's your opinion?
FAOD leaving as is is not an option - at least vm_event_ needs to
be added, to not chance collision with a future addition in Xen itself.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen-swiotlb: exchange memory with Xen only when pages are contiguous
On 10/30/18 1:59 AM, Paul Durrant wrote: >> On 10/25/18 11:56 AM, Joe Jin wrote: >>> I just discussed this patch with Boris in private, his opinions(Boris, >>> please correct me if any misunderstood) are: >>> >>> 1. With/without the check, both are incorrect, he thought we need to >>>prevented unalloc'd free at here. >>> 2. On freeing, if upper layer already checked the memory was DMA-able, >>>the checking at here does not make sense, we can remove all checks. >>> 3. xen_create_contiguous_region() and xen_destroy_contiguous_region() >>>to come in pairs. >> I tried to added radix_tree to track allocating/freeing and I found some >> memory only allocated but was not freed, I guess it caused by driver used >> dma_pool, that means if lots of such requests, the list will consume lot >> of memory for it. Will continue to work on it, if anyone have good idea >> for it please let me know, I'd like to try it. >> > FWIW, in my Xen PV-IOMMU test patches, I have also tried keeping a list of > ranges mapped for DMA and have discovered apparent issues with some drivers, > particularly tg3, that seem to free mappings that have not been allocated (or > possibly double-free). I've never fully tracked down the issue. Call trace of first called xen_swiotlb_alloc_coherent(The pages never backed to Xen): [ 23.436333] [] xen_swiotlb_alloc_coherent+0x169/0x510 [ 23.436623] [] ? kmem_cache_alloc_trace+0x1ed/0x280 [ 23.436900] [] dma_pool_alloc+0x11f/0x260 [ 23.437190] [] ehci_qh_alloc+0x52/0x120 [ 23.437481] [] ehci_setup+0x2bf/0x8e0 [ 23.437760] [] ? __dev_printk+0x46/0xa0 [ 23.438042] [] ? _dev_info+0x53/0x60 [ 23.438327] [] ehci_pci_setup+0xc0/0x5f0 [ 23.438615] [] usb_add_hcd+0x25d/0xaf0 [ 23.438901] [] usb_hcd_pci_probe+0x406/0x520 [ 23.439177] [] ehci_pci_probe+0x36/0x40 [ 23.439469] [] local_pci_probe+0x4a/0xb0 [ 23.439752] [] ? pci_match_device+0xe5/0x110 [ 23.440027] [] pci_device_probe+0xd1/0x120 [ 23.440320] [] driver_probe_device+0x20c/0x4d0 [ 23.440599] [] __driver_attach+0x9b/0xa0 [ 23.440879] [] ? __device_attach+0x50/0x50 Above was EHCI used DMA pool to allocate DMA memory. During my testing, ~1000 entries was not freed, if more PCI devices use DMA pool, the tree/list will have more entries, looks it's not a good idea that use a list to track it. Thanks, Joe ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [Xen-users] [XEN][ARM] WiFi bridge creation
Thanks Vladimir. Can some one provide pointer/reference on how to use NAT to share WiFi between Dom0 and DomU. Followed the instruction provided in the below link, but no success. https://wiki.debian.org/BridgeNetworkConnections#Bridging_with_a_wireless_NIC On Tue, Oct 30, 2018 at 4:04 PM Vladimir Botka wrote: > > On Tue, Oct 30, 2018 at 12:39 PM Vladimir Botka > wrote: > > > On Tue, 30 Oct 2018 10:03:22 +0530 > > > Vikram K wrote: > > > > Hello, > > > > We are using Hikey960 with Debian as Dom0 and DomU. This board has > only > > > > WiFi interface. We want to create bridge between Dom0 and DomU so > that > > > > DomU > > > > has internet access. We tried to create bridge using brtcl command, > but > > > > it > > > > is not working. Please provide pointers. > > > > AFAIK, it's not working > > > https://marc.info/?l=linux-wireless&m=136743495526905&w=2 > > > "There is a proposed fix that is included in OpenWrt" > > > https://marc.info/?l=linux-wireless&m=145591129008322&w=2 > > > More details are avilable in OpenWrt WiKi > > > https://wiki.openwrt.org/doc/recipes/relayclient > > > -vlado > > On Tue, 30 Oct 2018 15:01:39 +0530 > Vikram K wrote: > > Hi, > > As per below link, it is possible to share Internet via WiFi between Dom0 > > and DomU,. > > https://wiki.xenproject.org/wiki/Xen_in_WiFi_networks > > Tried the suggested solution using ebtables, but it did not work. > > * ebtables -t nat -A POSTROUTING -s 00:60:00:00:00:01 \ > > -j snat --to-source 00:60:aa:bb:cc:dd* > > In the configurations file we have added below configuration in DomU > > config file. > > * vif = ['mac=00:16:3e:64:b8:40']* > > Apart from that do we need to add any addition configuration? > > NAT is a different story. Worked for me with Armbian(no XEN) and Atheros > 9280 > couple of years ago. I used Ansible to configure it. > > https://github.com/vbotka/ansible-linux-postinstall/blob/master/templates/router1-iptables.j2 > > HTH, > > - vlado > -- Thanks & Regards Vikram KS -- This message contains confidential information and is intended only for the individual(s) named. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this mail and attached file/s is strictly prohibited. Please notify the sender immediately and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secured or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen-swiotlb: exchange memory with Xen only when pages are contiguous
> -Original Message- > From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf > Of Joe Jin > Sent: 30 October 2018 14:13 > To: Paul Durrant ; Boris Ostrovsky > ; Konrad Rzeszutek Wilk > > Cc: John Sobecki ; DONGLI.ZHANG > ; linux-ker...@vger.kernel.org" ker...@vger.kernel.org>; kon...@kernel.org; xen- > de...@lists.xenproject.org; Christoph Helwig > Subject: Re: [Xen-devel] [PATCH] xen-swiotlb: exchange memory with Xen > only when pages are contiguous > > On 10/30/18 1:59 AM, Paul Durrant wrote: > >> On 10/25/18 11:56 AM, Joe Jin wrote: > >>> I just discussed this patch with Boris in private, his opinions(Boris, > >>> please correct me if any misunderstood) are: > >>> > >>> 1. With/without the check, both are incorrect, he thought we need to > >>>prevented unalloc'd free at here. > >>> 2. On freeing, if upper layer already checked the memory was DMA-able, > >>>the checking at here does not make sense, we can remove all checks. > >>> 3. xen_create_contiguous_region() and xen_destroy_contiguous_region() > >>>to come in pairs. > >> I tried to added radix_tree to track allocating/freeing and I found > some > >> memory only allocated but was not freed, I guess it caused by driver > used > >> dma_pool, that means if lots of such requests, the list will consume > lot > >> of memory for it. Will continue to work on it, if anyone have good idea > >> for it please let me know, I'd like to try it. > >> > > FWIW, in my Xen PV-IOMMU test patches, I have also tried keeping a list > of ranges mapped for DMA and have discovered apparent issues with some > drivers, particularly tg3, that seem to free mappings that have not been > allocated (or possibly double-free). I've never fully tracked down the > issue. > > Call trace of first called xen_swiotlb_alloc_coherent(The pages never > backed to Xen): > > [ 23.436333] [] > xen_swiotlb_alloc_coherent+0x169/0x510 > [ 23.436623] [] ? kmem_cache_alloc_trace+0x1ed/0x280 > [ 23.436900] [] dma_pool_alloc+0x11f/0x260 > [ 23.437190] [] ehci_qh_alloc+0x52/0x120 > [ 23.437481] [] ehci_setup+0x2bf/0x8e0 > [ 23.437760] [] ? __dev_printk+0x46/0xa0 > [ 23.438042] [] ? _dev_info+0x53/0x60 > [ 23.438327] [] ehci_pci_setup+0xc0/0x5f0 > [ 23.438615] [] usb_add_hcd+0x25d/0xaf0 > [ 23.438901] [] usb_hcd_pci_probe+0x406/0x520 > [ 23.439177] [] ehci_pci_probe+0x36/0x40 > [ 23.439469] [] local_pci_probe+0x4a/0xb0 > [ 23.439752] [] ? pci_match_device+0xe5/0x110 > [ 23.440027] [] pci_device_probe+0xd1/0x120 > [ 23.440320] [] driver_probe_device+0x20c/0x4d0 > [ 23.440599] [] __driver_attach+0x9b/0xa0 > [ 23.440879] [] ? __device_attach+0x50/0x50 > > Above was EHCI used DMA pool to allocate DMA memory. > > During my testing, ~1000 entries was not freed, if more PCI devices > use DMA pool, the tree/list will have more entries, looks it's not a > good idea that use a list to track it. > Yes, it seems pools can hang onto a serious number of allocations so a list is probably not wise. What I was pointing out, though, is that it appears you can't even track mappings (as opposed to allocations) with a list either because drivers apparently try to unmap things they have not mapped. Paul > Thanks, > Joe > > ___ > Xen-devel mailing list > Xen-devel@lists.xenproject.org > https://lists.xenproject.org/mailman/listinfo/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] use consistent values when consuming runtime-changeable parameters
There's no guarantee that e.g. a switch() control expression's memory
operand(s) get(s) read just once. Guard against the compiler producing
"unexpected" code by sprinkling around some ACCESS_ONCE().
I'm leaving alone opt_conswitch[]: It gets accessed in quite a few
places anyway, and an intermediate change won't have any severe effect
afaict.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/pv/domain.c
+++ b/xen/arch/x86/pv/domain.c
@@ -256,7 +256,7 @@ int pv_domain_initialise(struct domain *
d->arch.pv.xpti = is_hardware_domain(d) ? opt_xpti_hwdom : opt_xpti_domu;
if ( !is_pv_32bit_domain(d) && use_invpcid && cpu_has_pcid )
-switch ( opt_pcid )
+switch ( ACCESS_ONCE(opt_pcid) )
{
case PCID_OFF:
break;
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -630,16 +630,16 @@ static void __putstr(const char *str)
static int printk_prefix_check(char *p, char **pp)
{
int loglvl = -1;
-int upper_thresh = xenlog_upper_thresh;
-int lower_thresh = xenlog_lower_thresh;
+int upper_thresh = ACCESS_ONCE(xenlog_upper_thresh);
+int lower_thresh = ACCESS_ONCE(xenlog_lower_thresh);
while ( (p[0] == '<') && (p[1] != '\0') && (p[2] == '>') )
{
switch ( p[1] )
{
case 'G':
-upper_thresh = xenlog_guest_upper_thresh;
-lower_thresh = xenlog_guest_lower_thresh;
+upper_thresh = ACCESS_ONCE(xenlog_guest_upper_thresh);
+lower_thresh = ACCESS_ONCE(xenlog_guest_lower_thresh);
if ( loglvl == -1 )
loglvl = XENLOG_GUEST_DEFAULT;
break;
@@ -690,13 +690,14 @@ static int parse_console_timestamps(cons
static void printk_start_of_line(const char *prefix)
{
+enum con_timestamp_mode mode = ACCESS_ONCE(opt_con_timestamp_mode);
struct tm tm;
char tstr[32];
uint64_t sec, nsec;
__putstr(prefix);
-switch ( opt_con_timestamp_mode )
+switch ( mode )
{
case TSM_DATE:
case TSM_DATE_MS:
@@ -704,7 +705,7 @@ static void printk_start_of_line(const c
if ( tm.tm_mday == 0 )
/* nothing */;
-else if ( opt_con_timestamp_mode == TSM_DATE )
+else if ( mode == TSM_DATE )
{
snprintf(tstr, sizeof(tstr), "[%04u-%02u-%02u %02u:%02u:%02u] ",
1900 + tm.tm_year, tm.tm_mon + 1, tm.tm_mday,
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf baseline-only test] 75546: regressions - FAIL
This run is configured for baseline tests only.
flight 75546 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75546/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 75543
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 75543
Tests which did not succeed, but are not blocking:
build-amd64-libvirt 6 libvirt-buildfail like 75543
build-i386-libvirt6 libvirt-buildfail like 75543
version targeted for testing:
ovmf 4222e8e7e421e9c8d2c2f319a3860dd3332d6255
baseline version:
ovmf c87ac38cf280fa969f1033de3c5b7a157aac8cbc
Last test of basis75543 2018-10-30 05:31:10 Z0 days
Testing same since75546 2018-10-30 09:21:34 Z0 days1 attempts
People who touched revisions under test:
Jian J Wang
Marvin H?user
Marvin Haeuser
jobs:
build-amd64-xsm pass
build-i386-xsm pass
build-amd64 pass
build-i386 pass
build-amd64-libvirt fail
build-i386-libvirt fail
build-amd64-pvopspass
build-i386-pvops pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 fail
test-amd64-i386-xl-qemuu-ovmf-amd64 fail
sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images
Logs, config files, etc. are available at
http://osstest.xensource.com/osstest/logs
Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
Push not applicable.
commit 4222e8e7e421e9c8d2c2f319a3860dd3332d6255
Author: Marvin H?user
Date: Sun Oct 28 16:51:23 2018 +0800
UefiCpuPkg/PiSmmCpuDxeSmm: Fix ASSERT for success.
Index is initialized to MAX_UINT16 as default failure value, which
is what the ASSERT is supposed to test for. The ASSERT condition
however can never return FALSE for INT16 != int, as due to
Integer Promotion[1], Index is converted to int, which can never
result in -1.
Furthermore, Index is used as a for loop index variable inbetween its
initialization and the ASSERT, so the value is unconditionally
overwritten too.
Fix the ASSERT check to compare Index to its upper boundary, which it
will be equal to if the loop was not broken out of on success.
[1] ISO/IEC 9899:2011, 6.5.9.4
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser
Reviewed-by: Eric Dong
commit 37fba7c2762e114a280e3b361b53ded034aac7e3
Author: Marvin H?user
Date: Sun Oct 28 16:51:22 2018 +0800
UefiCpuPkg/MpInitLib: Fix ASSERT for success.
Index is initialized to MAX_UINT16 as default failure value, which
is what the ASSERT is supposed to test for. The ASSERT condition
however can never return FALSE for INT16 != int, as due to
Integer Promotion[1], Index is converted to int, which can never
result in -1.
Furthermore, Index is used as a for loop index variable inbetween its
initialization and the ASSERT, so the value is unconditionally
overwritten too.
Fix the ASSERT check to compare Index to its upper boundary, which it
will be equal to if the loop was not broken out of on success.
[1] ISO/IEC 9899:2011, 6.5.9.4
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser
Reviewed-by: Eric Dong
commit 61a62fc2587ae4d01718124f28e1ea0e60375902
Author: Jian J Wang
Date: Mon Oct 29 16:20:44 2018 +0800
MdeModulePkg/Core: fix an issue of potential NULL pointer access
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1286
This issue is introduced by bb685071c2602cf786ea84c69bbebf2158194a38.
The *MemorySpaceMap assigned with NULL (line 1710) value might be
accessed (line 1726/1730) without any sanity check. Although it won't
happen in practice because of line 1722, we still need to add check
against NULL to make static code analyzer happy.
1710 *MemorySpaceMap = NULL;
...
1722 if (DescriptorCount == *NumberOfDescriptors) {
...
1726Descriptor = *MemorySpaceMap;
...
1730BuildMemoryDescriptor (Descriptor, Entry);
Tests:
Pass build and boot to shell.
Re: [Xen-devel] [PATCH v2] iommu / p2m: add a page_order parameter to iommu_map/unmap_page()
On Mon, Oct 29, 2018 at 01:29:28PM +, Paul Durrant wrote:
> The P2M code currently contains many loops to deal with the fact that,
> while it may be require to handle page orders greater than 4k, the
> IOMMU map and unmap functions do not.
> This patch adds a page_order parameter to those functions and implements
> the necessary loops within. This allows the P2M code to be substantially
> simplified.
>
> NOTE: This patch does not modify the underlying vendor IOMMU
> implementations to deal with page orders of more than 4k.
I'm wondering if it would make sense to drop the _page suffix from
those functions now that they take an order parameter.
> diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
> index 8b438ae4bc..e02dcb101f 100644
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -305,47 +305,76 @@ void iommu_domain_destroy(struct domain *d)
> }
>
> int iommu_map_page(struct domain *d, dfn_t dfn, mfn_t mfn,
> - unsigned int flags)
> + unsigned int page_order, unsigned int flags)
> {
> const struct domain_iommu *hd = dom_iommu(d);
> -int rc;
> +unsigned long i;
>
> if ( !iommu_enabled || !hd->platform_ops )
> return 0;
>
> -rc = hd->platform_ops->map_page(d, dfn, mfn, flags);
> -if ( unlikely(rc) )
> +ASSERT(!(dfn_x(dfn) & ((1ul << page_order) - 1)));
> +ASSERT(!(mfn_x(mfn) & ((1ul << page_order) - 1)));
I would consider using IS_ALIGNED for clarity.
> +
> +for ( i = 0; i < (1ul << page_order); i++ )
> {
> +int ignored, err = hd->platform_ops->map_page(d, dfn_add(dfn, i),
> + mfn_add(mfn, i),
> + flags);
> +
> +if ( likely(!err) )
> +continue;
> +
> if ( !d->is_shutting_down && printk_ratelimit() )
> printk(XENLOG_ERR
> "d%d: IOMMU mapping dfn %"PRI_dfn" to mfn %"PRI_mfn"
> failed: %d\n",
> - d->domain_id, dfn_x(dfn), mfn_x(mfn), rc);
> + d->domain_id, dfn_x(dfn_add(dfn, i)),
> + mfn_x(mfn_add(mfn, i)), err);
> +
> +while (i--)
Missing spaces in the condition.
> +/* assign to something to avoid compiler warning */
> +ignored = hd->platform_ops->unmap_page(d, dfn_add(dfn, i));
You could likely declare ignored here to further limit it's scope?
>
> if ( !is_hardware_domain(d) )
> domain_crash(d);
> +
> +return err;
I might prefer to keep the global rc variable here and just break on
error, also keeping the 'return rc' below as it was. But that's just a
question of taste IMO.
Thanks, Roger.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen-swiotlb: exchange memory with Xen only when pages are contiguous
On 10/30/18 7:21 AM, Paul Durrant wrote: >> -Original Message- >> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf >> Of Joe Jin >> Sent: 30 October 2018 14:13 >> To: Paul Durrant ; Boris Ostrovsky >> ; Konrad Rzeszutek Wilk >> >> Cc: John Sobecki ; DONGLI.ZHANG >> ; linux-ker...@vger.kernel.org" > ker...@vger.kernel.org>; kon...@kernel.org; xen- >> de...@lists.xenproject.org; Christoph Helwig >> Subject: Re: [Xen-devel] [PATCH] xen-swiotlb: exchange memory with Xen >> only when pages are contiguous >> >> On 10/30/18 1:59 AM, Paul Durrant wrote: On 10/25/18 11:56 AM, Joe Jin wrote: > I just discussed this patch with Boris in private, his opinions(Boris, > please correct me if any misunderstood) are: > > 1. With/without the check, both are incorrect, he thought we need to >prevented unalloc'd free at here. > 2. On freeing, if upper layer already checked the memory was DMA-able, >the checking at here does not make sense, we can remove all checks. > 3. xen_create_contiguous_region() and xen_destroy_contiguous_region() >to come in pairs. I tried to added radix_tree to track allocating/freeing and I found >> some memory only allocated but was not freed, I guess it caused by driver >> used dma_pool, that means if lots of such requests, the list will consume >> lot of memory for it. Will continue to work on it, if anyone have good idea for it please let me know, I'd like to try it. >>> FWIW, in my Xen PV-IOMMU test patches, I have also tried keeping a list >> of ranges mapped for DMA and have discovered apparent issues with some >> drivers, particularly tg3, that seem to free mappings that have not been >> allocated (or possibly double-free). I've never fully tracked down the >> issue. >> >> Call trace of first called xen_swiotlb_alloc_coherent(The pages never >> backed to Xen): >> >> [ 23.436333] [] >> xen_swiotlb_alloc_coherent+0x169/0x510 >> [ 23.436623] [] ? kmem_cache_alloc_trace+0x1ed/0x280 >> [ 23.436900] [] dma_pool_alloc+0x11f/0x260 >> [ 23.437190] [] ehci_qh_alloc+0x52/0x120 >> [ 23.437481] [] ehci_setup+0x2bf/0x8e0 >> [ 23.437760] [] ? __dev_printk+0x46/0xa0 >> [ 23.438042] [] ? _dev_info+0x53/0x60 >> [ 23.438327] [] ehci_pci_setup+0xc0/0x5f0 >> [ 23.438615] [] usb_add_hcd+0x25d/0xaf0 >> [ 23.438901] [] usb_hcd_pci_probe+0x406/0x520 >> [ 23.439177] [] ehci_pci_probe+0x36/0x40 >> [ 23.439469] [] local_pci_probe+0x4a/0xb0 >> [ 23.439752] [] ? pci_match_device+0xe5/0x110 >> [ 23.440027] [] pci_device_probe+0xd1/0x120 >> [ 23.440320] [] driver_probe_device+0x20c/0x4d0 >> [ 23.440599] [] __driver_attach+0x9b/0xa0 >> [ 23.440879] [] ? __device_attach+0x50/0x50 >> >> Above was EHCI used DMA pool to allocate DMA memory. >> >> During my testing, ~1000 entries was not freed, if more PCI devices >> use DMA pool, the tree/list will have more entries, looks it's not a >> good idea that use a list to track it. >> > > Yes, it seems pools can hang onto a serious number of allocations so a list > is probably not wise. I agree with you. > What I was pointing out, though, is that it appears you can't even track > mappings (as opposed to allocations) with a list. Right. > either because drivers apparently try to unmap things they have not mapped. If this happened, should be fixed by driver :) Thanks, Joe > > Paul > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen-swiotlb: exchange memory with Xen only when pages are contiguous
> -Original Message- > From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf > Of Joe Jin > Sent: 30 October 2018 14:48 > To: Paul Durrant ; Boris Ostrovsky > ; Konrad Rzeszutek Wilk > > Cc: John Sobecki ; DONGLI.ZHANG > ; linux-ker...@vger.kernel.org" ker...@vger.kernel.org>; kon...@kernel.org; xen- > de...@lists.xenproject.org; Christoph Helwig > Subject: Re: [Xen-devel] [PATCH] xen-swiotlb: exchange memory with Xen > only when pages are contiguous > > On 10/30/18 7:21 AM, Paul Durrant wrote: > >> -Original Message- > >> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On > Behalf > >> Of Joe Jin > >> Sent: 30 October 2018 14:13 > >> To: Paul Durrant ; Boris Ostrovsky > >> ; Konrad Rzeszutek Wilk > >> > >> Cc: John Sobecki ; DONGLI.ZHANG > >> ; linux-ker...@vger.kernel.org" >> ker...@vger.kernel.org>; kon...@kernel.org; xen- > >> de...@lists.xenproject.org; Christoph Helwig > >> Subject: Re: [Xen-devel] [PATCH] xen-swiotlb: exchange memory with Xen > >> only when pages are contiguous > >> > >> On 10/30/18 1:59 AM, Paul Durrant wrote: > On 10/25/18 11:56 AM, Joe Jin wrote: > > I just discussed this patch with Boris in private, his > opinions(Boris, > > please correct me if any misunderstood) are: > > > > 1. With/without the check, both are incorrect, he thought we need to > >prevented unalloc'd free at here. > > 2. On freeing, if upper layer already checked the memory was DMA- > able, > >the checking at here does not make sense, we can remove all > checks. > > 3. xen_create_contiguous_region() and > xen_destroy_contiguous_region() > >to come in pairs. > I tried to added radix_tree to track allocating/freeing and I found > >> some > memory only allocated but was not freed, I guess it caused by driver > >> used > dma_pool, that means if lots of such requests, the list will consume > >> lot > of memory for it. Will continue to work on it, if anyone have good > idea > for it please let me know, I'd like to try it. > > >>> FWIW, in my Xen PV-IOMMU test patches, I have also tried keeping a > list > >> of ranges mapped for DMA and have discovered apparent issues with some > >> drivers, particularly tg3, that seem to free mappings that have not > been > >> allocated (or possibly double-free). I've never fully tracked down the > >> issue. > >> > >> Call trace of first called xen_swiotlb_alloc_coherent(The pages never > >> backed to Xen): > >> > >> [ 23.436333] [] > >> xen_swiotlb_alloc_coherent+0x169/0x510 > >> [ 23.436623] [] ? > kmem_cache_alloc_trace+0x1ed/0x280 > >> [ 23.436900] [] dma_pool_alloc+0x11f/0x260 > >> [ 23.437190] [] ehci_qh_alloc+0x52/0x120 > >> [ 23.437481] [] ehci_setup+0x2bf/0x8e0 > >> [ 23.437760] [] ? __dev_printk+0x46/0xa0 > >> [ 23.438042] [] ? _dev_info+0x53/0x60 > >> [ 23.438327] [] ehci_pci_setup+0xc0/0x5f0 > >> [ 23.438615] [] usb_add_hcd+0x25d/0xaf0 > >> [ 23.438901] [] usb_hcd_pci_probe+0x406/0x520 > >> [ 23.439177] [] ehci_pci_probe+0x36/0x40 > >> [ 23.439469] [] local_pci_probe+0x4a/0xb0 > >> [ 23.439752] [] ? pci_match_device+0xe5/0x110 > >> [ 23.440027] [] pci_device_probe+0xd1/0x120 > >> [ 23.440320] [] driver_probe_device+0x20c/0x4d0 > >> [ 23.440599] [] __driver_attach+0x9b/0xa0 > >> [ 23.440879] [] ? __device_attach+0x50/0x50 > >> > >> Above was EHCI used DMA pool to allocate DMA memory. > >> > >> During my testing, ~1000 entries was not freed, if more PCI devices > >> use DMA pool, the tree/list will have more entries, looks it's not a > >> good idea that use a list to track it. > >> > > > > Yes, it seems pools can hang onto a serious number of allocations so a > list is probably not wise. > > I agree with you. > > > What I was pointing out, though, is that it appears you can't even track > mappings (as opposed to allocations) with a list. > > Right. > > > > either because drivers apparently try to unmap things they have not > mapped. > > If this happened, should be fixed by driver :) Oh, totally agreed. I fear the breakage is quite indemic throughout many drivers though :-( Paul > > Thanks, > Joe > > > > Paul > > > > ___ > Xen-devel mailing list > Xen-devel@lists.xenproject.org > https://lists.xenproject.org/mailman/listinfo/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [Xen-users] [XEN][ARM] WiFi bridge creation
> > > > > Hello, > > > > > We are using Hikey960 with Debian as Dom0 and DomU. This board has > > > > > only WiFi interface. We want to create bridge between Dom0 and DomU > > > > > so that DomU has internet access. We tried to create bridge using > > > > > brtcl > > > > > command, but it is not working. Please provide pointers. > > > > AFAIK, it's not working > > > > https://marc.info/?l=linux-wireless&m=136743495526905&w=2 > > > > "There is a proposed fix that is included in OpenWrt" > > > > https://marc.info/?l=linux-wireless&m=145591129008322&w=2 > > > > More details are avilable in OpenWrt WiKi > > > > https://wiki.openwrt.org/doc/recipes/relayclient > > > > -vlado > > > Hi, > > > As per below link, it is possible to share Internet via WiFi between > > > Dom0 and DomU,. > > > https://wiki.xenproject.org/wiki/Xen_in_WiFi_networks > > > Tried the suggested solution using ebtables, but it did not work. > > > * ebtables -t nat -A POSTROUTING -s 00:60:00:00:00:01 \ > > > -j snat --to-source 00:60:aa:bb:cc:dd* > > > In the configurations file we have added below configuration in DomU > > > config file. > > > * vif = ['mac=00:16:3e:64:b8:40']* > > > Apart from that do we need to add any addition configuration? > > NAT is a different story. Worked for me with Armbian(no XEN) and Atheros > > 9280 > > couple of years ago. I used Ansible to configure it. > > https://github.com/vbotka/ansible-linux-postinstall/blob/master/templates/router1-iptables.j2 Vikram K wrote: > Thanks Vladimir. > Can some one provide pointer/reference on how to use NAT to share WiFi > between Dom0 and DomU. > Followed the instruction provided in the below link, but no success. > https://wiki.debian.org/BridgeNetworkConnections#Bridging_with_a_wireless_NIC NAT is feasible. Follow the links and come back with specific questions in an appropriate list, if needed. Wifi bridge is NO-GO at the moment. A: Because we read from top to bottom. Q: Why should I start my reply below the quoted text? A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: The lost context. Q: What makes top-posted replies harder to read than bottom-posted? A: Yes. Q: Should I trim down the quoted part of an email to which I'm replying? -vlado pgporg4ZOEtu6.pgp Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] use consistent values when consuming runtime-changeable parameters
On 30/10/18 14:44, Jan Beulich wrote: > There's no guarantee that e.g. a switch() control expression's memory > operand(s) get(s) read just once. Guard against the compiler producing > "unexpected" code by sprinkling around some ACCESS_ONCE(). > > I'm leaving alone opt_conswitch[]: It gets accessed in quite a few > places anyway, and an intermediate change won't have any severe effect > afaict. > > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] dom0/pvh: Dom0 PVH with PCI passthrough support status
On Tue, Oct 30, 2018 at 01:32:38PM +0200, Alexandru Vasile wrote: > Hello, > > > > There is some low-hanging fruit, both in Xen and the Linux kernel, > > which can really be worked in parallel by different parties, so let me > > know if you have some capacity and we can speak about sharing the > > workload. > > Could you share more details about the low-hanging fruit? > > > Following with an update, I managed to start a PVH Dom0 with the patches > from Roger’s fixes branch > http://xenbits.xen.org/gitweb/?p=people/royger/xen.git;a=shortlog;h=refs/heads/fixes-pvh-v2 > and with the xen kernel tip > https://kernel.googlesource.com/pub/scm/linux/kernel/git/xen/tip/ (a978a5b – > latest commit). > > When trying to PCI passthrough a NIC to a HVM DomU guest from PVH Dom0, the > host completely freezes and reboots and xl returns the following errors: > > libxl: error:libxl_qmp.c:334:qmp_handle_error_reponse: Domain 1:received an > error message from QMP server: Mapping machine irq 16 to pirq -1 failed: > Function not implemented > > libxl: error:libxl_pci.c:1300:libxl__add_pcidevs: Domain > 1:libxl_device_pci_add failed: -3 > > libxl: error:libxl_create.c:1522:domcreate_attach_devices: Domain 1:unable > to add pci devices > > > Is someone familiar with this problem or the next steps needed in order to > make it work properly? I'm afraid you are likely the first to attempt PCI passthrough from a PVH Dom0, so there's likely some work to get it running. The first step would be to figure out why your host freezes. Are you running a version of the hypervisor built with debug=y? (that's the default on staging). Do you have a serial console setup in order to catch any Xen messages? In which case, do you get anything on the serial before the reboot? > > Steps to reproduce: > > 1. Start xencommons: sudo ./xen/etc/init.d/xencommons start > > 2. Assign PCI for NIC: sudo ./xen/sbin/xl pci-assignable-add 00:1f.6 > > 3. Create HVM DomU: sudo ./xen/sbin/xl create domU_hvm.cfg > > > The grub command for xen Dom0 as found in /etc/default/grub: > > GRUB_CMDLINE_XEN="dom0=pvh dom0_mem=8192M,max:8192M loglvl=all > sync_console_to_ring=true com1=115200,8n1 console=com1 I see you have a serial configured, is there anything printed there before the reboot? I would recommend that you also add sync_console in order to make sure no messages are dropped. > iommu=debug,verbose,workaround_bios_bug iommu_inclusive iommu_inclusive is not a valid option [0], you can just drop it. > xen-pciback.passthrough=1" > > The same problem is present if the above command does not contain > ‘xen-pciback.passthrough=1’. You can drop this chunk, that's not a Xen command line option [0]. Thanks, Roger. [0] https://xenbits.xen.org/docs/unstable/misc/xen-command-line.html ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5] arch/x86: Add registers to vm_event
On Tue, Oct 30, 2018 at 7:19 AM Jan Beulich wrote:
>
> >>> On 30.10.18 at 13:26, wrote:
> > On 10/30/18 1:33 PM, Jan Beulich wrote:
> > On 30.10.18 at 11:07, wrote:
> >>> --- a/xen/include/public/vm_event.h
> >>> +++ b/xen/include/public/vm_event.h
> >>> @@ -29,7 +29,7 @@
> >>>
> >>> #include "xen.h"
> >>>
> >>> -#define VM_EVENT_INTERFACE_VERSION 0x0003
> >>> +#define VM_EVENT_INTERFACE_VERSION 0x0004
> >>>
> >>> #if defined(__XEN__) || defined(__XEN_TOOLS__)
> >>>
> >>> @@ -157,6 +157,12 @@
> >>> #define VM_EVENT_X86_CR42
> >>> #define VM_EVENT_X86_XCR0 3
> >>>
> >>> +/* The limit field is right-shifted by 12 bits if .ar.g is set. */
> >>> +struct x86_selector_reg {
> >>
> >> I'm sorry for not having noticed this earlier, but this needs proper
> >> prefixing: Matching struct vm_event_regs_x86, it should at least
> >> be prefixed by vm_event_. Strictly speaking xen_ as the very
> >> first thing would also be required, but I'll leave that to the VM
> >> event maintainers to decide. With this
> >> Reviewed-by: Jan Beulich
> >
> > I am fine with either approach (so leaving it as it is not a problem),
> > so we'll go with Tamas' preference. Tamas, what's your opinion?
>
> FAOD leaving as is is not an option - at least vm_event_ needs to
> be added, to not chance collision with a future addition in Xen itself.
I agree, we should keep things prefixed with vm_event_ in this header.
Tamas
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v8 6/8] docs: documentation about static shared memory regions
Stefano Stabellini writes ("[PATCH v8 6/8] docs: documentation about static
shared memory regions"):
> Author: Zhongze Liu
>
> Add docs to document the motivation, usage, use cases and other
> relevant information about the static shared memory feature.
>
> This is for the proposal "Allow setting up shared memory areas between VMs
> from xl config file". See:
Thanks. I'm reviewing this series and I obviously needed to start
with this patch so I could see what was going on.
> diff --git a/docs/man/xl-static-shm-configuration.pod.5
> b/docs/man/xl-static-shm-configuration.pod.5
> new file mode 100644
> index 000..81ff3f1
> --- /dev/null
> +++ b/docs/man/xl-static-shm-configuration.pod.5
...
> +* Uniquely identified by a string that is no longer than 128 characters,
> which
> +is called an B in this document.
> +
> +* Backed by exactly one domain, which is called a B domain, and all
> +the other domains who are also sharing this region are called Bs.
Would it be possible to rename these concepts ? Nowadays it is
generally preferable to avoid master/slave terminology. Perhaps
`owning' and `borrowing' domains ? I'm not sure exactly what the
precise relationship is. It would be good to explain that by
explaining what the semantic difference is between the roles of the
owning and borrowing domains.
> +More formally, the string is a series of comma-separated keyword/value
> +pairs. Each parameter may be specified at most once. Default values apply if
> +the parameter is not specified.
Thanks for the formal syntax specification.
> +=item Description
> +
> +The unique identifier of the shared memory region.
> +
> +Every identifier could appear only once in each xl config file.
You need to specify in what scope this identifier is unique.
Obviously it is unique with an owning domain; but is is unique within
the host ?
Looking at the config syntax I think it is unique within the host,
because the borrowing domain config syntax does not specify the owning
domain. So the statement
Every identifier could appear only once in each xl config file.
is rather more limited than it could be.
Err, wait. I have just noticed something. You are saying a domain
cannot take on the slave role multiple times for the same ID
(presumably, with different offsets).
Why this limitation ? It seems artificial (and is perhaps due to the
libxl xenstore control data structure). I guess it's liveable with if
we don't bake it into the guest ABI or the config syntax.
> +=item B/B
> +=item Description
> +The boundaries of the shared memory area.
> +=item Supported values
> +
> +Same with B.
Units, please.
Also, which memory namespace (address space) is this in ? I think
guest [pseudo]physical. (Does that mean that this feature is not ever
going to be available for PV such as x86 PV?) Please state the
address space, anyway - ideally with an appropriate reference to some
architectural document which defines the various address spaces,
although I suspect there is no such document :-(.
The effect of this facility on the guest ABI needs to be stated. I
think that specifying this stuff provides (as far as the guests are
concerned) a static area of guest pseudophysical space which is shared
between the various guests.
And there is no built-in way provided for the guest to discover that
this has happened ? The guest is just supposed to know ? If so that
seems unfortunate. It would be nice to advertise this somehow.
> +=item Supported values
> +
> +Decimals or hexadecimals with a prefix "0x", and should be the multiple of
> the
> +hypervisor page granularity (currently 4K on both ARM and x86).
Is it not also necessary to avoid certain guest pseudophysical areas
because they are reserved, or used by Xen or the tools for RAM, or
something ?
> +=item Description
> +
> +The backing area would be taken from one domain, which we will mark as
> +the "master domain", and this domain should be created prior to any
> +other slave domains that depend on it. The master's shared memory range
> +is NOT allocated in addition to its regular memory. Hence, it is usually
> +a good idea to choose a subrange of the regular guest memory allocation,
> +which starts at GUEST_RAM0_BASE, see xen/include/public/arch-arm.h.
This is not arch-neutral of course.
It is an unfortunate that this setup requires the system administrator
and guest to have intimate knowledge of Xen's approach to memory
layout. It would be nice to have a way to improve that but I guess
the result would be much more complicated.
(Please forgive me if this has already been extensively discussed.)
> +The "slave domain" maps the memory of the master. The address of said
> +mapping should not be overlapping with the normal memory allocation of
> +the slave domain.
Ah, here is the text which I looked for in begin/end. Maybe this
discussion about memory selection would benefit from being moved out
into its own part of the document.
In general this document seems to
Re: [Xen-devel] dom0/pvh: Dom0 PVH with PCI passthrough support status
On Tue, Oct 30, 2018 at 01:32:38PM +0200, Alexandru Vasile wrote: > Hello, > > > > There is some low-hanging fruit, both in Xen and the Linux kernel, > > which can really be worked in parallel by different parties, so let me > > know if you have some capacity and we can speak about sharing the > > workload. > > Could you share more details about the low-hanging fruit? > > > Following with an update, I managed to start a PVH Dom0 with the patches > from Roger’s fixes branch > http://xenbits.xen.org/gitweb/?p=people/royger/xen.git;a=shortlog;h=refs/heads/fixes-pvh-v2 > and with the xen kernel tip > https://kernel.googlesource.com/pub/scm/linux/kernel/git/xen/tip/ (a978a5b – > latest commit). > > When trying to PCI passthrough a NIC to a HVM DomU guest from PVH Dom0, the > host completely freezes and reboots and xl returns the following errors: I think you mean xl returns such error before the host freezes? > > libxl: error:libxl_qmp.c:334:qmp_handle_error_reponse: Domain 1:received an > error message from QMP server: Mapping machine irq 16 to pirq -1 failed: Note the "-1" here. It looks wrong. The toolstack and QEMU probably need to be patched to handle DomU passthrough from a PVH Dom0. Wei. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v8 2/8] libxl: introduce a new structure to represent static shared memory regions
Stefano Stabellini writes ("[PATCH v8 2/8] libxl: introduce a new structure to
represent static shared memory regions"):
> From: Zhongze Liu
>
> Author: Zhongze Liu
>
> Add a new structure to the IDL family to represent static shared memory
> regions
> as proposed in the proposal "Allow setting up shared memory areas between VMs
> from xl config file" (see [1]).
>
> And deleted some trailing white spaces.
Can you please not add unrelated changes, even if they are only white
space changes ? You can put them in a pre-patch and if you do that
please put my ack on the pre-patch :-).
> +libxl_sshm_cachepolicy = Enumeration("sshm_cachepolicy", [
> +(-1, "UNKNOWN"),
> +(0, "ARM_NORMAL"), # ARM policies should be < 32
> +(32, "X86_NORMAL"), # X86 policies should be >= 32
> +], init_val = "LIBXL_SSHM_CACHE_POLICY_UNKNOWN")
What ? Why do these need separating like that ? This is quite odd.
> +libxl_sshm_prot = Enumeration("sshm_prot", [
> +(-1, "UNKNOWN"),
> +(3, "RW"),
> +], init_val = "LIBXL_SSHM_PROT_UNKNOWN")
Why 3 ?
> +libxl_sshm_role = Enumeration("sshm_role", [
> +(-1, "UNKNOWN"),
> +(0, "MASTER"),
> +(1, "SLAVE"),
> +], init_val = "LIBXL_SSHM_ROLE_UNKNOWN")
See my comments on the docs patch about the master/slave terminology.
Wouldn't it be better for the UNKNOWN values to be 0 ?
That would eliminate a class of possible bugs (although we do try to
avoid them anyway) where the variables are not initialised. It would
also avoid all of these extra init_val settings:
Thanks,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 5/5] xen/keyhandler: Drop keyhandler_scratch
On Fri, Oct 26, 2018 at 09:21:03AM -0600, Jan Beulich wrote:
> >>> On 22.10.18 at 14:58, wrote:
> > --- a/xen/common/efi/boot.c
> > +++ b/xen/common/efi/boot.c
> > @@ -487,6 +487,7 @@ static EFI_FILE_HANDLE __init
> > get_parent_handle(EFI_LOADED_IMAGE *loaded_image,
> > CHAR16 **leaf)
> > {
> > static EFI_GUID __initdata fs_protocol = SIMPLE_FILE_SYSTEM_PROTOCOL;
> > +static CHAR16 __initdata buffer[256];
>
> Did you intentionally halve the size of the buffer?
Seeing the length field consists of two uint8, the maximum length of the
path is 256.
Wei.
>
> Jan
>
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 5/5] xen/keyhandler: Drop keyhandler_scratch
On Mon, Oct 22, 2018 at 01:58:02PM +0100, Andrew Cooper wrote: > With almost all users of keyhandler_scratch gone, clean up the 3 remaining > users and drop the buffer. > > Signed-off-by: Andrew Cooper Reviewed-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v8 3/8] libxl: support mapping static shared memory areas during domain creation
Stefano Stabellini writes ("[PATCH v8 3/8] libxl: support mapping static shared
memory areas during domain creation"):
> +_hidden
> +bool libxl__arch_domain_support_sshm(const libxl_domain_build_info *b_info);
> +
> +_hidden
> +int libxl__arch_domain_sshm_cachepolicy_setdefault(libxl_static_shm *sshm);
> +
> #if defined(__i386__) || defined(__x86_64__)
>
> #define LAPIC_BASE_ADDRESS 0xfee0
> diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
> index 25dc3de..054ad58 100644
> --- a/tools/libxl/libxl_arm.c
> +++ b/tools/libxl/libxl_arm.c
> @@ -1138,6 +1138,21 @@ void
> libxl__arch_domain_build_info_setdefault(libxl__gc *gc,
> libxl_domain_build_info_init_type(b_info, LIBXL_DOMAIN_TYPE_PVH);
> }
>
> +bool libxl__arch_domain_support_sshm(const libxl_domain_build_info *b_info)
> +{
> +return true;
> +}
> +
> +int libxl__arch_domain_sshm_cachepolicy_setdefault(libxl_static_shm *sshm)
> +{
> +if (sshm->cache_policy == LIBXL_SSHM_CACHEPOLICY_UNKNOWN)
> +sshm->cache_policy = LIBXL_SSHM_CACHEPOLICY_ARM_NORMAL;
> +if (sshm->cache_policy >= LIBXL_SSHM_CACHEPOLICY_X86_NORMAL)
> +return ERROR_INVAL;
This cache policy stuff is odd. I couldn't see it being used by the
hypervisor. Why is it even there ?
The same question about prot.
> /*
> * Local variables:
> * mode: C
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index 320dbed..45ae9e4 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -513,6 +513,14 @@ int libxl__domain_build(libxl__gc *gc,
> ret = ERROR_INVAL;
> goto out;
> }
> +
> +/* The p2m has been setup, we could map the static shared memory now. */
> +ret = libxl__sshm_add(gc, domid, d_config->sshms, d_config->num_sshms);
> +if (ret != 0) {
> +LOG(ERROR, "failed to map static shared memory");
> +goto out;
> +}
> +
> ret = libxl__build_post(gc, domid, info, state, vments, localents);
> out:
> return ret;
> @@ -949,6 +957,25 @@ static void initiate_domain_create(libxl__egc *egc,
> goto error_out;
> }
>
> +if (d_config->num_sshms != 0 &&
> +!libxl__arch_domain_support_sshm(&d_config->b_info)) {
> +LOGD(ERROR, domid, "static_shm is not supported by this domain
> type.");
> +ret = ERROR_INVAL;
> +goto error_out;
> +}
> +
> +for (i = 0; i < d_config->num_sshms; ++i) {
> +ret = libxl__sshm_setdefault(gc, domid, &d_config->sshms[i]);
> +if (ret) {
> +LOGD(ERROR, domid, "Unable to set defaults for static shm");
> +goto error_out;
> +}
> +}
> +
> +ret = libxl__sshm_check_overlap(gc, domid,
> +d_config->sshms, d_config->num_sshms);
> +if (ret) goto error_out;
> +
> ret = libxl__domain_make(gc, d_config, &dcs->build_state, &domid);
> if (ret) {
> LOGD(ERROR, domid, "cannot make domain: %d", ret);
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 43947b1..6f31a3d 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -4434,6 +4434,20 @@ static inline const char
> *libxl__qemu_qmp_path(libxl__gc *gc, int domid)
> #endif
>
> /*
> + * Set up static shared ram pages for HVM domains to communicate
> + *
> + * This function should only be called after the memory map is constructed
> + * and before any further memory access.
> + */
> +_hidden int libxl__sshm_add(libxl__gc *gc, uint32_t domid,
> +libxl_static_shm *sshm, int len);
> +
> +_hidden int libxl__sshm_check_overlap(libxl__gc *gc, uint32_t domid,
> + libxl_static_shm *sshms, int len);
> +_hidden int libxl__sshm_setdefault(libxl__gc *gc, uint32_t domid,
> + libxl_static_shm *sshm);
> +
> +/*
> * Local variables:
> * mode: C
> * c-basic-offset: 4
> diff --git a/tools/libxl/libxl_sshm.c b/tools/libxl/libxl_sshm.c
> new file mode 100644
> index 000..f61b80c
> --- /dev/null
> +++ b/tools/libxl/libxl_sshm.c
> @@ -0,0 +1,405 @@
> +#include "libxl_osdeps.h"
> +#include "libxl_internal.h"
> +#include "libxl_arch.h"
> +
> +#define SSHM_PATH(id) GCSPRINTF("/libxl/static_shm/%s", id)
> +
> +#define SSHM_ERROR(domid, sshmid, f, ...) \
> +LOGD(ERROR, domid, "static_shm id = %s: " f, sshmid, ##__VA_ARGS__)
> +
> +
> +/* Set default values for libxl_static_shm */
> +int libxl__sshm_setdefault(libxl__gc *gc, uint32_t domid,
> + libxl_static_shm *sshm)
> +{
> +int rc;
> +
> +if (sshm->role != LIBXL_SSHM_ROLE_SLAVE &&
> +sshm->role != LIBXL_SSHM_ROLE_MASTER)
> +return ERROR_INVAL;
> +if (sshm->begin & ~XC_PAGE_MASK ||
> +sshm->size & ~XC_PAGE_MASK ||
> +(sshm->offset != LIBXL_SSHM_RANGE_UNKNOWN &&
> +sshm->offset & ~XC_PAGE_MASK)) {
> +SSHM
Re: [Xen-devel] [PATCH v2 5/5] xen/keyhandler: Drop keyhandler_scratch
>>> On 30.10.18 at 16:32, wrote:
> On Fri, Oct 26, 2018 at 09:21:03AM -0600, Jan Beulich wrote:
>> >>> On 22.10.18 at 14:58, wrote:
>> > --- a/xen/common/efi/boot.c
>> > +++ b/xen/common/efi/boot.c
>> > @@ -487,6 +487,7 @@ static EFI_FILE_HANDLE __init
>> > get_parent_handle(EFI_LOADED_IMAGE *loaded_image,
>> > CHAR16 **leaf)
>> > {
>> > static EFI_GUID __initdata fs_protocol = SIMPLE_FILE_SYSTEM_PROTOCOL;
>> > +static CHAR16 __initdata buffer[256];
>>
>> Did you intentionally halve the size of the buffer?
>
>
> Seeing the length field consists of two uint8, the maximum length of the
> path is 256.
With
#define DevicePathNodeLength(a) ( ((a)->Length[0]) | ((a)->Length[1] << 8) )
I'd rather say 65536.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 3/7] x86/pvh: allow PVH Dom0 to use the debug IO port console
Force trapping accesses to IO port 0xe9 for a PVH Dom0, so it can print to the HVM debug console. Signed-off-by: Roger Pau Monné --- Cc: Jan Beulich Cc: Andrew Cooper Cc: Wei Liu --- Changes since v2: - Always enable the E9 debug console. Changes since v1: - Use a define for 0xe9. - Expand 'List of' in the Xen command doc. --- xen/arch/x86/dom0_build.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c index fe73cef899..038e37132a 100644 --- a/xen/arch/x86/dom0_build.c +++ b/xen/arch/x86/dom0_build.c @@ -433,6 +433,12 @@ int __init dom0_setup_permissions(struct domain *d) rc |= ioports_deny_access(d, pmtmr_ioport, pmtmr_ioport + 3); /* PCI configuration space (NB. 0xcf8 has special treatment). */ rc |= ioports_deny_access(d, 0xcfc, 0xcff); +#ifdef CONFIG_HVM +if ( is_hvm_domain(d) ) +/* HVM debug console IO port. */ +rc |= ioports_deny_access(d, XEN_HVM_DEBUGCONS_IOPORT, + XEN_HVM_DEBUGCONS_IOPORT); +#endif /* Command-line I/O ranges. */ process_dom0_ioports_disable(d); -- 2.19.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 5/7] vpci: fix execution of long running operations
BAR map/unmap is a long running operation that needs to be preempted
in order to avoid overrunning the assigned vCPU time (or even
triggering the watchdog).
Current logic for this preemption is wrong, and won't work at all for
AMD since only Intel makes use of hvm_io_pending (and even in that
case the current code is wrong).
Instead move the code that performs the mapping/unmapping to
a tasklet and pause the guest vCPU until the {un}mapping is done and
the memory decoding bit has been toggled.
Signed-off-by: Roger Pau Monné
[ioreq parts]
Reviewed-by: Paul Durrant
---
Cc: Paul Durrant
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: George Dunlap
Cc: Ian Jackson
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
---
xen/arch/x86/hvm/ioreq.c | 3 --
xen/common/domain.c | 2 ++
xen/drivers/vpci/header.c | 70 +++
xen/include/xen/vpci.h| 15 +++--
4 files changed, 48 insertions(+), 42 deletions(-)
diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index e2e755a8a1..58a86f9225 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -85,9 +85,6 @@ bool hvm_io_pending(struct vcpu *v)
struct hvm_ioreq_server *s;
unsigned int id;
-if ( has_vpci(d) && vpci_process_pending(v) )
-return true;
-
FOR_EACH_IOREQ_SERVER(d, id, s)
{
struct hvm_ioreq_vcpu *sv;
diff --git a/xen/common/domain.c b/xen/common/domain.c
index b8d4848970..10bfb55909 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -153,6 +153,8 @@ struct vcpu *vcpu_create(
grant_table_init_vcpu(v);
+vpci_init_vcpu(v);
+
if ( !zalloc_cpumask_var(&v->cpu_hard_affinity) ||
!zalloc_cpumask_var(&v->cpu_hard_affinity_tmp) ||
!zalloc_cpumask_var(&v->cpu_hard_affinity_saved) ||
diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c
index 9234de9b26..4af85d3c02 100644
--- a/xen/drivers/vpci/header.c
+++ b/xen/drivers/vpci/header.c
@@ -118,39 +118,48 @@ static void modify_decoding(const struct pci_dev *pdev,
bool map, bool rom_only)
cmd);
}
-bool vpci_process_pending(struct vcpu *v)
+static void vpci_process_pending(unsigned long data)
{
-if ( v->vpci.mem )
+struct vcpu *v = (void *)data;
+struct map_data map_data = {
+.d = v->domain,
+.map = v->vpci.map,
+};
+int rc;
+
+ASSERT(v->vpci.mem && atomic_read(&v->pause_count));
+
+while ( (rc = rangeset_consume_ranges(v->vpci.mem, map_range, &map_data))
==
+-ERESTART )
{
-struct map_data data = {
-.d = v->domain,
-.map = v->vpci.map,
-};
-int rc = rangeset_consume_ranges(v->vpci.mem, map_range, &data);
-
-if ( rc == -ERESTART )
-return true;
-
-spin_lock(&v->vpci.pdev->vpci->lock);
-/* Disable memory decoding unconditionally on failure. */
-modify_decoding(v->vpci.pdev, !rc && v->vpci.map,
-!rc && v->vpci.rom_only);
-spin_unlock(&v->vpci.pdev->vpci->lock);
-
-rangeset_destroy(v->vpci.mem);
-v->vpci.mem = NULL;
-if ( rc )
-/*
- * FIXME: in case of failure remove the device from the domain.
- * Note that there might still be leftover mappings. While this is
- * safe for Dom0, for DomUs the domain will likely need to be
- * killed in order to avoid leaking stale p2m mappings on
- * failure.
- */
-vpci_remove_device(v->vpci.pdev);
+tasklet_schedule(&v->vpci.task);
+return;
}
-return false;
+spin_lock(&v->vpci.pdev->vpci->lock);
+/* Disable memory decoding unconditionally on failure. */
+modify_decoding(v->vpci.pdev, !rc && v->vpci.map,
+!rc && v->vpci.rom_only);
+spin_unlock(&v->vpci.pdev->vpci->lock);
+
+rangeset_destroy(v->vpci.mem);
+v->vpci.mem = NULL;
+if ( rc )
+/*
+ * FIXME: in case of failure remove the device from the domain.
+ * Note that there might still be leftover mappings. While this is
+ * safe for Dom0, for DomUs the domain will likely need to be
+ * killed in order to avoid leaking stale p2m mappings on
+ * failure.
+ */
+vpci_remove_device(v->vpci.pdev);
+
+vcpu_unpause(v);
+}
+
+void vpci_init_vcpu(struct vcpu *v)
+{
+tasklet_init(&v->vpci.task, vpci_process_pending, (unsigned long)v);
}
static int __init apply_map(struct domain *d, const struct pci_dev *pdev,
@@ -183,6 +192,9 @@ static void defer_map(struct domain *d, struct pci_dev
*pdev,
curr->vpci.mem = mem;
curr->vpci.map = map;
curr->vpci.rom_only = rom_only;
+/* Pause the vCPU and schedule the tasklet that will perform the mapping.
*/
+vcpu_pause_nosync(curr);
+tasklet_schedule(&curr->vpci.task);
}
static int modify_
[Xen-devel] [PATCH v3 2/7] x86/hvm: introduce a define for the debug output IO port
No functional change intended.
Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: George Dunlap
Cc: Ian Jackson
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
---
xen/arch/x86/hvm/hvm.c| 4 ++--
xen/drivers/char/console.c| 2 +-
xen/include/public/arch-x86/xen.h | 7 +++
3 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 42d7a9bd1b..0e9d316b40 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -545,7 +545,7 @@ static int hvm_print_line(
struct domain *cd = current->domain;
char c = *val;
-ASSERT(bytes == 1 && port == 0xe9);
+ASSERT(bytes == 1 && port == XEN_HVM_DEBUGCONS_IOPORT);
/* Deny any input requests. */
if ( dir != IOREQ_WRITE )
@@ -654,7 +654,7 @@ int hvm_domain_initialise(struct domain *d)
rtc_init(d);
-register_portio_handler(d, 0xe9, 1, hvm_print_line);
+register_portio_handler(d, XEN_HVM_DEBUGCONS_IOPORT, 1, hvm_print_line);
if ( hvm_tsc_scaling_supported )
d->arch.hvm.tsc_scaling_ratio = hvm_default_tsc_scaling_ratio;
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 3b75f7a472..734abd2552 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -458,7 +458,7 @@ static inline void xen_console_write_debug_port(const char
*buf, size_t len)
unsigned long tmp;
asm volatile ( "rep outsb;"
: "=&S" (tmp), "=&c" (tmp)
- : "0" (buf), "1" (len), "d" (0xe9) );
+ : "0" (buf), "1" (len), "d" (XEN_HVM_DEBUGCONS_IOPORT) );
}
#endif
diff --git a/xen/include/public/arch-x86/xen.h
b/xen/include/public/arch-x86/xen.h
index 69ee4bc40d..c76622654a 100644
--- a/xen/include/public/arch-x86/xen.h
+++ b/xen/include/public/arch-x86/xen.h
@@ -346,6 +346,13 @@ struct xen_arch_domainconfig {
#define XEN_CPUID XEN_EMULATE_PREFIX "cpuid"
#endif
+/*
+ * Debug console IO port, also called "port E9 hack". Each character written
+ * to this IO port will be printed on the hypervisor console, subject to log
+ * level restrictions.
+ */
+#define XEN_HVM_DEBUGCONS_IOPORT 0xe9
+
#endif /* __XEN_PUBLIC_ARCH_X86_XEN_H__ */
/*
--
2.19.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 0/7] x86/pvh: fix fixes for PVH Dom0
Hello, The following series contain miscellaneous fixes for a PVH Dom0. I've found out this issues while trying to boot on an AMD EPYC box. The series can be found on my git repo: git://xenbits.xen.org/people/royger/xen.git fixes-pvh-v3 Roger Pau Monne (7): x86/pvh: fix TSC mode setup for PVH Dom0 x86/hvm: introduce a define for the debug output IO port x86/pvh: allow PVH Dom0 to use the debug IO port console vpci: fix updating the command register vpci: fix execution of long running operations vpci/msix: carve p2m hole for MSIX MMIO regions amd/pvh: enable ACPI C1E disable quirk on PVH Dom0 xen/arch/x86/cpu/amd.c| 13 +++-- xen/arch/x86/dom0_build.c | 11 xen/arch/x86/hvm/hvm.c| 4 +- xen/arch/x86/hvm/ioreq.c | 3 -- xen/arch/x86/hvm/svm/svm.c| 21 xen/arch/x86/time.c | 2 +- xen/common/domain.c | 2 + xen/drivers/char/console.c| 2 +- xen/drivers/vpci/header.c | 84 +++ xen/drivers/vpci/msix.c | 40 +++ xen/include/asm-x86/amd.h | 3 ++ xen/include/public/arch-x86/xen.h | 7 +++ xen/include/xen/vpci.h| 18 +++ 13 files changed, 158 insertions(+), 52 deletions(-) -- 2.19.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 1/7] x86/pvh: fix TSC mode setup for PVH Dom0
A PVH Dom0 might use TSC scaling or other HVM specific TSC
adjustments, so only short-circuit the TSC setup for a classic PV
Dom0.
Signed-off-by: Roger Pau Monné
Acked-by: Jan Beulich
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
---
xen/arch/x86/time.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
index 553698d4ab..03f792e7e5 100644
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -2125,7 +2125,7 @@ void tsc_set_info(struct domain *d,
{
ASSERT(!is_system_domain(d));
-if ( is_hardware_domain(d) )
+if ( is_pv_domain(d) && is_hardware_domain(d) )
{
d->arch.vtsc = 0;
return;
--
2.19.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 7/7] amd/pvh: enable ACPI C1E disable quirk on PVH Dom0
PV Dom0 has a quirk for some AMD processors, where enabling ACPI can
also enable C1E mode. Apply the same workaround as done on PV for a
PVH Dom0, which consist on trapping accesses to the SMI command IO
port and disabling C1E if ACPI is enabled.
Reported-by: Jan Beulich
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: Boris Ostrovsky
Cc: Suravee Suthikulpanit
Cc: Brian Woods
---
Changes since v2:
- Only register the IO port handler for the hardware domain.
---
xen/arch/x86/cpu/amd.c | 13 +
xen/arch/x86/dom0_build.c | 5 +
xen/arch/x86/hvm/svm/svm.c | 21 +
xen/include/asm-x86/amd.h | 3 +++
4 files changed, 38 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c
index c394c1c2ec..18a9e92b3c 100644
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -44,6 +44,9 @@ integer_param("cpuid_mask_thermal_ecx",
opt_cpuid_mask_thermal_ecx);
s8 __read_mostly opt_allow_unsafe;
boolean_param("allow_unsafe", opt_allow_unsafe);
+/* Signal whether the ACPI C1E quirk is required. */
+bool amd_acpi_c1e_quirk;
+
static inline int rdmsr_amd_safe(unsigned int msr, unsigned int *lo,
unsigned int *hi)
{
@@ -427,7 +430,7 @@ static void disable_c1_ramping(void)
}
}
-static void disable_c1e(void *unused)
+void amd_disable_c1e(void *unused)
{
uint64_t msr_content;
@@ -447,7 +450,7 @@ static void check_disable_c1e(unsigned int port, u8 value)
{
/* C1E is sometimes enabled during entry to ACPI mode. */
if ((port == acpi_smi_cmd) && (value == acpi_enable_value))
- on_each_cpu(disable_c1e, NULL, 1);
+ on_each_cpu(amd_disable_c1e, NULL, 1);
}
/*
@@ -626,9 +629,11 @@ static void init_amd(struct cpuinfo_x86 *c)
switch(c->x86)
{
case 0xf ... 0x17:
- disable_c1e(NULL);
- if (acpi_smi_cmd && (acpi_enable_value | acpi_disable_value))
+ amd_disable_c1e(NULL);
+ if (acpi_smi_cmd && (acpi_enable_value | acpi_disable_value)) {
pv_post_outb_hook = check_disable_c1e;
+ amd_acpi_c1e_quirk = true;
+ }
break;
}
diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
index 038e37132a..5e2ad4bd56 100644
--- a/xen/arch/x86/dom0_build.c
+++ b/xen/arch/x86/dom0_build.c
@@ -12,6 +12,7 @@
#include
#include
+#include
#include
#include
#include
@@ -435,9 +436,13 @@ int __init dom0_setup_permissions(struct domain *d)
rc |= ioports_deny_access(d, 0xcfc, 0xcff);
#ifdef CONFIG_HVM
if ( is_hvm_domain(d) )
+{
/* HVM debug console IO port. */
rc |= ioports_deny_access(d, XEN_HVM_DEBUGCONS_IOPORT,
XEN_HVM_DEBUGCONS_IOPORT);
+if ( amd_acpi_c1e_quirk )
+rc |= ioports_deny_access(d, acpi_smi_cmd, acpi_smi_cmd);
+}
#endif
/* Command-line I/O ranges. */
process_dom0_ioports_disable(d);
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 41427e7b9b..828ac5beed 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1273,6 +1273,24 @@ void svm_host_osvw_init()
spin_unlock(&osvw_lock);
}
+static int acpi_c1e_quirk(int dir, unsigned int port, unsigned int bytes,
+ uint32_t *val)
+{
+ASSERT(bytes == 1 && port == acpi_smi_cmd);
+
+if ( dir == IOREQ_READ )
+{
+*val = inb(port);
+return X86EMUL_OKAY;
+}
+
+outb(*val, port);
+if ( *val == acpi_enable_value )
+ on_each_cpu(amd_disable_c1e, NULL, 1);
+
+return X86EMUL_OKAY;
+}
+
static int svm_domain_initialise(struct domain *d)
{
static const struct arch_csw csw = {
@@ -1285,6 +1303,9 @@ static int svm_domain_initialise(struct domain *d)
svm_guest_osvw_init(d);
+if ( is_hardware_domain(d) && amd_acpi_c1e_quirk )
+register_portio_handler(d, acpi_smi_cmd, 1, acpi_c1e_quirk);
+
return 0;
}
diff --git a/xen/include/asm-x86/amd.h b/xen/include/asm-x86/amd.h
index e9867c7823..71fc52924e 100644
--- a/xen/include/asm-x86/amd.h
+++ b/xen/include/asm-x86/amd.h
@@ -148,4 +148,7 @@ extern s8 opt_allow_unsafe;
void fam10h_check_enable_mmcfg(void);
void check_enable_amd_mmconf_dmi(void);
+extern bool amd_acpi_c1e_quirk;
+void amd_disable_c1e(void *);
+
#endif /* __AMD_H__ */
--
2.19.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 4/7] vpci: fix updating the command register
When switching the memory decoding bit in the command register the rest of the changes where dropped, leading to only the memory decoding bit being updated. Fix this by unconditionally writing the guest-requested command except for the memory decoding bit, which will be updated once the p2m changes are performed. Signed-off-by: Roger Pau Monné --- Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson Cc: Jan Beulich Cc: Julien Grall Cc: Konrad Rzeszutek Wilk Cc: Stefano Stabellini Cc: Tim Deegan Cc: Wei Liu --- xen/drivers/vpci/header.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c index 0ec4c082a6..9234de9b26 100644 --- a/xen/drivers/vpci/header.c +++ b/xen/drivers/vpci/header.c @@ -333,8 +333,10 @@ static void cmd_write(const struct pci_dev *pdev, unsigned int reg, * hoping the guest will realize and try again. */ modify_bars(pdev, cmd & PCI_COMMAND_MEMORY, false); -else -pci_conf_write16(pdev->seg, pdev->bus, slot, func, reg, cmd); + +/* Write the new command without updating the memory decoding bit. */ +cmd = (cmd & ~PCI_COMMAND_MEMORY) | (current_cmd & PCI_COMMAND_MEMORY); +pci_conf_write16(pdev->seg, pdev->bus, slot, func, reg, cmd); } static void bar_write(const struct pci_dev *pdev, unsigned int reg, -- 2.19.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 6/7] vpci/msix: carve p2m hole for MSIX MMIO regions
Make sure the MSIX MMIO regions don't have p2m entries setup, so that
accesses to them trap into the hypervisor and can be handled by vpci.
This is a side-effect of commit 042678762 for PVH Dom0, which added
mappings for all the reserved regions into the Dom0 p2m.
Signed-off-by: Roger Pau Monné
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
---
xen/drivers/vpci/header.c | 8
xen/drivers/vpci/msix.c | 40 +++
xen/include/xen/vpci.h| 3 +++
3 files changed, 51 insertions(+)
diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c
index 4af85d3c02..455dd4fc90 100644
--- a/xen/drivers/vpci/header.c
+++ b/xen/drivers/vpci/header.c
@@ -88,6 +88,14 @@ static void modify_decoding(const struct pci_dev *pdev, bool
map, bool rom_only)
uint16_t cmd;
unsigned int i;
+/*
+ * Make sure there are no mappings in the MSIX MMIO areas, so that accesses
+ * can be trapped (and emulated) by Xen when the memory decoding bit is
+ * enabled.
+ */
+if ( map && !rom_only && vpci_make_msix_hole(pdev) )
+return;
+
for ( i = 0; i < ARRAY_SIZE(header->bars); i++ )
{
if ( !MAPPABLE_BAR(&header->bars[i]) )
diff --git a/xen/drivers/vpci/msix.c b/xen/drivers/vpci/msix.c
index 1960dae123..5759551724 100644
--- a/xen/drivers/vpci/msix.c
+++ b/xen/drivers/vpci/msix.c
@@ -21,6 +21,7 @@
#include
#include
+#include
#define VMSIX_SIZE(num) offsetof(struct vpci_msix, entries[num])
@@ -395,6 +396,45 @@ static const struct hvm_mmio_ops vpci_msix_table_ops = {
.write = msix_write,
};
+int vpci_make_msix_hole(const struct pci_dev *pdev)
+{
+struct domain *d = pdev->domain;
+unsigned int i;
+
+if ( !pdev->vpci->msix )
+return 0;
+
+/* Make sure there's a hole for the MSIX table/PBA in the p2m. */
+for ( i = 0; i < ARRAY_SIZE(pdev->vpci->msix->tables); i++ )
+{
+unsigned long start = PFN_DOWN(vmsix_table_addr(pdev->vpci, i));
+unsigned long end = PFN_DOWN(vmsix_table_addr(pdev->vpci, i) +
+ vmsix_table_size(pdev->vpci, i) - 1);
+
+for ( ; start <= end; start++ )
+{
+p2m_type_t t;
+mfn_t mfn = get_gfn_query(d, start, &t);
+
+if ( t == p2m_mmio_direct && mfn_x(mfn) == start )
+clear_identity_p2m_entry(d, start);
+else if ( t != p2m_mmio_dm )
+{
+put_gfn(d, start);
+gprintk(XENLOG_WARNING,
+"%04x:%02x:%02x.%u: existing mapping (mfn: %" PRI_mfn
+"type: %d) at %#lx clobbers MSIX MMIO area\n",
+pdev->seg, pdev->bus, PCI_SLOT(pdev->devfn),
+PCI_FUNC(pdev->devfn), mfn_x(mfn), t, start);
+return -EEXIST;
+}
+put_gfn(d, start);
+}
+}
+
+return 0;
+}
+
static int init_msix(struct pci_dev *pdev)
{
struct domain *d = pdev->domain;
diff --git a/xen/include/xen/vpci.h b/xen/include/xen/vpci.h
index f97c48a8f1..e0c22ad81c 100644
--- a/xen/include/xen/vpci.h
+++ b/xen/include/xen/vpci.h
@@ -151,6 +151,9 @@ struct vpci_vcpu {
#ifdef __XEN__
void vpci_dump_msi(void);
+/* Make sure there's a hole in the p2m for the MSIX mmio areas. */
+int vpci_make_msix_hole(const struct pci_dev *pdev);
+
/* Arch-specific vPCI MSI helpers. */
void vpci_msi_arch_mask(struct vpci_msi *msi, const struct pci_dev *pdev,
unsigned int entry, bool mask);
--
2.19.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 5/5] xen/keyhandler: Drop keyhandler_scratch
On Tue, Oct 30, 2018 at 09:40:17AM -0600, Jan Beulich wrote:
> >>> On 30.10.18 at 16:32, wrote:
> > On Fri, Oct 26, 2018 at 09:21:03AM -0600, Jan Beulich wrote:
> >> >>> On 22.10.18 at 14:58, wrote:
> >> > --- a/xen/common/efi/boot.c
> >> > +++ b/xen/common/efi/boot.c
> >> > @@ -487,6 +487,7 @@ static EFI_FILE_HANDLE __init
> >> > get_parent_handle(EFI_LOADED_IMAGE *loaded_image,
> >> > CHAR16 **leaf)
> >> > {
> >> > static EFI_GUID __initdata fs_protocol =
> >> > SIMPLE_FILE_SYSTEM_PROTOCOL;
> >> > +static CHAR16 __initdata buffer[256];
> >>
> >> Did you intentionally halve the size of the buffer?
> >
> >
> > Seeing the length field consists of two uint8, the maximum length of the
> > path is 256.
>
> With
>
> #define DevicePathNodeLength(a) ( ((a)->Length[0]) | ((a)->Length[1] <<
> 8) )
>
> I'd rather say 65536.
Yes you're right. Can't do calculation when I'm having a cold. :-(
But having 65536 is unrealistic.
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
