[Xen-devel] Xen release cycle revisited

Hi all, with 4.10 more or less finished it is time to plan for the next release 4.11. Since 4.7 we are using a 6 month release cycle [1] targeting to release in June and December. While this worked reasonably well for 4.7, 4.8 and 4.9 we had some difficulties with 4.10: bad luck with security

[Xen-devel] [xen-4.10-testing test] 117020: trouble: blocked/broken/pass

flight 117020 xen-4.10-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/117020/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-prev broken build-i386

Re: [Xen-devel] [PATCH] tools/livepatch: recognize functions in livepatch.ignore.functions

On 12/14/2017 07:18 AM, Elena Ufimtseva wrote: Hi Ross Thanks for the info. I actually did look into the KPATCH_IGNORE_FUNCTION code. But.. I somehow ended up having this: #define KPATCH_IGNORE_FUNCTION(_fn) \ void *__kpatch_ignore_func_##_fn __section(.kpatch.ignore.functions) = (#_fn);

Re: [Xen-devel] [PATCH] tools/livepatch: recognize functions in livepatch.ignore.functions

Hi Ross Thanks for the info. I actually did look into the KPATCH_IGNORE_FUNCTION code. But.. I somehow ended up having this: #define KPATCH_IGNORE_FUNCTION(_fn) \ void *__kpatch_ignore_func_##_fn __section(.kpatch.ignore.functions) = (#_fn); Which apparently caused the symbol not being a

[Xen-devel] [xen-4.9-testing test] 117111: trouble: blocked/broken/pass

flight 117111 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/117111/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 broken build-amd64-prev

[Xen-devel] [xen-4.6-testing test] 117116: tolerable FAIL - PUSHED

flight 117116 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/117116/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-xtf-amd64-amd64-1 49 xtf/test-hvm64-lbr-tsx-vmentry fail like 116766 test-armhf-armhf-xl-rtds 12

[Xen-devel] [linux-next test] 117110: trouble: blocked/broken/pass

flight 117110 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/117110/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 broken build-i386

[Xen-devel] [xen-unstable-smoke test] 117124: trouble: broken/pass

flight 117124 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/117124/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl-xsm broken Tests which

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

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

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

flight 117104 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/117104/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 broken build-amd64-prev

[Xen-devel] [xen-4.5-testing test] 117112: trouble: blocked/broken

flight 117112 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/117112/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 broken build-amd64-prev

Re: [Xen-devel] [PATCH] xen/efi: Fix build with clang-5.0

On Wed, 13 Dec 2017, Andrew Cooper wrote: > The clang-5.0 build is reliably failing with: > > Error: size of boot.o:.text is 0x01 > > which is because efi_arch_flush_dcache_area() exists as a single ret > instruction. Mark it as __init like everything else in the files. > > Spotted by

Re: [Xen-devel] [PATCH V3 1/2] Drivers/PCI: Export pcie_has_flr() interface

[+cc Christoph] On Wed, Dec 13, 2017 at 02:46:57PM -0600, Govinda Tatti wrote: > > -static bool pcie_has_flr(struct pci_dev *dev) > +bool pcie_has_flr(struct pci_dev *dev) > { > u32 cap; > @@ -3882,6 +3882,7 @@ static bool pcie_has_flr(struct pci_dev *dev) >

Re: [Xen-devel] [PATCH V3 1/2] Drivers/PCI: Export pcie_has_flr() interface

-static bool pcie_has_flr(struct pci_dev *dev) +bool pcie_has_flr(struct pci_dev *dev) { u32 cap; @@ -3882,6 +3882,7 @@ static bool pcie_has_flr(struct pci_dev *dev) pcie_capability_read_dword(dev, PCI_EXP_DEVCAP, ); return cap & PCI_EXP_DEVCAP_FLR; }

[Xen-devel] [linux-4.1 test] 117088: trouble: blocked/broken/fail/pass

flight 117088 linux-4.1 real [real] http://logs.test-lab.xenproject.org/osstest/logs/117088/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 broken build-i386

[Xen-devel] [xen-4.7-testing test] 117100: trouble: blocked/broken/pass

flight 117100 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/117100/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 broken build-amd64-prev

Re: [Xen-devel] [RFC Patch v4 2/8] ioreq: bump the number of IOREQ page to 4 pages

> -Original Message- > From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf > Of Paul Durrant > Sent: 13 December 2017 10:49 > To: 'Chao Gao' > Cc: Stefano Stabellini ; Wei Liu > ; Andrew Cooper

Re: [Xen-devel] [PATCH v14 07/11] x86/mm: add an extra command to HYPERVISOR_mmu_update...

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 13 December 2017 15:25 > To: Paul Durrant > Cc: Andrew Cooper ; George Dunlap > ; Ian Jackson ; Wei Liu >

[Xen-devel] altp2m: set_mem_access with change_gfn in domU

Hello, I'm using altp2m from a guest, using Xen 4.9.1 and setting altp2m = 'mixed' in my VM config file. I'm confused about the expected behavior when combining HVMOP_altp2m_change_gfn and  HVMOP_altp2m_set_mem_access. In my case, I am "changing" one GFN to another (I'm thinking of this as GFN

[Xen-devel] [OSSTEST PATCH] crontab: Fix recipient of cron mails

Signed-off-by: Ian Jackson --- crontab | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/crontab b/crontab index b710355..3c8c8cc 100755 --- a/crontab +++ b/crontab @@ -2,7 +2,7 @@ #@@ osst...@osstest.test-lab.xenproject.org

[Xen-devel] [PATCH] xen/efi: Fix build with clang-5.0

The clang-5.0 build is reliably failing with: Error: size of boot.o:.text is 0x01 which is because efi_arch_flush_dcache_area() exists as a single ret instruction. Mark it as __init like everything else in the files. Spotted by Travis. Signed-off-by: Andrew Cooper

Re: [Xen-devel] [PATCH v6 1/4] hw: convert virtio-input-hid device to keycodemapdb

On Tue, Dec 12, 2017 at 02:10:41PM +, Daniel P. Berrange wrote: > diff --git a/Makefile b/Makefile > index ab0354c153..5aaff5fe1e 100644 > --- a/Makefile > +++ b/Makefile > @@ -227,6 +227,7 @@ KEYCODEMAP_CSV = > $(SRC_PATH)/ui/keycodemapdb/data/keymaps.csv > > KEYCODEMAP_FILES = \ >

Re: [Xen-devel] [PATCH v6 4/4] hw: convert XenInput keyboard to keycodemapdb

On Tue, Dec 12, 2017 at 02:10:44PM +, Daniel P. Berrange wrote: > Replace the scancode2linux table with an automatically > generated table. In doing so, the XenFB keyboard > handler is also converted to the modern InputEvent > framework. > > Signed-off-by: Daniel P. Berrange

Re: [Xen-devel] [PATCH] docs/process/xen-release-management: Lesson to learn

On Wed, Dec 13, 2017 at 12:02 PM, Ian Jackson wrote: > The 4.10 release preparation was significantly more hairy than ideal. > (We seem to have a good overall outcome despite, rather than because > of, our approach.) > > This is the second time (at least) that we have

Re: [Xen-devel] [PATCH v14 07/11] x86/mm: add an extra command to HYPERVISOR_mmu_update...

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 13 December 2017 14:36 > To: Paul Durrant > Cc: Andrew Cooper ; George Dunlap > ; Ian Jackson ; Wei Liu >

Re: [Xen-devel] [PATCH v14 07/11] x86/mm: add an extra command to HYPERVISOR_mmu_update...

>>> On 13.12.17 at 13:06, wrote: >> From: Jan Beulich [mailto:jbeul...@suse.com] >> Sent: 12 December 2017 14:39 >> >>> On 12.12.17 at 14:52, wrote: >> > We are deliberately trying to introducing a mechanism whereby a >> >

Re: [Xen-devel] [PATCH] x86/microcode: Add support for fam17h microcode loading

>>> On 13.12.17 at 14:27, wrote: > From: Tom Lendacky > > The size for the Microcode Patch Block (MPB) for an AMD family 17h > processor is 3200 bytes. Add a #define for fam17h so that it does > not default to 2048 bytes and fail a microcode

[Xen-devel] [PATCH v10] x86/altp2m: support for setting restrictions for an array of pages

From: Razvan Cojocaru For the default EPT view we have xc_set_mem_access_multi(), which is able to set an array of pages to an array of access rights with a single hypercall. However, this functionality was lacking for the altp2m subsystem, which could only set page

Re: [Xen-devel] [PATCH 4/6] x86/shadow: widen reference count

>>> On 13.12.17 at 11:32, wrote: > On 12/13/2017 09:17 AM, Jan Beulich wrote: > On 12.12.17 at 17:32, wrote: @@ -82,7 +153,7 @@ struct page_info unsigned long type:5; /* What kind of shadow is this? */

Re: [Xen-devel] [PATCH V1 1/1] Xen/libxl: Perform PCI reset using 'reset' SysFS attribute

On Thu, Dec 7, 2017 at 10:26 PM, Govinda Tatti wrote: > The life-cycle of a PCI device in Xen pciback is complex and is constrained > by the generic PCI locking mechanism. > > - It starts with the device being bound to us, for which we do a function > reset (done via

Re: [Xen-devel] [PATCH] docs/process/xen-release-management: Lesson to learn

Julien Grall writes ("Re: [Xen-devel] [PATCH] docs/process/xen-release-management: Lesson to learn"): > That's why testing with XSAs was requested on the security-ml before > hand. However, this was mistakenly done on rc7 rather than rc8. If the proposed release had been constructed in advance,

[Xen-devel] [PATCH] x86/microcode: Add support for fam17h microcode loading

From: Tom Lendacky The size for the Microcode Patch Block (MPB) for an AMD family 17h processor is 3200 bytes. Add a #define for fam17h so that it does not default to 2048 bytes and fail a microcode load/update. Signed-off-by: Tom Lendacky

[Xen-devel] [linux-3.18 test] 117087: trouble: blocked/broken/pass

flight 117087 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/117087/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 broken build-i386

Re: [Xen-devel] [PATCH] docs/process/xen-release-management: Lesson to learn

Hi Ian, On 13/12/17 12:02, Ian Jackson wrote: The 4.10 release preparation was significantly more hairy than ideal. (We seem to have a good overall outcome despite, rather than because of, our approach.) This is the second time (at least) that we have come close to failure by committing to a

Re: [Xen-devel] [PATCH] docs/process/xen-release-management: Lesson to learn

On 13/12/17 12:02, Ian Jackson wrote: > The 4.10 release preparation was significantly more hairy than ideal. > (We seem to have a good overall outcome despite, rather than because > of, our approach.) > > This is the second time (at least) that we have come close to failure > by committing to a

Re: [Xen-devel] [PATCH] docs/process/release-checklist.txt: Say to push staging branch

On 12/13/2017 12:17 PM, Ian Jackson wrote: > Preparing a real release, not just an RC, involves making commits. > Typically, those will be on staging-$x. The tag will refer to them, > and the checklist already says to push them to xenbits. > > But if the *branch* is not pushed, then people who

[Xen-devel] [PATCH] docs/process/release-checklist.txt: Say to push staging branch

Preparing a real release, not just an RC, involves making commits. Typically, those will be on staging-$x. The tag will refer to them, and the checklist already says to push them to xenbits. But if the *branch* is not pushed, then people who just "git fetch" won't get the tag because it refers

Re: [Xen-devel] [PATCH v14 07/11] x86/mm: add an extra command to HYPERVISOR_mmu_update...

-Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 12 December 2017 14:39 > To: Andrew Cooper > Cc: Paul Durrant ; Wei Liu ; > George Dunlap ; Ian Jackson >

Re: [Xen-devel] [PATCH] docs/process/xen-release-management: Lesson to learn

On 13/12/17 13:02, Ian Jackson wrote: > The 4.10 release preparation was significantly more hairy than ideal. > (We seem to have a good overall outcome despite, rather than because > of, our approach.) > > This is the second time (at least) that we have come close to failure > by committing to a

[Xen-devel] [PATCH] docs/process/xen-release-management: Lesson to learn

The 4.10 release preparation was significantly more hairy than ideal. (We seem to have a good overall outcome despite, rather than because of, our approach.) This is the second time (at least) that we have come close to failure by committing to a release date before the exact code to be released

Re: [Xen-devel] [PATCH v9] x86/altp2m: support for setting restrictions for an array of pages

>>> On 13.12.17 at 12:02, wrote: > If we accept this case as valid, although highly unlikely, (opaque == > nr and not 0), calling p2m_set_mem_access_multi will do nothing except > locking/unlocking p2m (case in which the performance penalty will be > significantly

[Xen-devel] [xen-4.6-testing test] 117099: trouble: blocked/broken

flight 117099 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/117099/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 broken build-amd64-prev

[Xen-devel] [distros-debian-squeeze test] 72730: trouble: blocked/broken

flight 72730 distros-debian-squeeze real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/72730/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-pvopsbroken

[Xen-devel] [PATCH v2 2/2] x86/vmx: Drop enum handler_return

They are straight aliases of the more common X86EMUL_* constants. While adjusting these, fix the case indentation where appropriate. No functional change, confirmed by diff'ing the compiled binary. Signed-off-by: Andrew Cooper Acked-by: Kevin Tian

[Xen-devel] [PATCH v2 1/2] x86/vmx: Don't use hvm_inject_hw_exception() in long_mode_do_msr_write()

Since c/s 49de10f3c1718 "x86/hvm: Don't raise #GP behind the emulators back for MSR accesses", returning X86EMUL_EXCEPTION has pushed the exception generation to the top of the call tree. Using hvm_inject_hw_exception() and returning X86EMUL_EXCEPTION causes a double #GP injection, which combines

Re: [Xen-devel] [RFC Patch v4 2/8] ioreq: bump the number of IOREQ page to 4 pages

> -Original Message- > From: Chao Gao [mailto:chao@intel.com] > Sent: 12 December 2017 23:39 > To: Paul Durrant > Cc: Stefano Stabellini ; Wei Liu > ; Andrew Cooper ; Tim > (Xen.org)

[Xen-devel] [PATCH] x86/efer: Make {read, write}_efer() into inline helpers

There is no need for the overhead of a call to a separate translation unit. While moving the implementation, update them to use uint64_t over u64 Signed-off-by: Andrew Cooper --- CC: Jan Beulich --- xen/arch/x86/traps.c | 13 +

Re: [Xen-devel] [PATCH 4/6] x86/shadow: widen reference count

On 12/13/2017 09:17 AM, Jan Beulich wrote: On 12.12.17 at 17:32, wrote: >>> @@ -82,7 +153,7 @@ struct page_info >>> unsigned long type:5; /* What kind of shadow is this? */ >>> unsigned long pinned:1; /* Is the shadow pinned? */ >>>

[Xen-devel] [xen-4.5-testing test] 117108: trouble: blocked/broken

flight 117108 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/117108/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 broken build-amd64-prev

[Xen-devel] [xen-4.9-testing test] 117096: trouble: blocked/broken/pass

flight 117096 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/117096/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 broken build-amd64-prev

Re: [Xen-devel] [PATCH v9] x86/altp2m: support for setting restrictions for an array of pages

>>> On 13.12.17 at 08:12, wrote: > @@ -4619,6 +4623,38 @@ static int do_altp2m_op( > a.u.set_mem_access.view); > break; > > +case HVMOP_altp2m_set_mem_access_multi: > +if ( a.u.set_mem_access_multi.pad || > +

Re: [Xen-devel] [PATCH 2/2] x86/vmx: Drop enum handler_return

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Thursday, December 7, 2017 4:06 AM > > They are straight aliases of the more common X86EMUL_* constants. > While > adjusting these, fix the case indentation where appropriate. > > No functional change, confirmed by diff'ing the

Re: [Xen-devel] [PATCH 1/2] x86/vmx: Don't use hvm_inject_hw_exception() in long_mode_do_msr_write()

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Thursday, December 7, 2017 4:06 AM > > Since c/s 49de10f3c1718 "x86/hvm: Don't raise #GP behind the emulators > back > for MSR accesses", returnning X86EMUL_EXCEPTION has pushed the > exception > generation to the top of the call

Re: [Xen-devel] [PATCH] VMX: drop bogus gpa parameter from __invept()

> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Thursday, December 7, 2017 12:29 AM > > Perhaps there once was a plan to have a flush type requiring this, but > the current SDM has no mention of such and all callers pass zero anyway. > > Take the opportunity and also change involved types