[Xen-devel] [libvirt test] 104199: tolerable all pass - PUSHED

flight 104199 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/104199/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 104179 test-armhf-armhf-libvirt-qcow2

[Xen-devel] Reading network data going into a VM from netback.c

Hi all, Recently, I’ve been trying to modify netback.c to print network data that is going into the VM. For example, I’m doing an SSL handshake with the VM as the server, and I send the following hexadecimal string from the client to the VM:

[Xen-devel] [ovmf test] 104198: all pass - PUSHED

flight 104198 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/104198/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 2b631390f9f5f6971c3c8a7f0f47160b80cf072b baseline version: ovmf

[Xen-devel] [qemu-mainline test] 104191: trouble: blocked/broken/pass

flight 104191 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/104191/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-xsm 3 host-install(3)broken REGR. vs.

Re: [Xen-devel] STAO spec in xen.git

On 16/01/17 19:40, Stefano Stabellini wrote: > On Mon, 16 Jan 2017, Ian Jackson wrote: >> Stefano Stabellini writes ("Re: STAO spec in xen.git"): >>> In that case, I think we should still commit it as ODT, but convert it >>> automatically to PDF when we publish it (we do something similar with >>>

[Xen-devel] [PATCH V6] x86/HVM: Introduce struct hvm_pi_ops

The current function pointers in struct vmx_domain for managing hvm posted interrupt can be used also by SVM AVIC. Therefore, this patch introduces struct hvm_pi_ops, which is declared in struct hvm_domain. Signed-off-by: Suravee Suthikulpanit Cc: Jan Beulich

Re: [Xen-devel] [PATCH V5] x86/HVM: Introduce struct hvm_pi_ops

Also, I just noticed another suggestion from Boris to change the hvm_domain.pi_ops to a pointer instead. So, I will be sending out V6. Thanks, Suravee On 1/17/17 09:35, Suravee Suthikulpanit wrote: The current function pointers in struct vmx_domain for managing hvm posted interrupt can be used

[Xen-devel] Reading network data going into a VM from netback.c

Hi all, Recently, I’ve been trying to modify netback.c to print network data that is going into the VM. For example, I’m doing an SSL handshake with the VM as the server, and I send the following hexadecimal string from the client to the VM:

[Xen-devel] [ovmf test] 104196: all pass - PUSHED

flight 104196 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/104196/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 13a50a6fe1dcfa6600c38456ee24e0f9ecf51b5f baseline version: ovmf

[Xen-devel] [PATCH V5] x86/HVM: Introduce struct hvm_pi_ops

The current function pointers in struct vmx_domain for managing hvm posted interrupt can be used also by SVM AVIC. Therefore, this patch introduces the struct hvm_pi_ops in the struct hvm_domain to hold them. Signed-off-by: Suravee Suthikulpanit Cc: Jan Beulich

Re: [Xen-devel] [PATCH V4] x86/HVM: Introduce struct hvm_pi_ops

GRR... sorry again for confusion. Sending error. Please ignore version4. I'll send out V5 instead then. Suravee ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

[Xen-devel] Reading network data going into a VM from netback.c

Hi all, Recently, I’ve been trying to modify netback.c to print network data that is going into the VM. For example, I’m doing an SSL handshake with the VM as the server, and I send the following hexadecimal string from the client to the VM:

Re: [Xen-devel] [PATCH V4] x86/HVM: Introduce struct hvm_pi_ops (RESEND)

From 2b8e159039e3e70414d49932e558b0d26b44be11 Mon Sep 17 00:00:00 2001 From: Suravee Suthikulpanit Date: Sat, 17 Sep 2016 01:19:49 -0500 Subject: [PATCH V4] x86/HVM: Introduce struct hvm_pi_ops The current function pointers in struct vmx_domain for managing hvm

[Xen-devel] [PATCH V4] x86/HVM: Introduce struct hvm_pi_ops

The current function pointers in struct vmx_domain for managing hvm posted interrupt can be used also by SVM AVIC. Therefore, this patch introduces the struct hvm_pi_ops in the struct hvm_domain to hold them. Signed-off-by: Suravee Suthikulpanit Cc: Andrew Cooper

Re: [Xen-devel] PROBLEM: Kernel BUG with raid5 soft + Xen + DRBD - invalid opcode

Hi Shaohua, I've made some new little tests, maybe it can help. - I tried creating the RAID 5 stack with only 2 drives (mdadm --create /dev/md10 --raid-devices=3 --level=5 /dev/sdc1 /dev/sdd1 missing). The same issue is happening. - but one time (still with 2/3 drives), I was not able to

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

flight 104195 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/104195/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl

[Xen-devel] [ovmf test] 104189: trouble: blocked/broken

flight 104189 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/104189/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm3 host-install(3)broken REGR. vs. 104163

Re: [Xen-devel] [PATCH v2 2/2] swiotlb-xen: implement xen_swiotlb_get_sgtable callback

On Mon, 16 Jan 2017, Andrii Anisov wrote: > From: Andrii Anisov > > Signed-off-by: Andrii Anisov Thanks for the patch! > arch/arm/xen/mm.c | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/arch/arm/xen/mm.c

Re: [Xen-devel] [PATCH v2] partially revert "xen: Remove event channel notification through Xen PCI platform device"

On Mon, 16 Jan 2017, Juergen Gross wrote: > On 13/01/17 19:44, Boris Ostrovsky wrote: > > On 01/13/2017 01:26 PM, Stefano Stabellini wrote: > >> On Fri, 13 Jan 2017, Boris Ostrovsky wrote: > >>> On 01/12/2017 04:39 PM, Stefano Stabellini wrote: > The following commit: > > commit

[Xen-devel] [xen-unstable-smoke test] 104194: trouble: blocked/broken

flight 104194 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/104194/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf 3 host-install(3)broken REGR.

Re: [Xen-devel] xc_evtchn_status fails with EFAULT on HVM, the same on PV works

On 16/01/2017 23:06, Marek Marczykowski-Górecki wrote: > On Mon, Jan 16, 2017 at 05:17:59AM -0700, Jan Beulich wrote: > On 14.01.17 at 03:52, wrote: >>> On Sat, Jan 14, 2017 at 01:47:49AM +, Andrew Cooper wrote: In a native situation, SMAP raises #PF

Re: [Xen-devel] xc_evtchn_status fails with EFAULT on HVM, the same on PV works

On Mon, Jan 16, 2017 at 05:17:59AM -0700, Jan Beulich wrote: > >>> On 14.01.17 at 03:52, wrote: > > On Sat, Jan 14, 2017 at 01:47:49AM +, Andrew Cooper wrote: > >> In a native situation, SMAP raises #PF if hardware tries to follow a > >> user pointer outside

Re: [Xen-devel] [PATCH v2 1/2] swiotlb-xen: implement xen_swiotlb_dma_mmap callback

On Mon, 16 Jan 2017, Stefano Stabellini wrote: > On Mon, 16 Jan 2017, Andrii Anisov wrote: > > From: Stefano Stabellini > > > > This function creates userspace mapping for the DMA-coherent memory. > > > > Signed-off-by: Stefano Stabellini

Re: [Xen-devel] [PATCH v2 1/2] swiotlb-xen: implement xen_swiotlb_dma_mmap callback

On Mon, 16 Jan 2017, Andrii Anisov wrote: > From: Stefano Stabellini > > This function creates userspace mapping for the DMA-coherent memory. > > Signed-off-by: Stefano Stabellini > Signed-off-by: Oleksandr Dmytryshyn

[Xen-devel] [xen-unstable-smoke test] 104193: trouble: blocked/broken

flight 104193 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/104193/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf 3 host-install(3)broken REGR.

Re: [Xen-devel] arm: Boot allocator fails with multi node memory

On Mon, 16 Jan 2017, Julien Grall wrote: > Hi Jan, > > On 09/01/17 08:40, Jan Beulich wrote: > > > > > On 07.01.17 at 07:05, wrote: > > > Question: Why this address is not mapped?. If mapped where this va is > > > mapped?. > > > > Well, I think this is the wrong question

Re: [Xen-devel] [PATCH] xen/common: Drop function calls for Xen compile/version information

On 1/16/17 8:04 AM, Andrew Cooper wrote: > The chageset/version/compile information is currently exported as a set of > function calls into a separate translation unit, which is inefficient for all > callers. > > Replace the function calls with externs pointing appropriately into .rodata, > which

[Xen-devel] [libvirt test] 104188: trouble: blocked/broken

flight 104188 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/104188/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-pvops 3 host-install(3)broken REGR. vs. 104179

Re: [Xen-devel] Xen: ARM: Support for mapping ECAM PCIe Config Space Specified In Static ACPI Table

On Mon, 16 Jan 2017, Julien Grall wrote: > Hi Stefano, > > On 03/01/17 19:27, Stefano Stabellini wrote: > > On Wed, 28 Dec 2016, Julien Grall wrote: > > > On 20/12/16 22:33, Stefano Stabellini wrote: > > > > On Tue, 20 Dec 2016, Julien Grall wrote: > > > > > On 20/12/2016 00:54, Stefano

Re: [Xen-devel] [RFC PATCH 08/24] ARM: GICv3: introduce separate pending_irq structs for LPIs

On Mon, 16 Jan 2017, André Przywara wrote: > On 13/01/17 19:37, Stefano Stabellini wrote: > > On Thu, 12 Jan 2017, Andre Przywara wrote: > > Hi Stefano, > > ... > > +list_for_each_entry(lpi_irq, >arch.vgic.pending_lpi_list, entry) > +{ > +if ( lpi_irq->pirq.irq ==

Re: [Xen-devel] [PATCH v2 4/4] The locking order is: first rank lock, then vgic lock. The order is respected everywhere, except for gic_update_one_lr.

On Mon, 16 Jan 2017, Julien Grall wrote: > Hi Stefano, > > On 03/01/17 22:51, Stefano Stabellini wrote: > > On Wed, 28 Dec 2016, Julien Grall wrote: > > > Hi Stefano, > > > > > > On 22/12/16 02:15, Stefano Stabellini wrote: > > > > gic_update_one_lr is called with the vgic lock held, but it

Re: [Xen-devel] arm: Boot allocator fails with multi node memory

Hi Jan, On 09/01/17 08:40, Jan Beulich wrote: On 07.01.17 at 07:05, wrote: Question: Why this address is not mapped?. If mapped where this va is mapped?. Well, I think this is the wrong question to ask. Why would it be mapped if there's no memory there? (XEN)

Re: [Xen-devel] STAO spec in xen.git

On Mon, 16 Jan 2017, Ian Jackson wrote: > Stefano Stabellini writes ("Re: STAO spec in xen.git"): > > In that case, I think we should still commit it as ODT, but convert it > > automatically to PDF when we publish it (we do something similar with > > the markdown docs, converting them from

Re: [Xen-devel] [PATCH] xen/common: Drop function calls for Xen compile/version information

On Mon, 16 Jan 2017, Andrew Cooper wrote: > The chageset/version/compile information is currently exported as a set of > function calls into a separate translation unit, which is inefficient for all > callers. > > Replace the function calls with externs pointing appropriately into .rodata, >

Re: [Xen-devel] PVH CPU hotplug design document

On Mon, 16 Jan 2017, Roger Pau Monné wrote: > On Mon, Jan 16, 2017 at 09:50:53AM -0700, Jan Beulich wrote: > > >>> On 16.01.17 at 17:31, wrote: > > > On Mon, Jan 16, 2017 at 09:09:55AM -0700, Jan Beulich wrote: > > >> >>> On 16.01.17 at 16:14, wrote: >

Re: [Xen-devel] [xen-unstable test] 104187: trouble: blocked/broken

osstest service owner writes ("[xen-unstable test] 104187: trouble: blocked/broken"): > flight 104187 xen-unstable real [real] > http://logs.test-lab.xenproject.org/osstest/logs/104187/ > > Failures and problems with tests :-( > > Tests which did not succeed and are blocking, > including tests

[Xen-devel] [xen-unstable test] 104187: trouble: blocked/broken

flight 104187 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/104187/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf 3 host-install(3)broken REGR. vs.

Re: [Xen-devel] PVH CPU hotplug design document

On Mon, Jan 16, 2017 at 09:50:53AM -0700, Jan Beulich wrote: > >>> On 16.01.17 at 17:31, wrote: > > On Mon, Jan 16, 2017 at 09:09:55AM -0700, Jan Beulich wrote: > >> >>> On 16.01.17 at 16:14, wrote: > >> > On Fri, Jan 13, 2017 at 08:51:57AM -0700, Jan

Re: [Xen-devel] [PATCH] xenstored: remove -L option

On Fri, Jan 13, 2017 at 02:38:21PM +0100, Juergen Gross wrote: > On 13/01/17 14:31, Juergen Gross wrote: > > On 13/01/17 13:18, Wei Liu wrote: > >> The only place that used such option was removed in 388d3011. > >> > >> Signed-off-by: Wei Liu > > > > Reviewed-by: Juergen

Re: [Xen-devel] [PATCH] tools/misc: add AVX512 vpopcntdq in xen-cpuid.c

On Mon, Jan 16, 2017 at 10:37:31AM +, Andrew Cooper wrote: > On 16/01/17 09:41, Wei Liu wrote: > > CC Andrew and Jan > > > > On Mon, Jan 16, 2017 at 04:05:03PM +0800, He Chen wrote: > >> Add AVX512 vpopcntdq information in xen-cpuid.c > >> > >> Signed-off-by: He Chen

Re: [Xen-devel] [PATCH 6/6] x86/cpuid: Offer ITSC to domains which are automatically non-migrateable

On 16/01/17 17:07, Jan Beulich wrote: On 16.01.17 at 12:40, wrote: >> Dom0 doesn't have a toolstack to explicitly decide that ITSC is safe to >> offer. >> For domains which are constructed with disable_migrate set, offer ITSC >> automatically. > I'm afraid

Re: [Xen-devel] [PATCH] x86emul: VEX.B is ignored in compatibility mode

On 13/01/17 13:20, Jan Beulich wrote: > >>> @@ -2235,7 +2241,7 @@ x86_decode( >>> break; >>> } >>> } >>> -if ( mode_64bit() && !vex.r ) >>> +if ( !vex.r ) >>> rex_prefix |= REX_R;

Re: [Xen-devel] [PATCH v3 1/8] public / x86: Introduce __HYPERCALL_dm_op...

>>> On 16.01.17 at 18:07, wrote: > If we don't want to bake 64-bit pointers into the ABI then I guess a > compat layer is the only way. Guess I'll go and stare at macros until my > brain explodes... Well, before you do I'd really hope for Andrew to provide us (or at

Re: [Xen-devel] [PATCH 2/6] x86/cpuid: Introduce recalculate_xstate()

>>> On 16.01.17 at 18:02, wrote: > On 16/01/17 16:45, Jan Beulich wrote: > On 16.01.17 at 12:40, wrote: >>> @@ -154,6 +152,13 @@ struct cpuid_policy >>> }; >>> uint32_t /* b */:32, xss_low, xss_high; >>>

Re: [Xen-devel] [PATCH 3/6] x86/cpuid: Move all xstate leaf handling into guest_cpuid()

On 16/01/17 16:58, Jan Beulich wrote: On 16.01.17 at 12:40, wrote: >> @@ -1007,10 +864,13 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf, >> break; >> >> case XSTATE_CPUID: >> -if ( subleaf > ARRAY_SIZE(p->xstate.raw) )

Re: [Xen-devel] [PATCH 6/6] x86/cpuid: Offer ITSC to domains which are automatically non-migrateable

>>> On 16.01.17 at 12:40, wrote: > Dom0 doesn't have a toolstack to explicitly decide that ITSC is safe to offer. > For domains which are constructed with disable_migrate set, offer ITSC > automatically. I'm afraid "constructed" is ambiguous here: To me, construction

Re: [Xen-devel] [PATCH v3 1/8] public / x86: Introduce __HYPERCALL_dm_op...

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 16 January 2017 16:17 > To: Andrew Cooper > Cc: Ian Jackson ; Jennifer Herbert > ; Paul Durrant ; Wei > Liu

Re: [Xen-devel] [PATCH 2/6] x86/cpuid: Introduce recalculate_xstate()

On 16/01/17 16:45, Jan Beulich wrote: On 16.01.17 at 12:40, wrote: >> All data in the xstate union, other than the Da1 feature word, is derived >> from >> other state; either feature bits from other words, or layout information >> which >> has already been

Re: [Xen-devel] [PATCH 5/6] x86/cpuid: Don't offer HVM hypervisor leaves to PV guests

>>> On 16.01.17 at 12:40, wrote: > Xen leaf 4 is HVM-only. Report a lower max_leaf to PV guests, so they don't > go and investigate a leaf which will return all zeros. > > Signed-off-by: Andrew Cooper Well, if you think it's worth it

Re: [Xen-devel] [PATCH 3/6] x86/cpuid: Move all xstate leaf handling into guest_cpuid()

>>> On 16.01.17 at 12:40, wrote: > @@ -1007,10 +864,13 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf, > break; > > case XSTATE_CPUID: > -if ( subleaf > ARRAY_SIZE(p->xstate.raw) ) > +if ( !p->basic.xsave ||

Re: [Xen-devel] [PATCH v2 4/4] The locking order is: first rank lock, then vgic lock. The order is respected everywhere, except for gic_update_one_lr.

Hi Stefano, On 03/01/17 22:51, Stefano Stabellini wrote: On Wed, 28 Dec 2016, Julien Grall wrote: Hi Stefano, On 22/12/16 02:15, Stefano Stabellini wrote: gic_update_one_lr is called with the vgic lock held, but it calls vgic_get_target_vcpu, which tries to obtain the rank lock. This can

Re: [Xen-devel] PVH CPU hotplug design document

>>> On 16.01.17 at 17:31, wrote: > On Mon, Jan 16, 2017 at 09:09:55AM -0700, Jan Beulich wrote: >> >>> On 16.01.17 at 16:14, wrote: >> > On Fri, Jan 13, 2017 at 08:51:57AM -0700, Jan Beulich wrote: >> >> >>> On 12.01.17 at 13:13,

Re: [Xen-devel] Xenstore domains and XS_RESTRICT

On 07/12/16 08:44, Juergen Gross wrote: > Hi, > > today the XS_RESTRICT wire command of Xenstore is supported by > oxenstored only to drop the privilege of a connection to that of the > domid given as a parameter to the command. > > Using this mechanism with Xenstore running in a stubdom will

Re: [Xen-devel] [PATCH 2/6] x86/cpuid: Introduce recalculate_xstate()

>>> On 16.01.17 at 12:40, wrote: > All data in the xstate union, other than the Da1 feature word, is derived from > other state; either feature bits from other words, or layout information which > has already been collected by Xen's xstate driver. > > Recalculate the

Re: [Xen-devel] PVH CPU hotplug design document

On Mon, Jan 16, 2017 at 09:09:55AM -0700, Jan Beulich wrote: > >>> On 16.01.17 at 16:14, wrote: > > On Fri, Jan 13, 2017 at 08:51:57AM -0700, Jan Beulich wrote: > >> >>> On 12.01.17 at 13:13, wrote: > >> > # Introduction > >> > > >> > One of the

Re: [Xen-devel] [PATCH v2 3/4] arm, vgic_migrate_irq: take the right vgic lock

Hi Stefano, On 03/01/17 23:30, Stefano Stabellini wrote: On Wed, 28 Dec 2016, Julien Grall wrote: On 22/12/16 02:15, Stefano Stabellini wrote: Always take the vgic lock of the old vcpu. When more than one irq migration is requested before the first one completes, take the vgic lock of the

Re: [Xen-devel] [PATCH 1/6] x86/xstate: Fix array overrun on hardware with LWP

>>> On 16.01.17 at 12:40, wrote: > c/s da62246e4c "x86/xsaves: enable xsaves/xrstors/xsavec in xen" introduced > setup_xstate_features() to allocate and fill xstate_offsets[] and > xstate_sizes[]. > > However, fls() casts xfeature_mask to 32bits which truncates LWP out

Re: [Xen-devel] IOMMU fault with IGD passthrough setup on XEN 4.8.0

>>> On 16.01.17 at 16:21, wrote: > BTW, before I generate more verbose && complete debug log, just want to > update that I also see the following in dom0 (without attempting any > pass-through to the IGD device) > But this time the log is not flooding at all. Not

Re: [Xen-devel] [PATCH v3 1/8] public / x86: Introduce __HYPERCALL_dm_op...

>>> On 16.01.17 at 17:05, wrote: > On 13/01/17 12:47, Jan Beulich wrote: >> The kernel already has to parse this structure anyway, and will know the >> bitness of its userspace process. We could easily (at this point) >> require the kernel to turn it into

Re: [Xen-devel] IOMMU fault with IGD passthrough setup on XEN 4.8.0

>>> On 16.01.17 at 16:15, wrote: > On Mon, Jan 16, 2017 at 9:56 PM, Jan Beulich wrote: > >> >>> On 16.01.17 at 14:43, wrote: >> > On Mon, Jan 16, 2017 at 8:37 PM, Jan Beulich wrote: >> >>

Re: [Xen-devel] PVH CPU hotplug design document

>>> On 16.01.17 at 16:14, wrote: > On Fri, Jan 13, 2017 at 08:51:57AM -0700, Jan Beulich wrote: >> >>> On 12.01.17 at 13:13, wrote: >> > # Introduction >> > >> > One of the design goals of PVH is to be able to remove as much Xen PV >> > specific >> >

Re: [Xen-devel] [PATCH v3 1/8] public / x86: Introduce __HYPERCALL_dm_op...

On 13/01/17 12:47, Jan Beulich wrote: > The kernel already has to parse this structure anyway, and will know the > bitness of its userspace process. We could easily (at this point) > require the kernel to turn it into the kernels bitness for forwarding on > to Xen, which covers

Re: [Xen-devel] Xen 4.8 + Linux 4.9 + Credit2 = can't bootup

Roger Pau Monné writes ("Re: [Xen-devel] Xen 4.8 + Linux 4.9 + Credit2 = can't bootup"): > Shouldn't this be: > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git Err, yes, thanks. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org

Re: [Xen-devel] [PATCH 5/8] x86emul: support TBM insns

>>> On 16.01.17 at 15:52, wrote: > On 16/01/17 11:36, Jan Beulich wrote: > On 13.01.17 at 19:48, wrote: >>> On 13/01/17 15:32, Jan Beulich wrote: --- a/xen/arch/x86/x86_emulate/x86_emulate.c +++

Re: [Xen-devel] [PATCH 3/8] x86emul: support BMI1 insns

>>> On 16.01.17 at 15:17, wrote: > On 16/01/17 13:58, Jan Beulich wrote: > On 16.01.17 at 14:51, wrote: >>> Right. What happens in reality is this: >>> >>> --- Xen Test Framework --- >>> Environment: HVM 32bit (No paging) >>> Test VEX.W

Re: [Xen-devel] Xen 4.8 + Linux 4.9 + Credit2 = can't bootup

On Fri, Jan 13, 2017 at 04:27:52PM +, Ian Jackson wrote: > Boris Ostrovsky writes ("Re: [Xen-devel] Xen 4.8 + Linux 4.9 + Credit2 = > can't bootup"): > > I can give it a try although I have practically no experience with > > OSSTest. Is there a way to subscribe to notifications for those

Re: [Xen-devel] STAO spec in xen.git

On Mon, Jan 16, 2017 at 11:26:57AM +, Ian Jackson wrote: > Stefano Stabellini writes ("Re: STAO spec in xen.git"): > > In that case, I think we should still commit it as ODT, but convert it > > automatically to PDF when we publish it (we do something similar with > > the markdown docs,

Re: [Xen-devel] IOMMU fault with IGD passthrough setup on XEN 4.8.0

BTW, before I generate more verbose && complete debug log, just want to update that I also see the following in dom0 (without attempting any pass-through to the IGD device) But this time the log is not flooding at all. Not sure if this is relevant to what I see from the domU with pci pass-through.

Re: [Xen-devel] [PATCH 4/4] x86: add multiboot2 protocol support for EFI platforms

On Mon, Jan 16, 2017 at 09:28:45AM -0500, Doug Goldstein wrote: > On 1/16/17 9:11 AM, Daniel Kiper wrote: > > On Mon, Jan 16, 2017 at 08:41:08AM -0500, Doug Goldstein wrote: > >> On 1/16/17 7:50 AM, Daniel Kiper wrote: > >>> On Mon, Jan 16, 2017 at 05:02:05AM -0700, Jan Beulich wrote: > >>> On

Re: [Xen-devel] IOMMU fault with IGD passthrough setup on XEN 4.8.0

On Mon, Jan 16, 2017 at 9:56 PM, Jan Beulich wrote: > >>> On 16.01.17 at 14:43, wrote: > > On Mon, Jan 16, 2017 at 8:37 PM, Jan Beulich wrote: > >> >>> On 16.01.17 at 10:25, wrote: > >

Re: [Xen-devel] PVH CPU hotplug design document

On Fri, Jan 13, 2017 at 08:51:57AM -0700, Jan Beulich wrote: > >>> On 12.01.17 at 13:13, wrote: > > # Introduction > > > > One of the design goals of PVH is to be able to remove as much Xen PV > > specific > > code as possible, thus limiting the number of Xen PV interfaces

Re: [Xen-devel] [PATCH v3 3/8] dm_op: convert HVMOP_track_dirty_vram

On 12/01/17 14:58, Paul Durrant wrote: > The handle type passed to the underlying shadow and hap functions is > changed for compatibility with the new hypercall buffer. > > NOTE: This patch also modifies the type of the 'nr' parameter of > xc_hvm_track_dirty_vram() from uint64_t to

Re: [Xen-devel] [PATCH V2] Xen: ARM: Zero reserved fields of xatp before making hypervisor call

Hi Stefano, On 03/01/17 18:03, Stefano Stabellini wrote: On Mon, 2 Jan 2017, Juergen Gross wrote: On 28/12/16 01:47, Jiandi An wrote: Ensure all reserved fields of xatp are zero before making hypervisor call to XEN in xen_map_device_mmio(). xenmem_add_to_physmap_one() in XEN fails the mapping

Re: [Xen-devel] PVH CPU hotplug design document

On Fri, Jan 13, 2017 at 08:27:30AM -0700, Jan Beulich wrote: > >>> On 12.01.17 at 20:00, wrote: > > On 12/01/17 12:13, Roger Pau Monné wrote: > >> Extra entries are going to be added for each vCPU available to the hardware > >> domain, up to the maximum number of

Re: [Xen-devel] [PATCH v2 2/2] x86/cpuid: Move x86_vendor from arch_domain to cpuid_policy

On 13/01/17 13:56, Andrew Cooper wrote: > No functional change. > > Signed-off-by: Andrew Cooper > --- > CC: Jan Beulich > CC: Tim Deegan > CC: George Dunlap > CC: Paul Durrant >

Re: [Xen-devel] [OSSTEST PATCH v9 3/3] Create a flight to test OpenStack with xen-unstable and libvirt

Anthony PERARD writes ("Re: [OSSTEST PATCH v9 3/3] Create a flight to test OpenStack with xen-unstable and libvirt"): > Here, it is downloading pip. There's maybe a way to not make it do that. > I'll try to find out. But I think more stuff are going to be downloaded, > all the python packages,

Re: [Xen-devel] [PATCH 5/8] x86emul: support TBM insns

On 16/01/17 11:36, Jan Beulich wrote: On 13.01.17 at 19:48, wrote: >> On 13/01/17 15:32, Jan Beulich wrote: >>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c >>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c >>> @@ -1355,6 +1355,7 @@ static bool vcpu_has( >>>

Re: [Xen-devel] PVH CPU hotplug design document

On Thu, Jan 12, 2017 at 07:00:57PM +, Andrew Cooper wrote: > On 12/01/17 12:13, Roger Pau Monné wrote: [...] > > ## QEMU CPU hotplug using ACPI > > > > The ACPI tables provided to HVM guests contain processor objects, as > > created by > > libacpi. The number of processor objects in the ACPI

Re: [Xen-devel] [PATCH v6 01/14] generic-sections: add section core helpers

On Mon, Jan 09, 2017 at 06:58:19AM -0800, Luis R. Rodriguez wrote: > Linux makes extensive use of custom ELF header sections, > documentation for these are well scatterred. Unify this is > documentation in a central place and provide helpers to > build custom Linux

Re: [Xen-devel] IOMMU fault with IGD passthrough setup on XEN 4.8.0

On Mon, Jan 16, 2017 at 1:43 PM, G.R. wrote: > On Mon, Jan 16, 2017 at 8:37 PM, Jan Beulich wrote: >> >> >>> On 16.01.17 at 10:25, wrote: >> > Here are some relevant logs, please help comment what's going on

Re: [Xen-devel] [PATCH 4/4] x86: add multiboot2 protocol support for EFI platforms

On 1/16/17 9:11 AM, Daniel Kiper wrote: > On Mon, Jan 16, 2017 at 08:41:08AM -0500, Doug Goldstein wrote: >> On 1/16/17 7:50 AM, Daniel Kiper wrote: >>> On Mon, Jan 16, 2017 at 05:02:05AM -0700, Jan Beulich wrote: >>> On 13.01.17 at 20:21, wrote: > Doug v1 - fix

Re: [Xen-devel] [PATCH 3/8] x86emul: support BMI1 insns

On 16/01/17 13:58, Jan Beulich wrote: On 16.01.17 at 14:51, wrote: >> Right. What happens in reality is this: >> >> --- Xen Test Framework --- >> Environment: HVM 32bit (No paging) >> Test VEX.W matching mode: >> andn a5a5, ff00ff00 = 00cc00a5 >> Test VEX.W

[Xen-devel] [PATCH v2 2/3] xen: modify xenstore watch event interface

Today a Xenstore watch event is delivered via a callback function declared as: void (*callback)(struct xenbus_watch *, const char **vec, unsigned int len); As all watch events only ever come with two parameters (path and token) changing the prototype to: void (*callback)(struct

[Xen-devel] [PATCH v2 3/3] xen: optimize xenbus driver for multiple concurrent xenstore accesses

Handling of multiple concurrent Xenstore accesses through xenbus driver either from the kernel or user land is rather lame today: xenbus is capable to have one access active only at one point of time. Rewrite xenbus to handle multiple requests concurrently by making use of the request id of the

[Xen-devel] [PATCH v2 0/3] xen: optimize xenbus performance

The xenbus driver used for communication with Xenstore (all kernel accesses to Xenstore and in case of Xenstore living in another domain all accesses of the local domain to Xenstore) is rather simple especially regarding multiple concurrent accesses: they are just being serialized in spite of

[Xen-devel] [PATCH v2 5/5] fix: add multiboot2 protocol support for EFI platforms

This should be squashed into the 4/4 patch 'x86: add multiboot2 protocol support for EFI platforms'. - fix incorrect assembly (identified by Andrew Cooper) - fix issue where the trampoline size was left as 0 and the way the memory is allocated for the trampolines we would go to the end of an

[Xen-devel] [PATCH v2 1/3] xen: clean up xenbus internal headers

The xenbus driver has an awful mixture of internally and globally visible headers: some of the internally used only stuff is defined in the global header include/xen/xenbus.h while some stuff defined in internal headers is used by other drivers, too. Clean this up by moving the externally used

[Xen-devel] [PATCH v2 0/5] multiboot2 protocol support

This is a series based on v11 of Daniel Kiper's "x86: multiboot2 protocol support" series. It aims to collect up all the fixes and changes that Andrew Cooper, Jan Beulich and myself discovered in code review and testing on actual hardware. I've had problems with the relocation portion of the

[Xen-devel] [PATCH v2 4/5] x86: add multiboot2 protocol support for EFI platforms

From: Daniel Kiper This way Xen can be loaded on EFI platforms using GRUB2 and other boot loaders which support multiboot2 protocol. Signed-off-by: Daniel Kiper Reviewed-by: Doug Goldstein Tested-by: Doug Goldstein

[Xen-devel] [PATCH v2 1/5] x86: add multiboot2 protocol support

From: Daniel Kiper Add multiboot2 protocol support. Alter min memory limit handling as we now may not find it from either multiboot (v1) or multiboot2. This way we are laying the foundation for EFI + GRUB2 + Xen development. Signed-off-by: Daniel Kiper

[Xen-devel] [PATCH v2 2/5] efi: build xen.gz with EFI code

From: Daniel Kiper Build xen.gz with EFI code. We need this to support multiboot2 protocol on EFI platforms. If we wish to load non-ELF file using multiboot (v1) or multiboot2 then it must contain "linear" (or "flat") representation of code and data. This is requirement

[Xen-devel] [PATCH v2 3/5] efi: create new early memory allocator

From: Daniel Kiper There is a problem with place_string() which is used as early memory allocator. It gets memory chunks starting from start symbol and goes down. Sadly this does not work when Xen is loaded using multiboot2 protocol because then the start lives on 1 MiB

Re: [Xen-devel] [PATCH 4/4] x86: add multiboot2 protocol support for EFI platforms

On Mon, Jan 16, 2017 at 08:41:08AM -0500, Doug Goldstein wrote: > On 1/16/17 7:50 AM, Daniel Kiper wrote: > > On Mon, Jan 16, 2017 at 05:02:05AM -0700, Jan Beulich wrote: > > On 13.01.17 at 20:21, wrote: > >>> Doug v1 - fix incorrect assembly (identified by Andrew Cooper) >

Re: [Xen-devel] Xen: ARM: Support for mapping ECAM PCIe Config Space Specified In Static ACPI Table

Hi Stefano, On 03/01/17 19:27, Stefano Stabellini wrote: On Wed, 28 Dec 2016, Julien Grall wrote: On 20/12/16 22:33, Stefano Stabellini wrote: On Tue, 20 Dec 2016, Julien Grall wrote: On 20/12/2016 00:54, Stefano Stabellini wrote: On Mon, 19 Dec 2016, Julien Grall wrote: On 16/12/2016

Re: [Xen-devel] [PATCH 3/8] x86emul: support BMI1 insns

>>> On 16.01.17 at 14:51, wrote: > Right. What happens in reality is this: > > --- Xen Test Framework --- > Environment: HVM 32bit (No paging) > Test VEX.W matching mode: > andn a5a5, ff00ff00 = 00cc00a5 > Test VEX.W opposite to mode: > andn a5a5, ff00ff00

Re: [Xen-devel] IOMMU fault with IGD passthrough setup on XEN 4.8.0

>>> On 16.01.17 at 14:43, wrote: > On Mon, Jan 16, 2017 at 8:37 PM, Jan Beulich wrote: >> >>> On 16.01.17 at 10:25, wrote: >> > Here are some relevant logs, please help comment what's going on here and >> >

Re: [Xen-devel] [PATCH 3/4] efi: create new early memory allocator

On 1/16/17 6:52 AM, Jan Beulich wrote: On 13.01.17 at 20:21, wrote: >> From: Daniel Kiper >> >> There is a problem with place_string() which is used as early memory >> allocator. It gets memory chunks starting from start symbol and goes >> down.

Re: [Xen-devel] [PATCH 3/8] x86emul: support BMI1 insns

On 16/01/17 12:57, Jan Beulich wrote: On 16.01.17 at 13:43, wrote: > On 16.01.17 at 12:59, wrote: >>> On 16/01/17 11:19, Jan Beulich wrote: >>> On 13.01.17 at 18:40, wrote: > On 13/01/17 15:31, Jan Beulich

Re: [Xen-devel] [PATCH V3] x86/HVM: Introduce struct hvm_pi_ops

>>> On 16.01.17 at 14:38, wrote: > So, what if I generalize and simplify as following: > > +/* > + * This structure defines function hooks to support hardware-assisted > + * virtual interrupt delivery to guest. (e.g. VMX PI and SVM AVIC). > + * > + * These hooks

[Xen-devel] Reading network data going into a VM from netback.c

Hi all, Recently, I’ve been trying to modify netback.c to print network data that is going into the VM. For example, I’m doing an SSL handshake with the VM as the server, and I send the following hexadecimal string from the client to the VM:

  1   2   >