Re: [Xen-devel] [RFC v3 00/13] linux: generalize sections, ranges and linker tables

On Tue, Aug 09, 2016 at 03:24:29PM +0100, One Thousand Gnomes wrote: > It would also be good if someone clarified whether 6 and 7 are intended > to combine so you can take contributed patches and put them in your own > proprietary version. As a non-lawyer the intent is not clear at all. 6 and 7

Re: [Xen-devel] [PATCH v4 2/2] qdisk - hw/block/xen_disk: grant copy implementation

On 08/09/2016 06:56 PM, Anthony PERARD wrote: On Tue, Aug 02, 2016 at 04:06:30PM +0200, Paulina Szubarczyk wrote: Copy data operated on during request from/to local buffers to/from the grant references. Before grant copy operation local buffers must be allocated what is done by calling

Re: [Xen-devel] [RFC v3 00/13] linux: generalize sections, ranges and linker tables

On Tue, Aug 09, 2016 at 03:24:29PM +0100, One Thousand Gnomes wrote: > However you need to clarify the licence first I think. Linux is GPLv2, > your document only allows use of GPL with "GPL" works - not GPL v2 works ? The license defines "GPL" as "a version of the GNU General Public License or

Re: [Xen-devel] [xen-4.5-testing test] 100322: regressions - trouble: broken/fail/pass

osstest service owner writes ("[xen-4.5-testing test] 100322: regressions - trouble: broken/fail/pass"): > flight 100322 xen-4.5-testing real [real] > test-amd64-i386-qemuu-rhel6hvm-amd 3 host-install(3) broken REGR. vs. 99752 This was merlot1 having forgotten its boot order. I fixed it

Re: [Xen-devel] [PATCH v4 2/2] qdisk - hw/block/xen_disk: grant copy implementation

On Tue, Aug 02, 2016 at 04:06:30PM +0200, Paulina Szubarczyk wrote: > Copy data operated on during request from/to local buffers to/from > the grant references. > > Before grant copy operation local buffers must be allocated what is > done by calling ioreq_init_copy_buffers. For the 'read'

Re: [Xen-devel] VM_EVENT_FLAG_SET_REGISTERS and sync_vcpu_execstate()

On Tue, Aug 9, 2016 at 3:41 AM, Tim Deegan wrote: > At 19:29 +0300 on 08 Aug (1470684579), Razvan Cojocaru wrote: >> On 08/08/16 18:52, Tamas K Lengyel wrote: >> >> I think the issue might be that vm_event_vcpu_pause() uses >> >> > vcpu_pause_nosync(), and it's being used everywhere

Re: [Xen-devel] [PATCH v2 1/3] livepach: Add .livepatch.hooks functions and test-case

> >> > @@ -70,7 +71,11 @@ struct payload { > >> > unsigned int nsyms; /* Nr of entries in .strtab > >> > and > >> > symbols. */ > >> > struct livepatch_build_id id;/* > >> > ELFNOTE_DESC(.note.gnu.build-id) of the payload. */ > >> > struct

[Xen-devel] [xen-unstable-smoke test] 100368: regressions - FAIL

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

[Xen-devel] [qemu-mainline test] 100363: tolerable FAIL - PUSHED

flight 100363 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/100363/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100356

[Xen-devel] [xen-unstable-smoke test] 100374: regressions - FAIL

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

Re: [Xen-devel] unable start xen in hikey

Hi Chen, I have tried to flash UEFI in my board with latest one but still facing the same issue. Regarding to use dtb file from kernel source, I couldnt find hi6220-hikey.dtb in my source kernel. i am downloading my kernel source from here:

Re: [Xen-devel] unable start xen in hikey

On Tue, Aug 9, 2016 at 7:07 PM, Kamenee Arumugam wrote: > > Hi Chen, > > I have tried to flash UEFI in my board with latest one but still facing the > same issue. Regarding to use dtb file from kernel source, I couldnt find > hi6220-hikey.dtb in my source kernel. i am

[Xen-devel] [xen-unstable-smoke test] 100375: regressions - FAIL

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

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

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

Re: [Xen-devel] [RFC v3 00/13] linux: generalize sections, ranges and linker tables

On Aug 9, 2016 7:09 PM, "James Bottomley" < james.bottom...@hansenpartnership.com> wrote: > > On Tue, 2016-08-09 at 15:24 +0100, One Thousand Gnomes wrote: > > > table development go under copyleft-next, Rusty recently asked for > > > code to go in prior to the license tag being added denoting

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

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

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

flight 100367 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/100367/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): build-amd64-rumpuserxen 6 xen-buildfail like 100361 build-i386-rumpuserxen

[Xen-devel] [xen-4.6-testing baseline-only test] 66947: regressions - FAIL

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

Re: [Xen-devel] [PATCH v5 4/4] x86/ioreq server: Reset outstanding p2m_ioreq_server entries when an ioreq server unmaps.

On 8/9/2016 4:13 PM, Jan Beulich wrote: On 09.08.16 at 09:39, wrote: On 8/9/2016 12:29 AM, Jan Beulich wrote: On 12.07.16 at 11:02, wrote: @@ -5512,6 +5513,12 @@ static int hvmop_set_mem_type( if ( rc ) goto

Re: [Xen-devel] [PATCH v2 07/25] arm/altp2m: Add altp2m init/teardown routines.

Hi Julien, >>> @@ -1460,7 +1469,16 @@ static int p2m_init_hostp2m(struct domain *d) >>> >>> int p2m_init(struct domain *d) >>> { >>> -return p2m_init_hostp2m(d); >>> +int rc; >>> + >>> +rc = p2m_init_hostp2m(d); >>> +if ( rc ) >>> +return rc; >>> + >>> +if (

Re: [Xen-devel] VM_EVENT_FLAG_SET_REGISTERS and sync_vcpu_execstate()

On 08/09/2016 12:41 PM, Tim Deegan wrote: > At 19:29 +0300 on 08 Aug (1470684579), Razvan Cojocaru wrote: >> On 08/08/16 18:52, Tamas K Lengyel wrote: I think the issue might be that vm_event_vcpu_pause() uses > vcpu_pause_nosync(), and it's being used everywhere we pause the VCPU in

[Xen-devel] [qemu-mainline test] 100356: tolerable FAIL - PUSHED

flight 100356 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/100356/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100334

Re: [Xen-devel] [PATCH] common/vm_event: synchronize vCPU state in vm_event_resume()

On 08/09/2016 12:40 PM, Razvan Cojocaru wrote: > Vm_event_vcpu_pause() needs to use vcpu_pause_nosync() in order > for the current vCPU to not get stuck. A consequence of this is > that the custom vm_event response handlers will not always see > the real vCPU state in v->arch.user_regs. This patch

[Xen-devel] [PATCH v2] xenbus: prefer list_for_each()

This is more efficient than list_for_each_safe() when list modification is accompanied by breaking out of the loop. Signed-off-by: Jan Beulich Reviewed-by: Juergen Gross --- v2: Avoid commit message to continue from subject. ---

Re: [Xen-devel] [PATCH v5 4/4] x86/ioreq server: Reset outstanding p2m_ioreq_server entries when an ioreq server unmaps.

On 8/9/2016 5:45 PM, Jan Beulich wrote: On 09.08.16 at 11:25, wrote: On 8/9/2016 4:13 PM, Jan Beulich wrote: On 09.08.16 at 09:39, wrote: On 8/9/2016 12:29 AM, Jan Beulich wrote: On 12.07.16 at 11:02,

Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv)

>>> On 08.08.16 at 15:46, wrote: > Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu > depriv)"): >> On 05.08.16 at 18:28, wrote: >> > That is, a bug of class 2 would allow the unprivileged qemu process in >> > dom0 to

[Xen-devel] [PATCH] replace bogus -ENOSYS uses

This doesn't cover all of them, just the ones that I think would most obviously better be -EINVAL or -EOPNOTSUPP. Signed-off-by: Jan Beulich --- a/xen/arch/x86/cpu/mcheck/vmce.c +++ b/xen/arch/x86/cpu/mcheck/vmce.c @@ -440,7 +440,7 @@ int unmmap_broken_page(struct domain *d,

Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv)

Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu depriv)"): > Actually, having thought about this some more, and taking this > together with the expectations to the privcmd driver previously > outlined, I think this part is problematic: If all the driver is to know > is

Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv)

>>> On 09.08.16 at 12:48, wrote: > Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu > depriv)"): >> Actually, having thought about this some more, and taking this >> together with the expectations to the privcmd driver previously >> outlined, I

Re: [Xen-devel] [PATCH 15/19] Qemu-Xen-vTPM: Xen frontend driver infrastructure

On August 07, 2016 7:39 PM, Emil Condrea wrote: On Mon, Jul 25, 2016 at 7:01 PM, Anthony PERARD wrote: > > > > > +{ > > > +xs_transaction_t xbt = XBT_NULL; > > > + > > > +if (xendev->fe_state == xbus) { > > > +return 0; > > > +

Re: [Xen-devel] [PATCH 4/4] tools/xenalyze: Allow automatic resizing of sample buffers

On Mon, Aug 8, 2016 at 6:11 PM, anshul makkar wrote: > On 08/08/16 10:54, George Dunlap wrote: >> >> Rather than have large fixed-size buffers, start with smaller buffers >> and allow them to grow as needed (doubling each time), with a fairly >> large maximum. Allow

[Xen-devel] [PATCH] common: clean up taint logic

Drop unused UNSAFE_SMP and BAD_PAGE flags. Style adjstments. Signed-off-by: Jan Beulich --- a/xen/common/kernel.c +++ b/xen/common/kernel.c @@ -22,8 +22,6 @@ enum system_state system_state = SYS_STATE_early_boot; -int tainted; - xen_commandline_t saved_cmdline;

Re: [Xen-devel] VM_EVENT_FLAG_SET_REGISTERS and sync_vcpu_execstate()

At 19:29 +0300 on 08 Aug (1470684579), Razvan Cojocaru wrote: > On 08/08/16 18:52, Tamas K Lengyel wrote: > >> I think the issue might be that vm_event_vcpu_pause() uses > >> > vcpu_pause_nosync(), and it's being used everywhere we pause the VCPU in > >> > the course of sending out a vm_event. >

[Xen-devel] [PATCH] common/vm_event: synchronize vCPU state in vm_event_resume()

Vm_event_vcpu_pause() needs to use vcpu_pause_nosync() in order for the current vCPU to not get stuck. A consequence of this is that the custom vm_event response handlers will not always see the real vCPU state in v->arch.user_regs. This patch makes sure that the state is always synchronized in

Re: [Xen-devel] [PATCH v5 4/4] x86/ioreq server: Reset outstanding p2m_ioreq_server entries when an ioreq server unmaps.

>>> On 09.08.16 at 11:25, wrote: > > On 8/9/2016 4:13 PM, Jan Beulich wrote: > On 09.08.16 at 09:39, wrote: >>> On 8/9/2016 12:29 AM, Jan Beulich wrote: >>> On 12.07.16 at 11:02, wrote: > @@

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

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

Re: [Xen-devel] [PATCH 2/2] AMD/VPMU: Keep reserved MSR bits untouched but allow the rest to be written

>>> On 08.08.16 at 19:00, wrote: > On 08/08/2016 11:54 AM, Jan Beulich wrote: > On 08.08.16 at 17:28, wrote: >>> On 08/08/2016 11:10 AM, Jan Beulich wrote: >>> On 08.08.16 at 16:10, wrote: > On

Re: [Xen-devel] mkelf32 uninitialized data and reproducible builds

>>> On 08.08.16 at 21:23, wrote: > On Mon, Aug 08, 2016 at 07:02:25PM +, Trammell Hudson wrote: >> The xen/arch/x86/boot/mkelf32 executable is preventing Xen hypervisors >> from being reproducibly built. It is using an uninitialized stack >> buffer for padding after

Re: [Xen-devel] [OSSTEST PATCH RFC v2 11/14] Introduce ts-xtf-run

On Mon, Aug 08, 2016 at 03:55:15PM +0100, Ian Jackson wrote: > Wei Liu writes ("[OSSTEST PATCH RFC v2 11/14] Introduce ts-xtf-run"): > > This is the main script for running XTF. It will first perform > > selftest, and then run each XTF test case as a substep. > ... > > +# XTF results (runner

Re: [Xen-devel] [PATCH v5 3/4] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server.

>>> On 09.08.16 at 09:39, wrote: > On 8/8/2016 11:40 PM, Jan Beulich wrote: > On 12.07.16 at 11:02, wrote: >>> +rc = -ENOENT; >>> +list_for_each_entry ( s, >>> + >arch.hvm_domain.ioreq_server.list, >>> +

Re: [Xen-devel] [PATCH v5 3/4] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server.

> -Original Message- > From: Yu Zhang [mailto:yu.c.zh...@linux.intel.com] > Sent: 09 August 2016 09:51 > To: Paul Durrant; Jan Beulich > Cc: Andrew Cooper; George Dunlap; Jun Nakajima; Kevin Tian; > zhiyuan...@intel.com; xen-devel@lists.xen.org; Tim (Xen.org) > Subject: Re: [Xen-devel]

[Xen-devel] [PATCH] xen: enable/disable SMAP/SMEP for Xen itself

SMAP/SMEP may affect the 32-bit pv guests. Users can determine whether turn SMAP/SMEP on for Xen hyperviosr when running 32-bit pv guests. Signed-off-by: He Chen --- docs/misc/xen-command-line.markdown | 14 ++ xen/arch/x86/setup.c| 12

[Xen-devel] [PATCH] solve SMAP/SMEP issues with 32-bit pv guests

This patch is going to solve SMAP/SMEP issues with 32-bit pv guests by adding new xen command line options "xen_smap" and "xen_smep". For the details, please see: https://lists.xen.org/archives/html/xen-devel/2016-06/msg03441.html I am sorry that I don't have 32-bit PV environment to test this

Re: [Xen-devel] [PATCH 1/2] x86/altp2m: use __get_gfn_type_access to avoid lock conflicts

>>> On 09.08.16 at 01:56, wrote: > Use __get_gfn_type_access instead of get_gfn_type_access when checking > the hostp2m entries during altp2m mem_access setting and gfn remapping > to avoid a lock conflict which can make dom0 freeze. You fail to mention why the

[Xen-devel] [libvirt test] 100360: trouble: broken/fail/pass

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

[Xen-devel] [PATCH] common/vm_event: Fix comment

There's no such thing as function vm_event_wake_waiters() anymore. Signed-off-by: Razvan Cojocaru --- xen/common/vm_event.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c index 941345b..ad7f986 100644

Re: [Xen-devel] VM_EVENT_FLAG_SET_REGISTERS and sync_vcpu_execstate()

On 08/08/2016 09:01 PM, Tamas K Lengyel wrote: > On Mon, Aug 8, 2016 at 10:29 AM, Razvan Cojocaru > wrote: >> On 08/08/16 18:52, Tamas K Lengyel wrote: I think the issue might be that vm_event_vcpu_pause() uses > vcpu_pause_nosync(), and it's being used

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

flight 100352 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/100352/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 99902

Re: [Xen-devel] [PATCH v5 3/4] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server.

On 8/8/2016 11:40 PM, Jan Beulich wrote: On 12.07.16 at 11:02, wrote: @@ -178,8 +179,34 @@ static int hvmemul_do_io( break; case X86EMUL_UNHANDLEABLE: { -struct hvm_ioreq_server *s = -hvm_select_ioreq_server(curr->domain,

Re: [Xen-devel] [PATCH v5 4/4] x86/ioreq server: Reset outstanding p2m_ioreq_server entries when an ioreq server unmaps.

On 8/9/2016 12:29 AM, Jan Beulich wrote: On 12.07.16 at 11:02, wrote: @@ -5512,6 +5513,12 @@ static int hvmop_set_mem_type( if ( rc ) goto out; +if ( t == p2m_ram_rw && memtype[a.hvmmem_type] == p2m_ioreq_server ) +

Re: [Xen-devel] [PATCH v5 4/4] x86/ioreq server: Reset outstanding p2m_ioreq_server entries when an ioreq server unmaps.

>>> On 09.08.16 at 09:39, wrote: > > On 8/9/2016 12:29 AM, Jan Beulich wrote: > On 12.07.16 at 11:02, wrote: >>> @@ -5512,6 +5513,12 @@ static int hvmop_set_mem_type( >>> if ( rc ) >>> goto out; >>> >>> +

Re: [Xen-devel] [PATCH v5 3/4] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server.

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 09 August 2016 09:11 > To: Paul Durrant; Yu Zhang > Cc: Andrew Cooper; George Dunlap; Jun Nakajima; Kevin Tian; > zhiyuan...@intel.com; xen-devel@lists.xen.org; Tim (Xen.org) > Subject: Re: [Xen-devel] [PATCH v5

Re: [Xen-devel] [PATCH v5 3/4] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server.

On 8/9/2016 4:20 PM, Paul Durrant wrote: -Original Message- From: Jan Beulich [mailto:jbeul...@suse.com] Sent: 09 August 2016 09:11 To: Paul Durrant; Yu Zhang Cc: Andrew Cooper; George Dunlap; Jun Nakajima; Kevin Tian; zhiyuan...@intel.com; xen-devel@lists.xen.org; Tim (Xen.org)

Re: [Xen-devel] [PATCH 1/2] x86/altp2m: use __get_gfn_type_access to avoid lock conflicts

On 08/09/16 02:56, Tamas K Lengyel wrote: > From: Tamas K Lengyel > > Use __get_gfn_type_access instead of get_gfn_type_access when checking > the hostp2m entries during altp2m mem_access setting and gfn remapping > to avoid a lock conflict which can make dom0 freeze. > >

Re: [Xen-devel] [PATCH 2/2] x86/altp2m: allow specifying external-only use-case

>>> On 09.08.16 at 01:56, wrote: > @@ -5238,18 +5238,19 @@ static int do_altp2m_op( > goto out; > } > > -if ( (rc = xsm_hvm_altp2mhvm_op(XSM_TARGET, d)) ) > +if ( !d->arch.hvm_domain.params[HVM_PARAM_ALTP2M] ) > +{ > +rc = -EINVAL; >

Re: [Xen-devel] VM_EVENT_FLAG_SET_REGISTERS and sync_vcpu_execstate()

On 08/09/2016 11:19 AM, Razvan Cojocaru wrote: > On 08/08/2016 09:01 PM, Tamas K Lengyel wrote: >> On Mon, Aug 8, 2016 at 10:29 AM, Razvan Cojocaru >> wrote: >>> On 08/08/16 18:52, Tamas K Lengyel wrote: > I think the issue might be that vm_event_vcpu_pause() uses

Re: [Xen-devel] [PATCH v2 05/23] acpi/hvmloader: Move passthrough initialization from ACPI code

>>> On 04.08.16 at 23:06, wrote: > Initialize it in hvmloader, avoiding ACPI code's use of xenstore_read() > > Signed-off-by: Boris Ostrovsky > --- > v2: > * Dropped pt_ prefix > * Slight change in construct_passthrough_tables() code (thus

[Xen-devel] [PATCH] xen/x86: Avoid undefined behaviour by shifting into a sign bit

Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich v2: * Use ~0u as opposed to -1u --- xen/arch/x86/apic.c | 2 +- xen/arch/x86/cpu/common.c | 2 +- xen/arch/x86/x86_64/traps.c | 2 +- xen/include/asm-x86/apicdef.h | 2 +- 4

Re: [Xen-devel] [PATCH v2 10/23] acpi/hvmloader: Replace mem_alloc() and virt_to_phys() with memory ops

>>> On 04.08.16 at 23:06, wrote: > @@ -568,13 +577,13 @@ void acpi_build_tables(struct acpi_config *config) > offsetof(struct acpi_header, checksum), > sizeof(struct acpi_20_fadt)); > > -nr_secondaries =

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

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

Re: [Xen-devel] [PATCH v2 06/23] acpi/hvmloader: Collect processor and NUMA info in hvmloader

On 08/09/2016 09:27 AM, Jan Beulich wrote: On 04.08.16 at 23:06, wrote: >> --- >> v2: >> * Note: struct acpi_numa's pointers can't be constified due to their >> use in later patches > Well, I hope I'll remember once I get there. Patch 22, init_acpi_config()

Re: [Xen-devel] [PATCH] common: clean up taint logic

On 09/08/16 11:39, Jan Beulich wrote: > Drop unused UNSAFE_SMP and BAD_PAGE flags. Style adjstments. > > Signed-off-by: Jan Beulich > > --- a/xen/common/kernel.c > +++ b/xen/common/kernel.c > @@ -22,8 +22,6 @@ > > enum system_state system_state = SYS_STATE_early_boot; >

Re: [Xen-devel] [PATCH v4 01/19] x86: allow EFI reboot method neither on EFI platforms...

>>> On 06.08.16 at 01:04, wrote: > ..nor EFI platforms with runtime services disabled. DYM non-EFI in the subject part of the sentence? > --- a/xen/arch/x86/shutdown.c > +++ b/xen/arch/x86/shutdown.c > @@ -80,6 +80,9 @@ static void __init set_reboot_type(char *str) >

Re: [Xen-devel] [PATCH v2 02/23] acpi/hvmloader: Allow acpi_build_tables() callers specify acpi_info values

>>> On 04.08.16 at 23:06, wrote: > By doing this we can move hvmloader-private interfaces (such as > uart_exists(), lpt_exists() etc.) out of the ACPI builder. This will > help us with allowing to call the builder from places other than > hvmloader. > > Signed-off-by:

Re: [Xen-devel] [XTF PATCH v2] xtf-runner: use xl create -Fc directly

On 08/08/16 14:13, Wei Liu wrote: > On Mon, Aug 08, 2016 at 02:06:37PM +0100, Andrew Cooper wrote: >> On 08/08/16 12:24, Wei Liu wrote: >>> Now that xl create -c is fixed in xen-unstable, there is no need to keep >>> the hack to get guest console output anymore. >>> >>> Use xl create -Fc directly,

[Xen-devel] [PATCH] x86/string: Use compiler builtins whenever possible

The use of -fno-builtin inhibits this automatic transformation. Manually tranform the callsites. This causes constructs such as strlen("literal") to be evaluated at compile time, and certain simple operations to be replaced with repeated string operations. Signed-off-by: Andrew Cooper

Re: [Xen-devel] [PATCH v4 02/19] x86/boot: remove multiboot1_header_end from symbol table

On 06/08/16 00:04, Daniel Kiper wrote: > Its visibility is not needed and just pollute symbol table. > > Suggested-by: Jan Beulich > Signed-off-by: Daniel Kiper > --- > xen/arch/x86/boot/head.S |2 +- > 1 file changed, 1 insertion(+), 1

[Xen-devel] [xen-4.5-testing baseline-only test] 66944: regressions - FAIL

This run is configured for baseline tests only. flight 66944 xen-4.5-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/66944/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-win7-amd64 15

[Xen-devel] help -- A question about ' XENFEAT_auto_translated_physmap':

Hi Jan, A question about ' XENFEAT_auto_translated_physmap': In linux code, in arch/x86/xen/mmu.c, __xen_pgd_walk() { if (xen_feature(XENFEAT_auto_translated_physmap)) return 0; } Why xen_feature(XENFEAT_auto_translated_physmap) is true, then return

Re: [Xen-devel] help -- A question about ' XENFEAT_auto_translated_physmap':

>>> On 09.08.16 at 14:36, wrote: > Hi Jan, > > A question about ' XENFEAT_auto_translated_physmap': > > In linux code, in arch/x86/xen/mmu.c, I assume you know that I'm not a maintainer of the Linux code. > __xen_pgd_walk() > { > > > if

Re: [Xen-devel] [PATCH v2 03/23] acpi/hvmloader: Initialize vm_gid data outside ACPI code

On 08/09/2016 09:11 AM, Jan Beulich wrote: On 04.08.16 at 23:06, wrote: >> --- a/tools/firmware/hvmloader/acpi/build.c >> +++ b/tools/firmware/hvmloader/acpi/build.c >> @@ -462,32 +462,26 @@ static int construct_secondary_tables(unsigned long >> *table_ptrs, >>

Re: [Xen-devel] [PATCH v2 09/23] acpi/hvmloader: Build WAET optionally

On 08/09/2016 09:29 AM, Jan Beulich wrote: On 04.08.16 at 23:06, wrote: >> Signed-off-by: Boris Ostrovsky >> Reviewed-by: Jan Beulich >> --- >> v2: >> * Note: didn't break "if ( !waet ) return -1" line since that's

Re: [Xen-devel] [PATCH] xen/common: Avoid undefined behaviour by shifting into a sign bit

>>> On 09.08.16 at 14:48, wrote: > For d->shutdown_code, change the field to being unsigned and using an unsigned > sentinel. The sentinal needs to be distinguishable from any value > representable in a u8. > > Signed-off-by: Andrew Cooper

Re: [Xen-devel] [PATCH] xen: enable/disable SMAP/SMEP for Xen itself

>>> On 09.08.16 at 11:13, wrote: > --- a/docs/misc/xen-command-line.markdown > +++ b/docs/misc/xen-command-line.markdown > @@ -1434,6 +1434,13 @@ Set the serial transmit buffer size. > > Flag to enable Supervisor Mode Execution Protection > > +### xen_smep > +> `= `

Re: [Xen-devel] [PATCH v2 06/23] acpi/hvmloader: Collect processor and NUMA info in hvmloader

>>> On 04.08.16 at 23:06, wrote: > --- > v2: > * Note: struct acpi_numa's pointers can't be constified due to their > use in later patches Well, I hope I'll remember once I get there. > --- a/tools/firmware/hvmloader/acpi/build.c > +++

Re: [Xen-devel] [PATCH v2 09/23] acpi/hvmloader: Build WAET optionally

>>> On 04.08.16 at 23:06, wrote: > Signed-off-by: Boris Ostrovsky > Reviewed-by: Jan Beulich > --- > v2: > * Note: didn't break "if ( !waet ) return -1" line since that's the style > of the file. Style of the file? At

[Xen-devel] [PATCH] Reproducible builds of xen.gz

The mkelf32 executable was using an uninitialized stack buffer for padding after the ehdr and phdr are written to the xen file, which leads to non-deterministic bytes in the binary and prevented Xen hypervisors from being reproducibly built. Additionally, the file was then compressed with gzip -9

Re: [Xen-devel] [PATCH] Reproducible builds of xen.gz

>>> On 09.08.16 at 16:56, wrote: > --- a/xen/arch/x86/boot/mkelf32.c > +++ b/xen/arch/x86/boot/mkelf32.c > @@ -260,7 +260,7 @@ int main(int argc, char **argv) > u32loadbase, dat_siz, mem_siz, note_base, note_sz, offset; > char *inimage,

Re: [Xen-devel] [PATCH v2 22/23] libxl/acpi: Build ACPI tables for HVMlite guests

On 08/09/2016 10:46 AM, Jan Beulich wrote: On 04.08.16 at 23:06, wrote: >> +if (dom->nr_vnodes) { >> +struct acpi_numa *numa = >numa; >> + >> +rc = xc_domain_getvnuma(xch, domid, >nr_vnodes, >> +>nr_vmemranges,

Re: [Xen-devel] [PATCH v2 09/23] acpi/hvmloader: Build WAET optionally

On 08/09/2016 10:48 AM, Jan Beulich wrote: On 09.08.16 at 15:51, wrote: >> On 08/09/2016 09:29 AM, Jan Beulich wrote: >> On 04.08.16 at 23:06, wrote: Signed-off-by: Boris Ostrovsky

Re: [Xen-devel] [PATCH v2 03/23] acpi/hvmloader: Initialize vm_gid data outside ACPI code

On 09/08/16 16:09, Boris Ostrovsky wrote: > On 08/09/2016 10:47 AM, Andrew Cooper wrote: >> On 09/08/16 15:31, Jan Beulich wrote: >> On 09.08.16 at 15:50, wrote: On 08/09/2016 09:11 AM, Jan Beulich wrote: On 04.08.16 at 23:06,

Re: [Xen-devel] [PATCH v2 03/23] acpi/hvmloader: Initialize vm_gid data outside ACPI code

>>> On 09.08.16 at 17:09, wrote: > On 08/09/2016 10:47 AM, Andrew Cooper wrote: >> On 09/08/16 15:31, Jan Beulich wrote: >> On 09.08.16 at 15:50, wrote: On 08/09/2016 09:11 AM, Jan Beulich wrote: On 04.08.16 at 23:06,

Re: [Xen-devel] [PATCH] xen: handle inbound migration of VMs without ioreq server pages

On Mon, Aug 01, 2016 at 10:16:25AM +0100, Paul Durrant wrote: > VMs created on older versions on Xen will not have been provisioned with > pages to support creation of non-default ioreq servers. In this case > the ioreq server API is not supported and QEMU's only option is to fall > back to using

Re: [Xen-devel] [PATCH v2 03/23] acpi/hvmloader: Initialize vm_gid data outside ACPI code

>>> On 04.08.16 at 23:06, wrote: > --- a/tools/firmware/hvmloader/acpi/build.c > +++ b/tools/firmware/hvmloader/acpi/build.c > @@ -462,32 +462,26 @@ static int construct_secondary_tables(unsigned long > *table_ptrs, > * > * Return 0 if memory failure, != 0 if

[Xen-devel] [PATCH] xen/common: Avoid undefined behaviour by shifting into a sign bit

For d->shutdown_code, change the field to being unsigned and using an unsigned sentinel. The sentinal needs to be distinguishable from any value representable in a u8. Signed-off-by: Andrew Cooper Reviewed-by: George Dunlap --- CC: Jan

[Xen-devel] [PATCH] x86/microcode: Avoid undefined behaviour from signed integer overflow

The checksums should be calculated using unsigned 32bit integers, as they are intended to overflow and end at 0. Replace some other signed integers with unsigned ones, to avoid mixed-sign comparisons. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich

Re: [Xen-devel] [PATCH v2 06/23] acpi/hvmloader: Collect processor and NUMA info in hvmloader

On 08/09/2016 09:43 AM, Boris Ostrovsky wrote: > On 08/09/2016 09:27 AM, Jan Beulich wrote: > On 04.08.16 at 23:06, wrote: >>> --- >>> v2: >>> * Note: struct acpi_numa's pointers can't be constified due to their >>> use in later patches >> Well, I hope I'll

Re: [Xen-devel] [PATCH] x86/string: Use compiler builtins whenever possible

>>> On 09.08.16 at 14:41, wrote: > The use of -fno-builtin inhibits this automatic transformation. Manually > tranform the callsites. This causes constructs such as strlen("literal") to > be evaluated at compile time, and certain simple operations to be replaced >

Re: [Xen-devel] [PATCH v2 03/23] acpi/hvmloader: Initialize vm_gid data outside ACPI code

On 08/09/2016 10:47 AM, Andrew Cooper wrote: > On 09/08/16 15:31, Jan Beulich wrote: > On 09.08.16 at 15:50, wrote: >>> On 08/09/2016 09:11 AM, Jan Beulich wrote: >>> On 04.08.16 at 23:06, wrote: > ---

Re: [Xen-devel] [PATCH v2 09/23] acpi/hvmloader: Build WAET optionally

>>> On 09.08.16 at 17:13, wrote: > On 08/09/2016 10:48 AM, Jan Beulich wrote: > On 09.08.16 at 15:51, wrote: >>> On 08/09/2016 09:29 AM, Jan Beulich wrote: >>> On 04.08.16 at 23:06, wrote: >

Re: [Xen-devel] [PATCH] xen: handle inbound migration of VMs without ioreq server pages

> -Original Message- > From: Anthony PERARD [mailto:anthony.per...@citrix.com] > Sent: 09 August 2016 16:19 > To: Paul Durrant > Cc: xen-de...@lists.xenproject.org; qemu-de...@nongnu.org; Stefano > Stabellini > Subject: Re: [PATCH] xen: handle inbound migration of VMs without ioreq >

Re: [Xen-devel] [PATCH] x86/string: Use compiler builtins whenever possible

On 09/08/16 15:01, Jan Beulich wrote: On 09.08.16 at 14:41, wrote: >> The use of -fno-builtin inhibits this automatic transformation. Manually >> tranform the callsites. This causes constructs such as strlen("literal") to >> be evaluated at compile time, and

Re: [Xen-devel] [RFC v3 00/13] linux: generalize sections, ranges and linker tables

> table development go under copyleft-next, Rusty recently asked for code > to go in prior to the license tag being added denoting this license as > GPL-compatible [3] -- I had noted in the patch submission which annotated > copyleft-next's compatibility to GPLv2 that copyleft-next is the license

[Xen-devel] Maintenance on wiki.xenproject.org : Wed Aug 10, 8:00 - 9:00 UTC

Hi all, just a quick note that we are upgrading the MediaWiki instance on Wed Aug 10, from 8:00 - 9:00 UTC. During this time, the wiki will be disabled for up to 15 minutes while we copy the database into the updated Wiki installation. Should you have any problems after the upgrade, please

Re: [Xen-devel] [PATCH v2 22/23] libxl/acpi: Build ACPI tables for HVMlite guests

>>> On 04.08.16 at 23:06, wrote: > +if (dom->nr_vnodes) { > +struct acpi_numa *numa = >numa; > + > +rc = xc_domain_getvnuma(xch, domid, >nr_vnodes, > +>nr_vmemranges, > +

Re: [Xen-devel] [PATCH v2 09/23] acpi/hvmloader: Build WAET optionally

>>> On 09.08.16 at 15:51, wrote: > On 08/09/2016 09:29 AM, Jan Beulich wrote: > On 04.08.16 at 23:06, wrote: >>> Signed-off-by: Boris Ostrovsky >>> Reviewed-by: Jan Beulich >>> --- >>>

Re: [Xen-devel] [Design RFC] Towards work-conserving RTDS scheduler

On Mon, Aug 8, 2016 at 5:38 AM, Dario Faggioli wrote: > On Thu, 2016-08-04 at 01:15 -0400, Meng Xu wrote: >> Hi Dario, >> > Hi, > >> I'm thinking about changing the current RTDS scheduler to >> work-conserving version as we briefly discussed before. >> Below is a design

Re: [Xen-devel] [PATCH] common: clean up taint logic

>>> On 09.08.16 at 15:16, wrote: > On 09/08/16 11:39, Jan Beulich wrote: >> --- a/xen/common/kernel.c >> +++ b/xen/common/kernel.c >> @@ -22,8 +22,6 @@ >> >> enum system_state system_state = SYS_STATE_early_boot; >> >> -int tainted; >> - >> xen_commandline_t

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

flight 100361 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/100361/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): build-amd64-rumpuserxen 6 xen-buildfail like 100348 build-i386-rumpuserxen

Re: [Xen-devel] [PATCH v2 03/23] acpi/hvmloader: Initialize vm_gid data outside ACPI code

>>> On 09.08.16 at 15:50, wrote: > On 08/09/2016 09:11 AM, Jan Beulich wrote: > On 04.08.16 at 23:06, wrote: >>> --- a/tools/firmware/hvmloader/acpi/build.c >>> +++ b/tools/firmware/hvmloader/acpi/build.c >>> @@ -462,32 +462,26 @@

  1   2   >