[Xen-devel] [linux-next test] 104340: tolerable FAIL

flight 104340 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/104340/ Failures :-/ but no regressions. Tests which did not succeed, including tests which could not be run: test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a

[Xen-devel] [linux-4.1 baseline-only test] 68405: trouble: blocked/broken

This run is configured for baseline tests only. flight 68405 linux-4.1 real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68405/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf

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

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

[Xen-devel] [xen-4.7-testing test] 104405: regressions - FAIL

flight 104405 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/104405/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 5 xen-buildfail REGR. vs. 104275 build-i386-xsm

[Xen-devel] [xen-4.5-testing test] 104391: regressions - FAIL

flight 104391 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/104391/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 5 xen-buildfail REGR. vs. 103805 build-armhf

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

flight 104326 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/104326/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl 6 xen-boot fail REGR. vs. 59254

[Xen-devel] [xen-4.6-testing test] 104387: regressions - FAIL

flight 104387 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/104387/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 5 xen-buildfail REGR. vs. 104308 build-amd64

[Xen-devel] [xen-4.6-testing bisection] complete build-amd64-xsm

branch xen-4.6-testing xenbranch xen-4.6-testing job build-amd64-xsm testid xen-build Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree:

[Xen-devel] [xen-4.7-testing test] 104370: regressions - FAIL

flight 104370 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/104370/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 5 xen-buildfail REGR. vs. 104275 build-i386-xsm

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

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

[Xen-devel] [xen-4.5-testing test] 104368: regressions - FAIL

flight 104368 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/104368/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 5 xen-buildfail REGR. vs. 103805 build-armhf

[Xen-devel] [linux-linus bisection] complete test-amd64-i386-xl-qemuu-win7-amd64

branch xen-unstable xenbranch xen-unstable job test-amd64-i386-xl-qemuu-win7-amd64 testid xen-boot Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu

[Xen-devel] [xen-4.6-testing test] 104364: regressions - FAIL

flight 104364 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/104364/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 5 xen-buildfail REGR. vs. 104308 build-amd64

[Xen-devel] [ovmf baseline-only test] 68407: tolerable trouble: blocked/broken

This run is configured for baseline tests only. flight 68407 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68407/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): build-i3863 host-install(3) broken

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

flight 104324 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/104324/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemuu-rhel6hvm-intel 6 xen-boot fail REGR. vs. 104223

[Xen-devel] [PATCH] x86/hvm: do not set msr_tsc_adjust on hvm_set_guest_tsc_fixed

Commit 6e03363 ("x86: Implement TSC adjust feature for HVM guest") implemented TSC_ADJUST MSR for hvm guests. Though while booting an HVM guest the boot CPU would have a value set with delta_tsc - guest tsc while secondary CPUS would have 0. For example one can observe: $ xen-hvmctx 17 | grep

Re: [Xen-devel] [PATCH] docs: clarify xl mem-max semantics

On 01/20/2017 02:54 AM, Juergen Gross wrote: The information given in the xl man page for the mem-max command is rather brief. Expand it in order to let the reader understand what it is really doing. As the related libxl function libxl_domain_setmaxmem() isn't much clearer add a comment to it

Re: [Xen-devel] [PATCH v1 2/2] xen/kbdif: add multi-touch support

On Fri, 20 Jan 2017, Oleksandr Andrushchenko wrote: > On 01/20/2017 07:52 PM, Stefano Stabellini wrote: > > On Fri, 20 Jan 2017, Oleksandr Andrushchenko wrote: > > > On 01/20/2017 12:22 AM, Stefano Stabellini wrote: > > > > On Thu, 19 Jan 2017, Oleksandr Andrushchenko wrote: > > > > > From:

Re: [Xen-devel] [RFC PATCH v2 07/26] ARM: GICv3 ITS: introduce host LPI array

On Fri, 20 Jan 2017, Julien Grall wrote: > Hi Stefano, > > Sorry for the late answer, still going through my e-mail backlog. > > On 06/01/2017 21:20, Stefano Stabellini wrote: > > On Fri, 6 Jan 2017, Andre Przywara wrote: > > > > It is also possible to end up calling mapti with an inexistent

Re: [Xen-devel] [RFC] Device memory mappings for Dom0 on ARM64 ACPI systems

On Fri, 20 Jan 2017, Roger Pau Monné wrote: > > > > So you need DOM0 to tell the list of regions. > > > > > > Yes, I agree that we need such hypercall ATM, although I think that we > > > might be > > > able to get rid of it in the long term if we are able to parse the AML > > > tables > > >

[Xen-devel] [ovmf baseline-only test] 68404: tolerable trouble: blocked/broken

This run is configured for baseline tests only. flight 68404 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68404/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): build-i3863 host-install(3) broken

[Xen-devel] [xen-4.7-testing test] 104360: regressions - FAIL

flight 104360 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/104360/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 5 xen-buildfail REGR. vs. 104275 build-i386-xsm

Re: [Xen-devel] [PATCH v12 00/10] x86: multiboot2 protocol support

On Fri, Jan 20, 2017 at 02:42:30PM -0500, Doug Goldstein wrote: > On 1/19/17 8:34 PM, Daniel Kiper wrote: > > Hi, > > > > I am sending twelfth version of multiboot2 protocol support for > > legacy BIOS and EFI platforms. This patch series release contains > > fixes for all known/confirmed issues.

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

On Fri, Jan 20, 2017 at 02:34:35PM -0500, Doug Goldstein wrote: > On 1/19/17 8:34 PM, Daniel Kiper wrote: > > diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h > > index 62c010e..c1285ad 100644 > > --- a/xen/arch/x86/efi/efi-boot.h > > +++ b/xen/arch/x86/efi/efi-boot.h > > > +

[Xen-devel] [xen-4.5-testing test] 104355: regressions - FAIL

flight 104355 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/104355/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i3865 xen-buildfail REGR. vs. 103805 build-amd64

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

flight 104308 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/104308/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail in 104278 pass in

Re: [Xen-devel] [PATCH v12 00/10] x86: multiboot2 protocol support

On Fri, Jan 20, 2017 at 02:42:30PM -0500, Doug Goldstein wrote: > On 1/19/17 8:34 PM, Daniel Kiper wrote: > > Hi, > > > > I am sending twelfth version of multiboot2 protocol support for > > legacy BIOS and EFI platforms. This patch series release contains > > fixes for all known/confirmed issues.

Re: [Xen-devel] xennet_start_xmit assumptions

On (01/20/17 14:30), David Miller wrote: > > CAP_SYS_RAWIO or not, the contract we have with the device is that > there will be at least enough bytes to cover a link layer header. I see. If that's the case (for all the kernel-driver interfaces), then the xen_netfront driver is probably not

Re: [Xen-devel] [DOC v7] PV Calls protocol design

On Tue, Jan 10, 2017 at 04:13:26PM -0800, Stefano Stabellini wrote: > Upon request from Konrad, I am attaching the output of pahole on the C > structs defined by PVCalls. As you can see, alignments and sizes of all Thank you! > fields are the same, except for the padding at the end of many

Re: [Xen-devel] [PATCH v12 00/10] x86: multiboot2 protocol support

On 1/20/17 2:42 PM, Doug Goldstein wrote: > Effectively the fix to efi_multiboot2() gets us back to the same level > of hardware support that v11 + my v5 was at for 1-5. So I will extend my: > > Reviewed-by: Doug Goldstein > Tested-by: Doug Goldstein > >

Re: [Xen-devel] [PATCH v5 5/9] x86/hvm: add vcpu parameter to guest memory copy function

On 19/01/17 17:29, Roger Pau Monne wrote: > @@ -3172,9 +3173,9 @@ static enum hvm_copy_result __hvm_copy( > { > static unsigned long lastpage; > if ( xchg(, gfn) != gfn ) > -gdprintk(XENLOG_DEBUG, "guest attempted write to >

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

flight 104357 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/104357/ 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 v12 00/10] x86: multiboot2 protocol support

On 1/19/17 8:34 PM, Daniel Kiper wrote: > Hi, > > I am sending twelfth version of multiboot2 protocol support for > legacy BIOS and EFI platforms. This patch series release contains > fixes for all known/confirmed issues. With my fix to efi_multiboot2() in 5/10 and the entire series applied, I

Re: [Xen-devel] [PATCH v5 4/9] xen/x86: populate PVHv2 Dom0 physical memory map

On 19/01/17 17:29, Roger Pau Monne wrote: > +static int __init pvh_setup_vmx_realmode_helpers(struct domain *d) > +{ > +p2m_type_t p2mt; > +uint32_t rc, *ident_pt; > +uint8_t *tss; > +mfn_t mfn; > +paddr_t gaddr; > +unsigned int i; > + > +/* > + * Steal some space

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

On 1/19/17 8:34 PM, Daniel Kiper wrote: > diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h > index 62c010e..c1285ad 100644 > --- a/xen/arch/x86/efi/efi-boot.h > +++ b/xen/arch/x86/efi/efi-boot.h > + > +efi_exit_boot(ImageHandle, SystemTable); > + > +/* Return

Re: [Xen-devel] xennet_start_xmit assumptions

From: Sowmini Varadhan Date: Thu, 19 Jan 2017 17:41:23 -0500 > On (01/19/17 13:47), Sowmini Varadhan wrote: >> > Specifically I'm talking about the dev_validate_header() check. >> > That is supposed to protect us from these kinds of situations. >> >> ah, but I run

Re: [Xen-devel] [PATCH v12 00/10] x86: multiboot2 protocol support

On 1/20/17 12:21 PM, Daniel Kiper wrote: > On Fri, Jan 20, 2017 at 11:22:21AM -0500, Doug Goldstein wrote: >> On 1/19/17 8:34 PM, Daniel Kiper wrote: >>> Hi, >>> >>> I am sending twelfth version of multiboot2 protocol support for >>> legacy BIOS and EFI platforms. This patch series release

Re: [Xen-devel] [PATCH v5 3/9] xen/x86: split Dom0 build into PV and PVHv2

On 20/01/17 19:13, Boris Ostrovsky wrote: >> diff --git a/xen/arch/x86/domain_build.c b/xen/arch/x86/domain_build.c >> index 243df96..4d555b1 100644 >> --- a/xen/arch/x86/domain_build.c >> +++ b/xen/arch/x86/domain_build.c >> @@ -191,11 +191,40 @@ struct vcpu *__init alloc_dom0_vcpu0(struct domain

Re: [Xen-devel] Possible improvement to Xen Security Response Process

James Bulpin writes ("Re: [Xen-devel] Possible improvement to Xen Security Response Process"): > On Tue, 2016-12-13 at 08:42, Jan Beulich wrote: >> On 12.12.16 at 18:11, wrote: > > > > Hmm - this means 6 weeks of latency in the worst case. I don't > > think that's

[Xen-devel] [distros-debian-jessie test] 68402: trouble: blocked/broken

flight 68402 distros-debian-jessie real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68402/ 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

Re: [Xen-devel] [PATCH v5 3/9] xen/x86: split Dom0 build into PV and PVHv2

> diff --git a/xen/arch/x86/domain_build.c b/xen/arch/x86/domain_build.c > index 243df96..4d555b1 100644 > --- a/xen/arch/x86/domain_build.c > +++ b/xen/arch/x86/domain_build.c > @@ -191,11 +191,40 @@ struct vcpu *__init alloc_dom0_vcpu0(struct domain > *dom0) > } > > #ifdef

Re: [Xen-devel] RFC: Adding a section to the Xen security policy about what constitutes a vulnerability

George Dunlap writes ("[Xen-devel] RFC: Adding a section to the Xen security policy about what constitutes a vulnerability"): > If a bug requires a vulnerable operating system to be exploitable, the > Xen Security Team will pro-actively investigate the vulnerability of > the following open-source

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

On 20/01/17 19:04, Doug Goldstein wrote: > On 1/19/17 8:34 PM, Daniel Kiper wrote: >> This way Xen can be loaded on EFI platforms using GRUB2 and >> other boot loaders which support multiboot2 protocol. >> >> Signed-off-by: Daniel Kiper >> --- >> v12 - suggestions/fixes:

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

On 1/19/17 8:34 PM, Daniel Kiper wrote: > This way Xen can be loaded on EFI platforms using GRUB2 and > other boot loaders which support multiboot2 protocol. > > Signed-off-by: Daniel Kiper > --- > v12 - suggestions/fixes: > - rename __efi64_start to

Re: [Xen-devel] [PATCH v5 3/9] xen/x86: split Dom0 build into PV and PVHv2

On 19/01/17 17:29, Roger Pau Monne wrote: > diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c > index 0ccef1d..f52f269 100644 > --- a/xen/arch/x86/setup.c > +++ b/xen/arch/x86/setup.c > @@ -1545,6 +1545,15 @@ void __init noreturn __start_xen(unsigned long mbi_p) > if ( opt_dom0pvh ) >

Re: [Xen-devel] [PATCH v12 02/10] x86: add multiboot2 protocol support

On 1/19/17 8:34 PM, Daniel Kiper wrote: > 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

Re: [Xen-devel] [PATCH v12 00/10] x86: multiboot2 protocol support

On 1/20/17 12:21 PM, Daniel Kiper wrote: > On Fri, Jan 20, 2017 at 11:22:21AM -0500, Doug Goldstein wrote: >> On 1/19/17 8:34 PM, Daniel Kiper wrote: >>> Hi, >>> >>> I am sending twelfth version of multiboot2 protocol support for >>> legacy BIOS and EFI platforms. This patch series release

Re: [Xen-devel] [PATCH v1 2/2] xen/kbdif: add multi-touch support

On 01/20/2017 07:52 PM, Stefano Stabellini wrote: On Fri, 20 Jan 2017, Oleksandr Andrushchenko wrote: On 01/20/2017 12:22 AM, Stefano Stabellini wrote: On Thu, 19 Jan 2017, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko Signed-off-by:

Re: [Xen-devel] [PATCH v5 2/9] x86/iommu: add IOMMU entries for p2m_mmio_direct pages

On 19/01/17 17:29, Roger Pau Monne wrote: > There's nothing wrong with allowing the domain to perform DMA transfers to > MMIO areas that it already can access from the CPU, and this allows us to > remove the hack in set_identity_p2m_entry for PVH Dom0. > > Signed-off-by: Roger Pau Monné

Re: [Xen-devel] [PATCH v5 1/9] xen/x86: remove XENFEAT_hvm_pirqs for PVHv2 guests

On 19/01/17 17:29, Roger Pau Monne wrote: > @@ -3768,7 +3770,9 @@ static long hvm_physdev_op(int cmd, > XEN_GUEST_HANDLE_PARAM(void) arg) > case PHYSDEVOP_eoi: > case PHYSDEVOP_irq_status_query: > case PHYSDEVOP_get_free_pirq: > -return do_physdev_op(cmd, arg); > +

[Xen-devel] [xen-4.7-testing test] 104303: regressions - FAIL

flight 104303 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/104303/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-qemuu-nested-intel 12 xen-install/l1fail REGR. vs. 104275

Re: [Xen-devel] [PATCH v4 7/8] dm_op: convert HVMOP_inject_trap and HVMOP_inject_msi

On 17/01/17 17:29, Paul Durrant wrote: > diff --git a/xen/include/public/hvm/dm_op.h b/xen/include/public/hvm/dm_op.h > index 8e9bef1..abe8bbe 100644 > --- a/xen/include/public/hvm/dm_op.h > +++ b/xen/include/public/hvm/dm_op.h > @@ -273,6 +273,52 @@ struct xen_dm_op_set_mem_type { >

Re: [Xen-devel] [PATCH v4 6/8] dm_op: convert HVMOP_set_mem_type

On 17/01/17 17:29, Paul Durrant wrote: > diff --git a/xen/arch/x86/hvm/dm.c b/xen/arch/x86/hvm/dm.c > index dd81116..b3c91f8 100644 > --- a/xen/arch/x86/hvm/dm.c > +++ b/xen/arch/x86/hvm/dm.c > @@ -159,6 +159,82 @@ static int modified_memory(struct domain *d, xen_pfn_t > *first_pfn, > return

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

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

Re: [Xen-devel] [PATCH v4 5/8] dm_op: convert HVMOP_modified_memory

On 17/01/17 17:29, Paul Durrant wrote: > diff --git a/xen/arch/x86/hvm/dm.c b/xen/arch/x86/hvm/dm.c > index 12a82e5..dd81116 100644 > --- a/xen/arch/x86/hvm/dm.c > +++ b/xen/arch/x86/hvm/dm.c > @@ -14,6 +14,7 @@ > * this program; If not, see . > */ > > +#include

Re: [Xen-devel] [RFC PATCH v2 03/26] ARM: GICv3 ITS: allocate device and collection table

Hi Andre, On 20/01/2017 17:05, Andre Przywara wrote: On 20/01/17 12:18, Julien Grall wrote: Hi Andre, On 20/01/2017 12:27, Andre Przywara wrote: On 20/01/17 11:12, Julien Grall wrote: Hello, On 04/01/2017 22:47, Stefano Stabellini wrote: On Thu, 22 Dec 2016, Andre Przywara wrote: Each

Re: [Xen-devel] [PATCH v12 02/10] x86: add multiboot2 protocol support

On 20/01/17 17:24, Daniel Kiper wrote: > On Fri, Jan 20, 2017 at 04:52:30PM +, Andrew Cooper wrote: >> >> here please? > Will do. > >> With this, Reviewed-by: Andrew Cooper > Thanks! > >> With this patch present, should legacy booting with MB2 work properly? >> If

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

On Fri, Jan 20, 2017 at 05:51:53PM +, Paul Durrant wrote: > ...as a set of hypercalls to be used by a device model. > > As stated in the new docs/designs/dm_op.markdown: > > "The aim of DMOP is to prevent a compromised device model from > compromising domains other then the one it is

[Xen-devel] [PATCH v5 2/8] dm_op: convert HVMOP_*ioreq_server*

The definitions of HVM_IOREQSRV_BUFIOREQ_* have to persist as they are already in use by callers of the libxc interface. Suggested-by: Jan Beulich Signed-off-by: Paul Durrant Reviewed-by: Jan Beulich Acked-by: Wei Liu

Re: [Xen-devel] [PATCH v1 2/2] xen/kbdif: add multi-touch support

On Fri, 20 Jan 2017, Oleksandr Andrushchenko wrote: > On 01/20/2017 12:22 AM, Stefano Stabellini wrote: > > On Thu, 19 Jan 2017, Oleksandr Andrushchenko wrote: > > > From: Oleksandr Andrushchenko > > > > > > Signed-off-by: Oleksandr Andrushchenko

[Xen-devel] [PATCH v5 6/8] dm_op: convert HVMOP_set_mem_type

This patch removes the need for handling HVMOP restarts, so that infrastructure is removed. NOTE: This patch also modifies the type of the 'nr' argument of xc_hvm_set_mem_type() from uint64_t to uint32_t. In practice the value passed was always truncated to 32 bits. Suggested-by: Jan

[Xen-devel] [PATCH v5 4/8] dm_op: convert HVMOP_set_pci_intx_level, HVMOP_set_isa_irq_level, and...

... HVMOP_set_pci_link_route These HVMOPs were exposed to guests so their definitions need to be preserved for compatibility. This patch therefore updates __XEN_LATEST_INTERFACE_VERSION__ to 0x00040900 and makes the HVMOP defintions conditional on __XEN_INTERFACE_VERSION__ less than that value.

[Xen-devel] [PATCH v5 7/8] dm_op: convert HVMOP_inject_trap and HVMOP_inject_msi

NOTE: This patch also modifies the types of the 'vector', 'type' and 'insn_len' arguments of xc_hvm_inject_trap() from uint32_t to uint8_t. In practice the values passed were always truncated to 8 bits. Suggested-by: Jan Beulich Signed-off-by: Paul Durrant

[Xen-devel] [PATCH v5 8/8] x86/hvm: serialize trap injecting producer and consumer

Since injection works on a remote vCPU, and since there's no enforcement of the subject vCPU being paused, there's a potential race between the producing and consuming sides. Fix this by leveraging the vector field as synchronization variable. Signed-off-by: Jan Beulich

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

...as a set of hypercalls to be used by a device model. As stated in the new docs/designs/dm_op.markdown: "The aim of DMOP is to prevent a compromised device model from compromising domains other then the one it is associated with. (And is therefore likely already compromised)." See that file

[Xen-devel] [PATCH v5 5/8] dm_op: convert HVMOP_modified_memory

This patch introduces code to handle DMOP continuations. NOTE: This patch also modifies the type of the 'nr' argument of xc_hvm_modified_memory() from uint64_t to uint32_t. In practice the value passed was always truncated to 32 bits. Suggested-by: Jan Beulich

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

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 uint32_t. In practice the value passed was always

[Xen-devel] [PATCH v5 0/8] New hypercall for device models

Following on from the design submitted by Jennifer Herbert to the list [1] this series provides an implementation of __HYPERCALL_dm_op followed by patches based on Jan Beulich's previous HVMCTL series [2] to convert tools-only HVMOPs used by device models to DMOPs. [1]

Re: [Xen-devel] [PATCH v1 1/2] xen/kbdif: update protocol documentation

On Fri, 20 Jan 2017, Oleksandr Andrushchenko wrote: > On 01/19/2017 08:56 PM, Stefano Stabellini wrote: > > On Thu, 19 Jan 2017, Oleksandr Andrushchenko wrote: > > > From: Oleksandr Andrushchenko > > > > > > Signed-off-by: Oleksandr Andrushchenko

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

flight 104352 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/104352/ 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] [linux-4.1 test] 104301: tolerable trouble: broken/fail/pass - PUSHED

flight 104301 linux-4.1 real [real] http://logs.test-lab.xenproject.org/osstest/logs/104301/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qcow2 16 guest-localmigrate/x10 fail in 104272 pass in 104301

[Xen-devel] [offlist] Re: [PATCH v4 4/8] dm_op: convert HVMOP_set_pci_intx_level, HVMOP_set_isa_irq_level, and...

On 17/01/17 17:29, Paul Durrant wrote: > ... HVMOP_set_pci_link_route > > These HVMOPs were exposed to guests so their definitions need to be > preserved for compatibility. This patch therefore updates > __XEN_LATEST_INTERFACE_VERSION__ to 0x00040900 and makes the HVMOP > defintions conditional on

Re: [Xen-devel] [PATCH v12 02/10] x86: add multiboot2 protocol support

On Fri, Jan 20, 2017 at 04:52:30PM +, Andrew Cooper wrote: > On 20/01/17 01:34, Daniel Kiper wrote: > > @@ -101,3 +112,126 @@ multiboot_info_t __stdcall *reloc(u32 mbi_in, u32 > > trampoline) > > > > return mbi_out; > > } > > + > > +static multiboot_info_t *mbi2_reloc(u32 mbi_in) > > +{

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

On 17/01/17 17:29, 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 uint32_t.

Re: [Xen-devel] [PATCH v12 00/10] x86: multiboot2 protocol support

On Fri, Jan 20, 2017 at 11:22:21AM -0500, Doug Goldstein wrote: > On 1/19/17 8:34 PM, Daniel Kiper wrote: > > Hi, > > > > I am sending twelfth version of multiboot2 protocol support for > > legacy BIOS and EFI platforms. This patch series release contains > > fixes for all known/confirmed issues.

[Xen-devel] [PATCH v2] kexec: implemented XEN KEXEC STATUS to determine if an image is loaded

Instead of the scripts having to poke at various fields we can provide that functionality via the -S parameter. Returns 0 if the payload is loaded. Can be used in combination with -l or -p to get the state of the proper kexec image. Signed-off-by: Konrad Rzeszutek Wilk

Re: [Xen-devel] [linux-linus bisection] complete test-amd64-amd64-xl-qemut-win7-amd64 [and 1 more messages]

On 01/20/2017 11:29 AM, Boris Ostrovsky wrote: > On 01/20/2017 06:09 AM, Ian Jackson wrote: >> Boris Ostrovsky writes ("Re: [linux-linus bisection] complete >> test-amd64-amd64-xl-qemut-win7-amd64 [and 1 more messages]"): >>> On 01/19/2017 01:05 PM, Ian Jackson wrote: This means that the bug

Re: [Xen-devel] [PATCH v12 02/10] x86: add multiboot2 protocol support

On 20/01/17 01:34, Daniel Kiper wrote: > @@ -101,3 +112,126 @@ multiboot_info_t __stdcall *reloc(u32 mbi_in, u32 > trampoline) > > return mbi_out; > } > + > +static multiboot_info_t *mbi2_reloc(u32 mbi_in) > +{ > +const multiboot2_fixed_t *mbi_fix = _p(mbi_in); > +const

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

> -Original Message- > From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Jan > Beulich > Sent: 20 January 2017 16:38 > To: Paul Durrant > Cc: Wei Liu ; Andrew Cooper > ; Jennifer Herbert >

Re: [Xen-devel] [PATCH v12 01/10] x86/boot: implement early command line parser in C

On 1/20/17 11:37 AM, Doug Goldstein wrote: > On 1/19/17 8:34 PM, Daniel Kiper wrote: >> diff --git a/xen/arch/x86/boot/Makefile b/xen/arch/x86/boot/Makefile >> index 5fdb5ae..6d20646 100644 >> --- a/xen/arch/x86/boot/Makefile >> +++ b/xen/arch/x86/boot/Makefile >> @@ -1,8 +1,15 @@ >> obj-bin-y +=

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

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 20 January 2017 16:21 > To: Paul Durrant > Cc: Andrew Cooper ; Ian Jackson > ; xen-de...@lists.xenproject.org; Daniel De Graaf >

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

>>> On 20.01.17 at 17:32, wrote: >> -Original Message- >> From: Jan Beulich [mailto:jbeul...@suse.com] >> Sent: 20 January 2017 16:21 >> To: Paul Durrant >> Cc: Andrew Cooper ; Ian Jackson >>

Re: [Xen-devel] [PATCH v12 01/10] x86/boot: implement early command line parser in C

On 1/19/17 8:34 PM, Daniel Kiper wrote: > diff --git a/xen/arch/x86/boot/Makefile b/xen/arch/x86/boot/Makefile > index 5fdb5ae..6d20646 100644 > --- a/xen/arch/x86/boot/Makefile > +++ b/xen/arch/x86/boot/Makefile > @@ -1,8 +1,15 @@ > obj-bin-y += head.o > > -RELOC_DEPS =

Re: [Xen-devel] memory hotplug for domUs

On 20/01/17 17:37, Ian Jackson wrote: > Juergen Gross writes ("Re: memory hotplug for domUs"): >> On 20/01/17 16:54, Ian Jackson wrote: >>> Why ? Why would xl mem-set not automatically do the right thing ? >> >> How would you specify the numa node to add the memory to? > > You don't have to

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

>>> On 20.01.17 at 17:20, wrote: >> From: Jan Beulich [mailto:jbeul...@suse.com] >> Sent: 20 January 2017 16:18 >> >>> On 17.01.17 at 18:29, wrote: >> > +#ifndef __XEN_PUBLIC_HVM_DM_OP_H__ >> > +#define __XEN_PUBLIC_HVM_DM_OP_H__ >> > + >> > +#if

Re: [Xen-devel] memory hotplug for domUs

Juergen Gross writes ("Re: memory hotplug for domUs"): > On 20/01/17 16:54, Ian Jackson wrote: > > Why ? Why would xl mem-set not automatically do the right thing ? > > How would you specify the numa node to add the memory to? You don't have to specify a numa node when you create a domain.

Re: [Xen-devel] [PATCH v4 5/8] dm_op: convert HVMOP_modified_memory

>>> On 17.01.17 at 18:29, wrote: > v4: > - Continuation code in dm.c modified as knock-on from compat code. Not > adding Jan's R-b since patch has fundamentally changed. Same here - other than the same code being added to compat_dm_op(), I'm unable to spot any

Re: [Xen-devel] [linux-linus bisection] complete test-amd64-amd64-xl-qemut-win7-amd64 [and 1 more messages]

On 01/20/2017 06:09 AM, Ian Jackson wrote: > Boris Ostrovsky writes ("Re: [linux-linus bisection] complete > test-amd64-amd64-xl-qemut-win7-amd64 [and 1 more messages]"): >> On 01/19/2017 01:05 PM, Ian Jackson wrote: >>> This means that the bug is in commits which diverged before the last >>>

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

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 20 January 2017 16:21 > To: Paul Durrant > Cc: Andrew Cooper ; Ian Jackson > ; xen-de...@lists.xenproject.org; Daniel De Graaf >

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

>>> On 17.01.17 at 18:29, wrote: > +static bool copy_buf_from_guest(xen_dm_op_buf_t bufs[], > +unsigned int nr_bufs, void *dst, > +unsigned int idx, size_t dst_size) > +{ > +size_t size = min_t(size_t,

Re: [Xen-devel] [PATCH v12 00/10] x86: multiboot2 protocol support

On 1/19/17 8:34 PM, Daniel Kiper wrote: > Hi, > > I am sending twelfth version of multiboot2 protocol support for > legacy BIOS and EFI platforms. This patch series release contains > fixes for all known/confirmed issues. What machines did you test this series on? It fails to boot with iPXE and

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

>>> On 17.01.17 at 18:29, wrote: > v4: > - Knock-on changes from compat code in dm.c. Not adding Jan's R-b since > the patch has fundamentally changed. I must be missing something, as I can't seem to spot any meaningful compat handling related changes. Could you

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

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

Re: [Xen-devel] [PATCH] docs: clarify xl mem-max semantics

On 20/01/17 16:51, Ian Jackson wrote: > Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] [PATCH] docs: clarify xl > mem-max semantics"): >> On Fri, Jan 20, 2017 at 10:54:18AM +0100, Juergen Gross wrote: >>> The mem-max value may not correspond to the actual memory used in the >>> domain, as it

[Xen-devel] [qemu-mainline baseline-only test] 68401: tolerable trouble: blocked/broken

This run is configured for baseline tests only. flight 68401 qemu-mainline real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68401/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): build-armhf-xsm 3 host-install(3)

Re: [Xen-devel] memory hotplug for domUs

On 20/01/17 16:54, Ian Jackson wrote: > Juergen Gross writes ("memory hotplug for domUs"): >> We first thought to enhance "xl mem-set", but after some more thinking >> about it I'd rather add a new xl command, e.g. "mem-add" (we could later >> even add "mem-remove" to support memory unplug). > >

Re: [Xen-devel] [PATCH 6/6] x86/cpuid: Only recalculate the shared feature bits once

>>> On 18.01.17 at 20:40, wrote: > @@ -165,6 +153,8 @@ static void recalculate_xstate(struct cpuid_policy *p) > > static void recalculate_common(struct cpuid_policy *p) > { > +p->extd.e1d &= ~CPUID_COMMON_1D_FEATURES; > + > switch ( p->x86_vendor ) > {

Re: [Xen-devel] [RFC PATCH v2 03/26] ARM: GICv3 ITS: allocate device and collection table

Hi, On 20/01/17 12:18, Julien Grall wrote: > Hi Andre, > > On 20/01/2017 12:27, Andre Przywara wrote: >> On 20/01/17 11:12, Julien Grall wrote: >>> Hello, >>> >>> On 04/01/2017 22:47, Stefano Stabellini wrote: On Thu, 22 Dec 2016, Andre Przywara wrote: > Each ITS maps a pair of a

Re: [Xen-devel] [PATCH 5/6] x86/cpuid: Handle the long vendor string in guest_cpuid()

On 20/01/17 16:00, Jan Beulich wrote: On 18.01.17 at 20:40, wrote: >> Leaves 0x8002 through 0x8004 are plain ASCII text, and require no >> specific recalculation. > Do they not? We don't currently get them in line with a perhaps > overridden vendor, but

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

On Fri, Jan 20, 2017 at 03:59:22PM +, Paul Durrant wrote: > > -Original Message- > [snip] > > > + > > > +va_start(args, nr_bufs); > > > +for (idx = 0; idx < nr_bufs; idx++) > > > > Coding style. > > Ah, yes. > > > > > > + > > > +int compat_dm_op(domid_t domid, > > > +

  1   2   3   >