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

flight 104175 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/104175/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 15 guest-start/debian.repeat fail REGR. vs. 104170 Regressions which

[Xen-devel] [qemu-mainline test] 104176: regressions - trouble: broken/fail/pass

flight 104176 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/104176/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-multivcpu 3 host-install(3) broken REGR. vs. 104159

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

On Sat, Jan 14, 2017 at 01:47:49AM +, Andrew Cooper wrote: > On 13/01/2017 20:32, Marek Marczykowski-Górecki wrote: > > On Fri, Jan 13, 2017 at 07:54:01PM +, Andrew Cooper wrote: > >> This is a guest kernel bug. The guest kernel has used SMAP to say > >> "please disallow all userspace

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

On 13/01/2017 20:32, Marek Marczykowski-Górecki wrote: > On Fri, Jan 13, 2017 at 07:54:01PM +, Andrew Cooper wrote: >> On 13/01/17 19:40, Marek Marczykowski-Górecki wrote: >>> On Fri, Jan 13, 2017 at 07:27:20PM +, Andrew Cooper wrote: On 13/01/17 18:59, Marek Marczykowski-Górecki

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

On 01/13/2017 10:51 AM, 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 used by >> guests, >>

[Xen-devel] [ovmf baseline-only test] 68364: all pass

This run is configured for baseline tests only. flight 68364 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68364/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 521981ee7608b75b51693ea367c9e1d83687d110 baseline

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

On 01/13/2017 11:27 AM, Ian Jackson wrote: > > osstest's reports are posted to xen-devel. To give you an example of > what they look like, I have pasted below the top of the report from > last test report of linux-linus (including interesting mail headers). > > If you find the mail filtering of

Re: [Xen-devel] [PATCH] xen: do not re-use pirq number cached in pci device msi msg data

On Fri, Jan 13, 2017 at 03:07:51PM -0500, Dan Streetman wrote: > Revert the main part of commit: > af42b8d12f8a ("xen: fix MSI setup and teardown for PV on HVM guests") > > That commit introduced reading the pci device's msi message data to see > if a pirq was previously configured for the

[Xen-devel] [xen-unstable test] 104170: tolerable FAIL - PUSHED

flight 104170 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/104170/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-credit2 6 xen-boot fail in 104162 pass in 104170 test-armhf-armhf-xl-arndale 4

[Xen-devel] [qemu-mainline test] 104169: regressions - FAIL

flight 104169 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/104169/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-arndale 6 xen-boot fail REGR. vs. 104159 Regressions

Re: [Xen-devel] [PATCH] xen: do not re-use pirq number cached in pci device msi msg data

On 01/13/2017 03:07 PM, Dan Streetman wrote: > Revert the main part of commit: > af42b8d12f8a ("xen: fix MSI setup and teardown for PV on HVM guests") > > That commit introduced reading the pci device's msi message data to see > if a pirq was previously configured for the device's msi/msix, and

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

On Fri, 13 Jan 2017, Al Stone wrote: > On 01/13/2017 12:52 PM, Stefano Stabellini wrote: > > On Fri, 13 Jan 2017, Ian Jackson wrote: > >> Stefano Stabellini writes ("STAO spec in xen.git"): > >>> I suggest we commit the STAO spec in the form of the attached ODT > >>> document to xen.git under

Re: [Xen-devel] [PATCH] xen: do not re-use pirq number cached in pci device msi msg data

On Fri, 13 Jan 2017, Dan Streetman wrote: > Revert the main part of commit: > af42b8d12f8a ("xen: fix MSI setup and teardown for PV on HVM guests") > > That commit introduced reading the pci device's msi message data to see > if a pirq was previously configured for the device's msi/msix, and

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

On 01/13/2017 12:52 PM, Stefano Stabellini wrote: > On Fri, 13 Jan 2017, Ian Jackson wrote: >> Stefano Stabellini writes ("STAO spec in xen.git"): >>> I suggest we commit the STAO spec in the form of the attached ODT >>> document to xen.git under docs/misc, for easier editing and consumption >>>

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

On Fri, Jan 13, 2017 at 07:54:01PM +, Andrew Cooper wrote: > On 13/01/17 19:40, Marek Marczykowski-Górecki wrote: > > On Fri, Jan 13, 2017 at 07:27:20PM +, Andrew Cooper wrote: > >> On 13/01/17 18:59, Marek Marczykowski-Górecki wrote: > >>> On Fri, Jan 13, 2017 at 06:37:06PM +, Andrew

Re: [Xen-devel] [PATCH] xen: do not re-use pirq number cached in pci device msi msg data

On Fri, Jan 13, 2017 at 3:00 PM, Boris Ostrovsky wrote: > On 01/13/2017 01:44 PM, Stefano Stabellini wrote: >> On Fri, 13 Jan 2017, Dan Streetman wrote: >>> On Wed, Jan 11, 2017 at 6:25 PM, Dan Streetman wrote: On Wed, Jan 11, 2017 at 1:46 PM,

[Xen-devel] [PATCH] xen: do not re-use pirq number cached in pci device msi msg data

Revert the main part of commit: af42b8d12f8a ("xen: fix MSI setup and teardown for PV on HVM guests") That commit introduced reading the pci device's msi message data to see if a pirq was previously configured for the device's msi/msix, and re-use that pirq. At the time, that was the correct

Re: [Xen-devel] [PATCH] xen: do not re-use pirq number cached in pci device msi msg data

On 01/13/2017 01:44 PM, Stefano Stabellini wrote: > On Fri, 13 Jan 2017, Dan Streetman wrote: >> On Wed, Jan 11, 2017 at 6:25 PM, Dan Streetman wrote: >>> On Wed, Jan 11, 2017 at 1:46 PM, Stefano Stabellini >>> wrote: On Wed, 11 Jan 2017, Dan

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

Hi Julien, I tried markdown, but there are too many tables, they all get garbled. git diff would only show binary diffs, but libreoffice can show changes. Cheers, Stefano On Fri, 13 Jan 2017, Julien Grall wrote: > Hi, > > Sorry for the top postimg and formatting. I am sending this e-mail from

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

On 13/01/17 19:40, Marek Marczykowski-Górecki wrote: > On Fri, Jan 13, 2017 at 07:27:20PM +, Andrew Cooper wrote: >> On 13/01/17 18:59, Marek Marczykowski-Górecki wrote: >>> On Fri, Jan 13, 2017 at 06:37:06PM +, Andrew Cooper wrote: On 13/01/17 18:32, Marek Marczykowski-Górecki wrote:

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

On Fri, 13 Jan 2017, Ian Jackson wrote: > Stefano Stabellini writes ("STAO spec in xen.git"): > > I suggest we commit the STAO spec in the form of the attached ODT > > document to xen.git under docs/misc, for easier editing and consumption > > by the Xen community, and to be able to generate a

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

Hi, Sorry for the top postimg and formatting. I am sending this e-mail from my phone. We already had this discussion a couple of months ago (see [1]). We agreed on an URL but the pdfs were not uploaded. Regarding the format. Does ODT will allow git to do proper diff? If not I would prefer the

[Xen-devel] [xen-unstable baseline-only test] 68357: regressions - trouble: blocked/broken/fail/pass

This run is configured for baseline tests only. flight 68357 xen-unstable real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68357/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-xtf-amd64-amd64-33

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

On Fri, 13 Jan 2017, 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 used by > > guests,

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

On Fri, Jan 13, 2017 at 07:27:20PM +, Andrew Cooper wrote: > On 13/01/17 18:59, Marek Marczykowski-Górecki wrote: > > On Fri, Jan 13, 2017 at 06:37:06PM +, Andrew Cooper wrote: > >> On 13/01/17 18:32, Marek Marczykowski-Górecki wrote: > >>> On Fri, Jan 13, 2017 at 06:15:35PM +, Andrew

Re: [Xen-devel] [PATCH v2] x86emul: suppress memory writes after faulting FPU insns

On 13/01/17 14:32, Jan Beulich wrote: > FPU insns writing to memory must not touch memory if they latch #MF (to > be delivered on the next waiting FPU insn). Note that inspecting FSW.ES > needs to be avoided for all FNST* insns, as they don't raise exceptions > themselves, but may instead be

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

Ian Jackson writes ("Re: [OSSTEST PATCH v9 3/3] Create a flight to test OpenStack with xen-unstable and libvirt"): > Can you provide this series to me as a git branch (catch me on irc > with the url perhaps) ? I will queue it and feed it to the osstest > self-push-gate at an opportune moment.

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

On Thu, 12 Jan 2017, Andre Przywara wrote: > Hi Stefano, > > as just mentioned in my last reply, I missed that email last time. Sorry > for that. > > Replying to the comments that still apply to the new drop ... > > On 28/10/16 02:04, Stefano Stabellini wrote: > > On Wed, 28 Sep 2016, Andre

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

Stefano Stabellini writes ("STAO spec in xen.git"): > I suggest we commit the STAO spec in the form of the attached ODT > document to xen.git under docs/misc, for easier editing and consumption > by the Xen community, and to be able to generate a stable URL for it. In > fact at the moment the link

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

On 13/01/17 18:59, Marek Marczykowski-Górecki wrote: > On Fri, Jan 13, 2017 at 06:37:06PM +, Andrew Cooper wrote: >> On 13/01/17 18:32, Marek Marczykowski-Górecki wrote: >>> On Fri, Jan 13, 2017 at 06:15:35PM +, Andrew Cooper wrote: Can you get the result of this piece of debugging in

[Xen-devel] [PATCH 3/4] 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

[Xen-devel] [PATCH 1/4] 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 0/4] 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 2/4] 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

Re: [Xen-devel] [RFC PATCH v2 06/26] ARM: GICv3 ITS: introduce device mapping

On Fri, 13 Jan 2017, Andre Przywara wrote: > Hi Stefano, > > On 05/01/17 00:13, Stefano Stabellini wrote: > > On Thu, 22 Dec 2016, Andre Przywara wrote: > >> The ITS uses device IDs to map LPIs to a device. Dom0 will later use > >> those IDs, which we directly pass on to the host. > >> For this

[Xen-devel] [PATCH 4/4] 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 Signed-off-by: Doug Goldstein Reviewed-by: Doug Goldstein

[Xen-devel] XENV table in xen.git

Hi all, Similarly to STAO (http://marc.info/?l=xen-devel=148433427425627), I suggest we also commit the XENV spec in the form of the attached ODT document to xen.git under docs/misc. Cheers, Stefano xen-env-table-spec-v0.2.odt Description: application/vnd.oasis.opendocument.text

[Xen-devel] STAO spec in xen.git

Hi all, I suggest we commit the STAO spec in the form of the attached ODT document to xen.git under docs/misc, for easier editing and consumption by the Xen community, and to be able to generate a stable URL for it. In fact at the moment the link to the STAO spec from http://uefi.org/acpi is

Re: [Xen-devel] [PATCH 8/8] x86emul: rename the no_writeback label

On 13/01/17 15:35, Jan Beulich wrote: > This is to bring its name in line with what actually happens there. > > Suggested-by: Andrew Cooper > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper

Re: [Xen-devel] [PATCH 7/8] x86emul: support RDPID

On 13/01/17 15:34, Jan Beulich wrote: > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

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

On Fri, Jan 13, 2017 at 06:37:06PM +, Andrew Cooper wrote: > On 13/01/17 18:32, Marek Marczykowski-Górecki wrote: > > On Fri, Jan 13, 2017 at 06:15:35PM +, Andrew Cooper wrote: > >> Can you get the result of this piece of debugging in the failure case? > > I've got this: > > ** d4v0

Re: [Xen-devel] [PATCH 6/8] x86emul: support RDRAND/RDSEED

On 13/01/17 15:34, Jan Beulich wrote: > @@ -5737,14 +5739,82 @@ x86_emulate( > dst.val = src.val; > break; > > -case X86EMUL_OPC(0x0f, 0xc7): /* Grp9 (cmpxchg8b/cmpxchg16b) */ { > +case X86EMUL_OPC(0x0f, 0xc7): /* Grp9 */ { Style (while you are changing this).

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

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( > #define vcpu_has_cr8_legacy() vcpu_has(0x8001, ECX, 4, ctxt, ops) > #define vcpu_has_lzcnt()

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

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 72a9b186292d98494f26cfd24a1621796209 >>> Author: KarimAllah Ahmed >>> Date: Fri

Re: [Xen-devel] [PATCH] xen: do not re-use pirq number cached in pci device msi msg data

On Fri, 13 Jan 2017, Dan Streetman wrote: > On Wed, Jan 11, 2017 at 6:25 PM, Dan Streetman wrote: > > On Wed, Jan 11, 2017 at 1:46 PM, Stefano Stabellini > > wrote: > >> On Wed, 11 Jan 2017, Dan Streetman wrote: > >>> On Tue, Jan 10, 2017 at 8:25 PM,

Re: [Xen-devel] Xen ARM community call - meeting minutes and date for the next one

On Fri, 13 Jan 2017, Pooya.Keshavarzi wrote: > On 01/12/2017 07:50 PM, Stefano Stabellini wrote: > > On Thu, 12 Jan 2017, Pooya.Keshavarzi wrote: > >> > >> Firstly sorry for the late reply on this. > >> > >> Regarding the problem with swiotlb-xen here are some more details: > >> > >> If we limit

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

On 13/01/17 18:32, Marek Marczykowski-Górecki wrote: > On Fri, Jan 13, 2017 at 06:15:35PM +, Andrew Cooper wrote: >> On 13/01/17 18:03, Marek Marczykowski-Górecki wrote: >>> On Fri, Jan 13, 2017 at 05:38:42PM +, Andrew Cooper wrote: On 13/01/17 17:31, Marek Marczykowski-Górecki wrote:

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

On Fri, Jan 13, 2017 at 06:15:35PM +, Andrew Cooper wrote: > On 13/01/17 18:03, Marek Marczykowski-Górecki wrote: > > On Fri, Jan 13, 2017 at 05:38:42PM +, Andrew Cooper wrote: > >> On 13/01/17 17:31, Marek Marczykowski-Górecki wrote: > >>> Hi, > >>> > >>> I have a strange problem -

Re: [Xen-devel] [PATCH] xen: do not re-use pirq number cached in pci device msi msg data

On Wed, Jan 11, 2017 at 6:25 PM, Dan Streetman wrote: > On Wed, Jan 11, 2017 at 1:46 PM, Stefano Stabellini > wrote: >> On Wed, 11 Jan 2017, Dan Streetman wrote: >>> On Tue, Jan 10, 2017 at 8:25 PM, Stefano Stabellini >>> wrote:

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

On Fri, 13 Jan 2017, Boris Ostrovsky wrote: > On 01/12/2017 04:39 PM, Stefano Stabellini wrote: > > The following commit: > > > > commit 72a9b186292d98494f26cfd24a1621796209 > > Author: KarimAllah Ahmed > > Date: Fri Aug 26 23:55:36 2016 +0200 > > > > xen: Remove

Re: [Xen-devel] [PATCH 4/8] x86emul: support BMI2 insns

On 13/01/17 15:32, Jan Beulich wrote: > Note that the adjustment to the mode_64bit() definition is so that we > can avoid "#ifdef __x86_64__" around the 64-bit asm() portions. An > alternative would be single asm()s with a conditional branch over the > (manually encoded) REX64 prefix. This

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

On 13/01/17 18:03, Marek Marczykowski-Górecki wrote: > On Fri, Jan 13, 2017 at 05:38:42PM +, Andrew Cooper wrote: >> On 13/01/17 17:31, Marek Marczykowski-Górecki wrote: >>> Hi, >>> >>> I have a strange problem - xc_evtchn_status fails when running in HVM, >>> while exactly the same code (same

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

On Fri, Jan 13, 2017 at 05:38:42PM +, Andrew Cooper wrote: > On 13/01/17 17:31, Marek Marczykowski-Górecki wrote: > > Hi, > > > > I have a strange problem - xc_evtchn_status fails when running in HVM, > > while exactly the same code (same kernel, same application etc) works > > fine in PV.

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

On 13/01/17 15:31, Jan Beulich wrote: > --- a/xen/arch/x86/x86_emulate/x86_emulate.c > +++ b/xen/arch/x86/x86_emulate/x86_emulate.c > @@ -676,6 +676,16 @@ do{ asm volatile ( > #define __emulate_1op_8byte(_op, _dst, _eflags) > #endif /* __i386__ */ > > +#define emulate_stub(dst, src...) do {

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

On 13/01/17 17:31, Marek Marczykowski-Górecki wrote: > Hi, > > I have a strange problem - xc_evtchn_status fails when running in HVM, > while exactly the same code (same kernel, same application etc) works > fine in PV. I've narrowed it down to copy_from_guest call in > common/event_channel.c, but

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

Hi, I have a strange problem - xc_evtchn_status fails when running in HVM, while exactly the same code (same kernel, same application etc) works fine in PV. I've narrowed it down to copy_from_guest call in common/event_channel.c, but no idea why it fails there. Xen version is 4.8.0. kernel is

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

flight 104171 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/104171/ 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

Re: [Xen-devel] [PATCH v3 1/8] arm: put types.h in uapi

On Fri, Jan 13, 2017 at 11:46:39AM +0100, Nicolas Dichtel wrote: > This header file is exported, thus move it to uapi. I'm taking this patch, but with the following commit log: Due to the way kbuild works, this header was unintentionally exported back in 2013 when it was created, despite it

Re: [Xen-devel] [PATCH v3 4/8] x86: stop exporting msr-index.h to userland

On Fri, Jan 13, 2017 at 05:08:34PM +0100, Nicolas Dichtel wrote: > Le 13/01/2017 à 16:43, David Howells a écrit : > >> -header-y += msr-index.h > > > > I see it on my desktop as /usr/include/asm/msr-index.h and it's been there > > at > > least four years - and as such it's part of the UAPI. I

Re: [Xen-devel] [PATCH 2/8] x86emul: support ADCX/ADOX

On 13/01/17 15:31, Jan Beulich wrote: > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 1/8] x86emul: support POPCNT

On 13/01/17 15:30, Jan Beulich wrote: > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

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

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 tests? osstest's reports are posted to xen-devel. To give you an

Re: [Xen-devel] [PATCH v3 1/8] arm: put types.h in uapi

On Fri, Jan 13, 2017 at 05:01:01PM +0100, Nicolas Dichtel wrote: > Please, do not remove the email subject when you reply. I restore it to > ease the thread follow-up. I mentioned it to David, and he says it's because the long list of recipients is breaking his mailer. I've already posed the

Re: [Xen-devel] [PATCH v11 00/13] x86: multiboot2 protocol support

On Fri, Jan 13, 2017 at 09:45:13AM -0600, Doug Goldstein wrote: > On 1/11/17 2:46 PM, Daniel Kiper wrote: > > On Mon, Dec 05, 2016 at 11:25:05PM +0100, Daniel Kiper wrote: > >> Hi, > >> > >> I am sending eleventh version of multiboot2 protocol support for > >> legacy BIOS and EFI platforms. This

Re: [Xen-devel] [PATCH v3 4/8] x86: stop exporting msr-index.h to userland

Le 13/01/2017 à 16:43, David Howells a écrit : >> -header-y += msr-index.h > > I see it on my desktop as /usr/include/asm/msr-index.h and it's been there at > least four years - and as such it's part of the UAPI. I don't think you can > remove it unless you can guarantee there are no userspace

Re: [Xen-devel] [PATCH v3 1/8] arm: put types.h in uapi

Please, do not remove the email subject when you reply. I restore it to ease the thread follow-up. Le 13/01/2017 à 16:36, David Howells a écrit : > Nicolas Dichtel wrote: > >> This header file is exported, thus move it to uapi. > > Exported how? It is listed in

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

>>> 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 used by > guests, > and tending to use native interfaces (as used by bare

Re: [Xen-devel] [patch 1/3] KVM: x86: provide realtime host clock via vsyscall notifiers

On Fri, Jan 13, 2017 at 10:41:10AM -0500, Konrad Rzeszutek Wilk wrote: > On Fri, Jan 13, 2017 at 04:18:04PM +0100, Radim Krcmar wrote: > > 2017-01-13 10:01-0200, Marcelo Tosatti: > > > Expose the realtime host clock and save the TSC value > > > used for the clock calculation. > > > > > >

Re: [Xen-devel] [PATCH v11 00/13] x86: multiboot2 protocol support

On 1/11/17 2:46 PM, Daniel Kiper wrote: > On Mon, Dec 05, 2016 at 11:25:05PM +0100, Daniel Kiper wrote: >> Hi, >> >> I am sending eleventh version of multiboot2 protocol support for >> legacy BIOS and EFI platforms. This patch series release contains >> fixes for all known issues. >> >> The final

[Xen-devel] (no subject)

> -header-y += msr-index.h I see it on my desktop as /usr/include/asm/msr-index.h and it's been there at least four years - and as such it's part of the UAPI. I don't think you can remove it unless you can guarantee there are no userspace users. David

[Xen-devel] (no subject)

Nicolas Dichtel wrote: > This header file is exported, thus move it to uapi. Exported how? > +#ifdef __INT32_TYPE__ > +#undef __INT32_TYPE__ > +#define __INT32_TYPE__ int > +#endif > + > +#ifdef __UINT32_TYPE__ > +#undef __UINT32_TYPE__ > +#define

Re: [Xen-devel] [patch 1/3] KVM: x86: provide realtime host clock via vsyscall notifiers

On Fri, Jan 13, 2017 at 04:18:04PM +0100, Radim Krcmar wrote: > 2017-01-13 10:01-0200, Marcelo Tosatti: > > Expose the realtime host clock and save the TSC value > > used for the clock calculation. > > > > Signed-off-by: Marcelo Tosatti > > > > --- > > arch/x86/kvm/x86.c |

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

On 01/13/2017 03:31 AM, Dario Faggioli wrote: > On Thu, 2017-01-12 at 11:22 -0500, Boris Ostrovsky wrote: >> On 01/12/2017 07:50 AM, Dario Faggioli wrote: >>> I don't think we do that any longer, and that may be part of the >>> reason >>> why we missed this one? >> I believe you needed to be on a

[Xen-devel] [PATCH 8/8] x86emul: rename the no_writeback label

This is to bring its name in line with what actually happens there. Suggested-by: Andrew Cooper Signed-off-by: Jan Beulich --- a/xen/arch/x86/x86_emulate/x86_emulate.c +++ b/xen/arch/x86/x86_emulate/x86_emulate.c @@ -986,7 +986,7 @@ static inline

[Xen-devel] [PATCH 7/8] x86emul: support RDPID

Signed-off-by: Jan Beulich --- a/tools/tests/x86_emulator/test_x86_emulator.c +++ b/tools/tests/x86_emulator/test_x86_emulator.c @@ -158,6 +158,11 @@ static int read_msr( case 0xc080: /* EFER */ *val = ctxt->addr_size > 32 ? 0x500 /* LME|LMA */ : 0;

[Xen-devel] [PATCH 6/8] x86emul: support RDRAND/RDSEED

Signed-off-by: Jan Beulich --- a/xen/arch/x86/Rules.mk +++ b/xen/arch/x86/Rules.mk @@ -14,7 +14,9 @@ $(call cc-option-add,CFLAGS,CC,-Wnested- $(call as-insn-check,CFLAGS,CC,"vmcall",-DHAVE_GAS_VMX) $(call as-insn-check,CFLAGS,CC,"crc32 %eax$$(comma)%eax",-DHAVE_GAS_SSE4_2)

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

Signed-off-by: Jan Beulich --- a/tools/tests/x86_emulator/test_x86_emulator.c +++ b/tools/tests/x86_emulator/test_x86_emulator.c @@ -1244,6 +1244,234 @@ int main(int argc, char **argv) printf("okay\n"); } +printf("%-40s", "Testing bextr

[Xen-devel] [PATCH 4/8] x86emul: support BMI2 insns

Note that the adjustment to the mode_64bit() definition is so that we can avoid "#ifdef __x86_64__" around the 64-bit asm() portions. An alternative would be single asm()s with a conditional branch over the (manually encoded) REX64 prefix. Signed-off-by: Jan Beulich ---

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

Signed-off-by: Jan Beulich --- a/tools/tests/x86_emulator/test_x86_emulator.c +++ b/tools/tests/x86_emulator/test_x86_emulator.c @@ -892,6 +892,133 @@ int main(int argc, char **argv) #define check_eip(which) (regs.eip == (unsigned long)(which) + \

[Xen-devel] [PATCH 2/8] x86emul: support ADCX/ADOX

Signed-off-by: Jan Beulich --- a/tools/tests/x86_emulator/test_x86_emulator.c +++ b/tools/tests/x86_emulator/test_x86_emulator.c @@ -885,10 +885,65 @@ int main(int argc, char **argv) #which ": " insn "\n" \

[Xen-devel] [PATCH 1/8] x86emul: support POPCNT

Signed-off-by: Jan Beulich --- TBD: Alternative code needed for binutils < 2.18? --- a/tools/tests/x86_emulator/test_x86_emulator.c +++ b/tools/tests/x86_emulator/test_x86_emulator.c @@ -684,6 +684,52 @@ int main(int argc, char **argv) goto fail;

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

>>> On 12.01.17 at 20:00, wrote: > On 12/01/17 12:13, Roger Pau Monné wrote: >> ## Proposed solution using the STAO >> >> The general idea of this method is to use the STAO in order to hide the pCPUs >> from the hardware domain, and provide processor objects for vCPUs

Re: [Xen-devel] Xen ARM community call - meeting minutes and date for the next one

Dear Andrii, On 01/13/2017 11:47 AM, Andrii Anisov wrote: > > Dear Pooya, > > On our site we did not face those issues 'cause we limited dom0 memory space > to the 32-bit addressable range. Could you give it a try? Maybe there is something wrong on our side and it works for you. > BTW, it

Re: [Xen-devel] Xen ARM community call - meeting minutes and date for the next one

On 01/12/2017 07:50 PM, Stefano Stabellini wrote: > On Thu, 12 Jan 2017, Pooya.Keshavarzi wrote: >> >> Firstly sorry for the late reply on this. >> >> Regarding the problem with swiotlb-xen here are some more details: >> >> If we limit Dom0's memory such that only low-memory (up to 32-bit >>

[Xen-devel] [PATCH 0/8] x86emul: support various ISA extensions

... plus, in the final patch, some cleanup. 1: support POPCNT 2: support ADCX/ADOX 3: support BMI1 insns 4: support BMI2 insns 5: support TBM insns 6: support RDRAND 7: support RDPID 8: rename the no_writeback label Signed-off-by: Jan Beulich

[Xen-devel] [PATCH v2] x86emul: suppress memory writes after faulting FPU insns

FPU insns writing to memory must not touch memory if they latch #MF (to be delivered on the next waiting FPU insn). Note that inspecting FSW.ES needs to be avoided for all FNST* insns, as they don't raise exceptions themselves, but may instead be invoked with the bit already set. Signed-off-by:

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

>>> On 13.01.17 at 14:56, wrote: > No functional change. > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org

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

flight 104166 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/104166/ 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

Re: [Xen-devel] [PATCH v2 1/2] x86/cpuid: Drop a guests cached x86 family and model information

>>> On 13.01.17 at 14:56, wrote: > The model information isn't used at all, and the family information is only > used once. > > Make get_cpu_family() a static inline (as it is just basic calculation, and > the function call is probably more expensive than the function

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

On 01/12/2017 04:39 PM, Stefano Stabellini wrote: > The following commit: > > commit 72a9b186292d98494f26cfd24a1621796209 > Author: KarimAllah Ahmed > Date: Fri Aug 26 23:55:36 2016 +0200 > > xen: Remove event channel notification through Xen PCI platform device > >

[Xen-devel] [PATCH RESEND] tools/libxl: add support for emulated NVMe drives

Upstream QEMU supports emulation of NVM Express a.k.a. NVMe drives. This patch adds a new vdev type into libxl to allow such drives to be presented to HVM guests. Because the purpose of the new vdev is purely to configure emulation, the syntax only supports specification of whole disks. Also

Re: [Xen-devel] [PATCH] tools/libxl: add support for emulated NVMe drives

> -Original Message- > From: Paul Durrant [mailto:paul.durr...@citrix.com] > Sent: 13 January 2017 13:57 > To: xen-de...@lists.xenproject.org > Cc: Paul Durrant > Subject: [PATCH] tools/libxl: add support for emulated NVMe drives > > Upstream QEMU supports

[Xen-devel] [PATCH] tools/libxl: add support for emulated NVMe drives

Upstream QEMU supports emulation of NVM Express a.k.a. NVMe drives. This patch adds a new vdev type into libxl to allow such drives to be presented to HVM guests. Because the purpose of the new vdev is purely to configure emulation, the syntax only supports specification of whole disks. Also

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

No functional change. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Tim Deegan CC: George Dunlap CC: Paul Durrant CC: Boris Ostrovsky CC:

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

flight 104162 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/104162/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-credit2 6 xen-boot fail REGR. vs. 104157 Regressions which

[Xen-devel] [PATCH v2 1/2] x86/cpuid: Drop a guests cached x86 family and model information

The model information isn't used at all, and the family information is only used once. Make get_cpu_family() a static inline (as it is just basic calculation, and the function call is probably more expensive than the function itself) and rearange the logic to avoid calculating model entirely if

Re: [Xen-devel] [PATCH] x86emul: suppress memory writes after faulting FPU insns

>>> On 12.01.17 at 17:43, wrote: > On 12/01/17 16:12, Jan Beulich wrote: > On 12.01.17 at 16:04, wrote: >>> On 12/01/17 14:02, Jan Beulich wrote: Furthermore I think we have another issue with writes: If the write faults, the

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

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 Gross Sorry, this stands only if you do the change I

Re: [Xen-devel] [PATCH v2] kexec: implement STATUS hypercall to check if image is loaded

On Fri, Jan 13, 2017 at 06:19:28AM -0700, Jan Beulich wrote: > >>> On 13.01.17 at 13:49, wrote: > > On Fri, Jan 13, 2017 at 05:35:35AM -0700, Jan Beulich wrote: > >> >>> On 13.01.17 at 13:14, wrote: > >> > Jan, so,

[Xen-devel] all packets from HVM guests to PV guests on the same host being dropped

please forgive the cross-posting. having not had much luck on the xen-users list, and having seen similarly-complex threads on this list, i thought i'd see if anyone here had any ideas or pointers. TL;DR all packets are being dropped in a debian 7 (wheezy) guest only when they are coming from

  1   2   >