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

flight 100348 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/100348/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail REGR. vs. 100326 build-amd64-rumpuserxen

Re: [Xen-devel] [Very RFC PATCH] Livepatch - initial ARM64/32 support.

On Tue, Aug 09, 2016 at 12:18:57AM -0400, Konrad Rzeszutek Wilk wrote: > Hey! > > Over the last couple of months in my spare time I was playing > with making livepatch work with ARM64 (using the FoundationModel > simulator) and I finally got it working tonight. The git tree is

[Xen-devel] [Very RFC PATCH 3/3] livepatch: Initial ARM32/64 support.

The initial support for ARM64 - and livepatching works: (XEN) livepatch: xen_hello_world: Applying 1 functions (XEN) hi_func: Hi! (called 1 times) (XEN) Hook executing. (XEN) livepatch: xen_hello_world finished APPLY with rc=0 (XEN) livepatch.c:1687: livepatch: load_payload_fnc: rc=0 (p->rc=0)

[Xen-devel] [Very RFC PATCH 1/3] mm/arm: Introduce modify_xen_mappings

Which is only used by Livepatch code. The purpose behind this call is to modify the page table entries flags. Specifically the .ro and .nx flags. The current mechanism puts cache attributes in the flags and the .ro and .nx are locked down and assumed to be .ro=0, nx=1. Livepatch needs .nx=0 and

[Xen-devel] [Very RFC PATCH 2/3] insn: Add arch64_insn_gen_branch_imm to generate branch

We copied from Linux code (v4.7) the code that generates the unconditional branch instructions. This is mostly from Linux commit c0cafbae20d2878883ec3c06d6ea30ff38a6bf92 "arm64: introduce aarch64_insn_gen_branch_reg()" However the branch-link instructions was omitted, only the branch instruction

[Xen-devel] [Very RFC PATCH] Livepatch - initial ARM64/32 support.

Hey! Over the last couple of months in my spare time I was playing with making livepatch work with ARM64 (using the FoundationModel simulator) and I finally got it working tonight. Sending out the patches just in case they don't work tomorrow :-) The ARM32 part is going slowly - as I don't have

Re: [Xen-devel] [RFC v3 07/13] tables.h: add linker table support

On Mon, Aug 08, 2016 at 05:05:39PM +0200, Luis R. Rodriguez wrote: > > So how can I disable those table-* things from even getting built? Avoid > > using table-y? But then everything declared table-y will be built > > unconditionally. I don't think I like that. :-\ > > I suppose we could make

[Xen-devel] [qemu-mainline baseline-only test] 66941: tolerable FAIL

This run is configured for baseline tests only. flight 66941 qemu-mainline real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/66941/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-qemuu-nested-intel 16

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

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

[Xen-devel] [xen-4.5-testing test] 100338: tolerable FAIL - PUSHED

flight 100338 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/100338/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stopfail blocked in 99752

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

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. Signed-off-by: Tamas K Lengyel

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

Currently setting altp2mhvm=1 in the domain configuration allows access to the altp2m interface for both in-guest and external privileged tools. This poses a problem for use-cases where only external access should be allowed, requiring the user to compile Xen with XSM enabled to be able to

Re: [Xen-devel] Coreboot + Linux + kexec + Xen

On 08/08/2016 19:54, Trammell Hudson wrote: > This is in reply to an ancient post to the xen-devel list: > > http://ward.vandewege.net/blog/2008/08/kexecing-into-a-xen-kernel/ > http://old-list-archives.xenproject.org/archives/html/xen-devel/2008-08/msg00298.html > > Ward Vandewege wrote (in

Re: [Xen-devel] "Tried to do a paging op on itself"

On 08/08/2016 21:35, Alina wrote: > Hello, > > When I try to enable shadow page table features using the shadow_control > function, I get this message in the hypervisor logs: "Tried to do a paging > op on itself". After backtracking to the source of this message, I > discovered it comes from the

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

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

Re: [Xen-devel] Proposed plan and URL name for new VM to download xen tarballs (ftp.xenproject.org)

> On 8 Aug 2016, at 15:04, Ian Jackson wrote: > > Lars Kurth writes ("Re: Proposed plan and URL name for new VM to download xen > tarballs (ftp.xenproject.org)"): >> I don't mind. I can ask Credativ whether that is doable from a load >> perspective. But the answer

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

flight 100334 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/100334/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-multivcpu 3 host-install(3) broken in 100310 pass in 100334 test-amd64-amd64-xl-xsm

Re: [Xen-devel] "Tried to do a paging op on itself"

On Mon, 8 Aug 2016 13:35:42 -0700 (MST) Alina wrote: > When I try to enable shadow page table features using the shadow_control > function, I get this message in the hypervisor logs: "Tried to do a paging > op on itself". After backtracking to the source of this message, I > discovered it comes

Re: [Xen-devel] "Tried to do a paging op on itself"

Hello, > When I try to enable shadow page table features using the shadow_control > function, I get this message in the hypervisor logs: "Tried to do a paging > op on itself". After backtracking to the source of this message, I > discovered it comes from the condition: "if ( unlikely(d ==

[Xen-devel] "Tried to do a paging op on itself"

Hello, When I try to enable shadow page table features using the shadow_control function, I get this message in the hypervisor logs: "Tried to do a paging op on itself". After backtracking to the source of this message, I discovered it comes from the condition: "if ( unlikely(d ==

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

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

[Xen-devel] [xen-4.6-testing test] 100329: regressions - trouble: broken/fail/pass

flight 100329 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/100329/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-pvh-intel 6 xen-boot fail REGR. vs. 99902

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

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 the ehdr and phdr are written to the xen file, > which leads to

Re: [Xen-devel] Build problems with xen 4.7

On Mon, 8 Aug 2016, Peng Fan wrote: > ... > :0:0: error: "__OBJECT_FILE__" redefined [-Werror] > :0:0: note: this is the location of the previous definition > cc1: all warnings being treated as errors > > ... > > Does this patch work when cross compile for ARM64? I dropped that patch following

[Xen-devel] mkelf32 uninitialized data and reproducible builds

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 the ehdr and phdr are written to the xen file, which leads to non-deterministic bytes in the binary. Additionally, the file is then

[Xen-devel] Coreboot + Linux + kexec + Xen

This is in reply to an ancient post to the xen-devel list: http://ward.vandewege.net/blog/2008/08/kexecing-into-a-xen-kernel/ http://old-list-archives.xenproject.org/archives/html/xen-devel/2008-08/msg00298.html Ward Vandewege wrote (in 2008): > There seems to be a regression with regard to

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

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

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

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

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

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 everywhere we pause the VCPU in >>> > the course of sending

Re: [Xen-devel] [PATCH 0/3] tools: support autoballooning of xenstore domain

On 08/08/16 16:45, Ian Jackson wrote: > Juergen Gross writes ("[PATCH 0/3] tools: support autoballooning of xenstore > domain"): >> Support xenstore domain autoballooning by: >> - adding --maxmem parameter to init-xenstore-domain >> - build xenstore stubdom with Mini-OS CONFIG_BALLOON set >> -

[Xen-devel] Raw Image vs LVM cloning

hi all,  is there any difference for a raw image vm save/restore vs an LVM vm save/restore?  the case is the LVM one won’t work after restore due to the hang_up_task error but the raw img is working properly.  If someone used LVM save/restore and didn’t get any error please let me know, or it's

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

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 this maximum to be set by a command-line parameter. Signed-off-by: George Dunlap

Re: [Xen-devel] xenbits "official" repo for XTF (was Re: [PATCH 0/2] xtf: add launcher (+1 bugfix)

Ian Jackson writes ("Re: [Xen-devel] xenbits "official" repo for XTF (was Re: [PATCH 0/2] xtf: add launcher (+1 bugfix)"): > With my xenbits admin hat on I therefore intend to: > > * Create xtf.git in the xenbits toplevel >and give it the appropriate permissions I created a group

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

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 08/08/2016 09:56 AM, Jan Beulich wrote: On 08.08.16 at 15:41,

Re: [Xen-devel] [PATCH RFC] libxl: make firmware_override able to cope with relative path

Andrew Cooper writes ("Re: [PATCH RFC] libxl: make firmware_override able to cope with relative path"): > On 08/08/16 17:24, Ian Jackson wrote: > > My example was disk images. > > I fail to see why any question of disk image is relevant here. It is relevant because we want a coherent answer to

Re: [Xen-devel] [OSSTEST PATCH RFC v2 09/14] mfi-common: create xtf build job for 4.8 onwards

On Mon, Aug 08, 2016 at 05:26:16PM +0100, Andrew Cooper wrote: > On 08/08/16 17:21, Wei Liu wrote: > > On Mon, Aug 08, 2016 at 03:51:06PM +0100, Ian Jackson wrote: > >> Wei Liu writes ("[OSSTEST PATCH RFC v2 09/14] mfi-common: create xtf build > >> job for 4.8 onwards"): > >>> Signed-off-by: Wei

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

Andrew Cooper writes ("Re: [Xen-devel] [OSSTEST PATCH RFC v2 11/14] Introduce ts-xtf-run"): > On 08/08/16 10:22, Wei Liu wrote: ... > > The script may exit early if it detects the test host is down or > > xtf-runner returns non-recognisable exit code. > > What is OSSTests general approach to

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

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

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

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. >> > >> > So this creates the premise for a race condition: either some

Re: [Xen-devel] [PATCH RFC] libxl: make firmware_override able to cope with relative path

On 08/08/16 17:24, Ian Jackson wrote: > Andrew Cooper writes ("Re: [PATCH RFC] libxl: make firmware_override able to > cope with relative path"): >> On 08/08/16 17:09, Ian Jackson wrote: >>> Discuss what should happen when the domain is subsequently migrated. >>> (4 marks) >> No change. >> >> In

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

>>> 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 ) > +p2m->ioreq.entry_count++; > + > +

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

On 08/08/16 10:22, Wei Liu wrote: > This is the main script for running XTF. It will first perform > selftest, and then run each XTF test case as a substep. > > It does the following things: > > 1. Run self tests for individual environment and record the result. > 2. Collect tests according to

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

flight 100326 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/100326/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-pvops3 host-install(3) broken in 7 REGR. vs. 100326

Re: [Xen-devel] [OSSTEST PATCH RFC v2 09/14] mfi-common: create xtf build job for 4.8 onwards

On 08/08/16 17:21, Wei Liu wrote: > On Mon, Aug 08, 2016 at 03:51:06PM +0100, Ian Jackson wrote: >> Wei Liu writes ("[OSSTEST PATCH RFC v2 09/14] mfi-common: create xtf build >> job for 4.8 onwards"): >>> Signed-off-by: Wei Liu >> FAOD I am expecting xtf to be useable for

Re: [Xen-devel] [PATCH RFC] libxl: make firmware_override able to cope with relative path

Andrew Cooper writes ("Re: [PATCH RFC] libxl: make firmware_override able to cope with relative path"): > On 08/08/16 17:09, Ian Jackson wrote: > > Discuss what should happen when the domain is subsequently migrated. > > (4 marks) > > No change. > > In both of these cases, they are boot-time

Re: [Xen-devel] [OSSTEST PATCH RFC v2 09/14] mfi-common: create xtf build job for 4.8 onwards

On Mon, Aug 08, 2016 at 03:51:06PM +0100, Ian Jackson wrote: > Wei Liu writes ("[OSSTEST PATCH RFC v2 09/14] mfi-common: create xtf build > job for 4.8 onwards"): > > Signed-off-by: Wei Liu > > FAOD I am expecting xtf to be useable for older branches by the time > this

Re: [Xen-devel] [PATCH RFC] libxl: make firmware_override able to cope with relative path

On 08/08/16 17:09, Ian Jackson wrote: > Andrew Cooper writes ("Re: [PATCH RFC] libxl: make firmware_override able to > cope with relative path"): >> The important bit which XTF and regular users want is relative to the >> .cfg file, rather than $CWD. > Consider: > > cd /root/foo > xl create

Re: [Xen-devel] [PATCH RFC] libxl: make firmware_override able to cope with relative path

Andrew Cooper writes ("Re: [PATCH RFC] libxl: make firmware_override able to cope with relative path"): > The important bit which XTF and regular users want is relative to the > .cfg file, rather than $CWD. Consider: cd /root/foo xl create dir/vm1/vm1.cfg cd /root/bar xl block-attach

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

On 08/08/16 16:15, Jan Beulich wrote: On 08.08.16 at 16:10, wrote: >> On 08/08/16 15:01, Jan Beulich wrote: >> On 08.08.16 at 15:42, wrote: On 05/08/16 16:35, Jan Beulich wrote: On 04.08.16 at 17:49,

Re: [Xen-devel] [PATCH RFC] libxl: make firmware_override able to cope with relative path

On 08/08/16 16:49, Ian Jackson wrote: > Wei Liu writes ("Re: [PATCH RFC] libxl: make firmware_override able to cope > with relative path"): >> On Mon, Aug 08, 2016 at 04:09:49PM +0100, Ian Jackson wrote: >>> Wei Liu writes ("[PATCH RFC] libxl: make firmware_override able to cope >>> with

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 17:28, wrote: > On 08/08/2016 11:10 AM, Jan Beulich wrote: > On 08.08.16 at 16:10, wrote: >>> On 08/08/2016 09:56 AM, Jan Beulich wrote: >>> On 08.08.16 at 15:41, wrote: > While

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

On Mon, Aug 8, 2016 at 9:10 AM, Razvan Cojocaru wrote: > On 08/08/2016 03:47 PM, Razvan Cojocaru wrote: >> On 08/08/2016 03:01 PM, Andrew Cooper wrote: >>> On 08/08/16 11:31, Razvan Cojocaru wrote: Hello, We've been mostly setting registers by using

Re: [Xen-devel] [PATCH RFC] libxl: make firmware_override able to cope with relative path

Wei Liu writes ("Re: [PATCH RFC] libxl: make firmware_override able to cope with relative path"): > On Mon, Aug 08, 2016 at 04:09:49PM +0100, Ian Jackson wrote: > > Wei Liu writes ("[PATCH RFC] libxl: make firmware_override able to cope > > with relative path"): > > > And also document that

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 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, ); > +struct

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

On 08/08/2016 11:10 AM, Jan Beulich wrote: On 08.08.16 at 16:10, wrote: >> On 08/08/2016 09:56 AM, Jan Beulich wrote: >> On 08.08.16 at 15:41, wrote: While AMD APM suggests that reserved MSR bits are not supposed to be

Re: [Xen-devel] [PATCH RFC] libxl: make firmware_override able to cope with relative path

On Mon, Aug 08, 2016 at 04:09:49PM +0100, Ian Jackson wrote: > Wei Liu writes ("[PATCH RFC] libxl: make firmware_override able to cope with > relative path"): > > And also document that option in xl.cfg(5). > ... > > -Select the virtual firmware that is exposed to the guest. > > +Select the

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

>>> On 08.08.16 at 16:10, wrote: > On 08/08/16 15:01, Jan Beulich wrote: > On 08.08.16 at 15:42, wrote: >>> On 05/08/16 16:35, Jan Beulich wrote: >>> On 04.08.16 at 17:49, wrote: > In general, the hooks

Re: [Xen-devel] [PATCH 1/2] AMD/VPMU: 0xc0010000 - 0xc001007 MSRs are in PMU range

On 08/08/2016 10:09 AM, Jan Beulich wrote: >> The reserved bits look the same on all supported families --- bits >> 63:42, 39:36, 21 and 19. Except apparently on family 12h bit 19 is MBZ. > Isn't MBZ == reserved for all practical purposes? My understanding is that when something is MBZ we know

Re: [Xen-devel] [PATCH 1/2] AMD/VPMU: 0xc0010000 - 0xc001007 MSRs are in PMU range

>>> On 08.08.16 at 17:05, wrote: > On 08/08/2016 10:09 AM, Jan Beulich wrote: >>> The reserved bits look the same on all supported families --- bits >>> 63:42, 39:36, 21 and 19. Except apparently on family 12h bit 19 is MBZ. >> Isn't MBZ == reserved for all practical

Re: [Xen-devel] [PATCH] libxl: fix declaration of libxl_primary_console_exec_0x040700

On Mon, Aug 08, 2016 at 04:10:11PM +0100, Ian Jackson wrote: > Wei Liu writes ("[PATCH] libxl: fix declaration of > libxl_primary_console_exec_0x040700"): > > Add missing "int". > > Ooops! > > Acked-by: Ian Jackson Thanks. I will push it soon.

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 16:10, wrote: > On 08/08/2016 09:56 AM, Jan Beulich wrote: > On 08.08.16 at 15:41, wrote: >>> While AMD APM suggests that reserved MSR bits are not supposed to be >>> touched, it is not clear how (or whether) HW

Re: [Xen-devel] [PATCH] libxl: fix declaration of libxl_primary_console_exec_0x040700

Wei Liu writes ("[PATCH] libxl: fix declaration of libxl_primary_console_exec_0x040700"): > Add missing "int". Ooops! Acked-by: Ian Jackson ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH RFC] libxl: make firmware_override able to cope with relative path

Wei Liu writes ("[PATCH RFC] libxl: make firmware_override able to cope with relative path"): > And also document that option in xl.cfg(5). ... > -Select the virtual firmware that is exposed to the guest. > +Select the virtual bios that is exposed to the guest. > By default, a guess is made

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

On 08/08/2016 03:47 PM, Razvan Cojocaru wrote: > On 08/08/2016 03:01 PM, Andrew Cooper wrote: >> On 08/08/16 11:31, Razvan Cojocaru wrote: >>> Hello, >>> >>> We've been mostly setting registers by using xc_vcpu_setcontext(): >>> >>>

Re: [Xen-devel] [RFC v3 07/13] tables.h: add linker table support

On Fri, Jul 29, 2016 at 12:06:30PM +0200, Borislav Petkov wrote: > On Fri, Jul 22, 2016 at 02:24:41PM -0700, Luis R. Rodriguez wrote: > > A linker table is a data structure that is stitched together from items > > in multiple object files. Linux has historically implicitly used linker > > tables

[Xen-devel] [PATCH] libxl: fix declaration of libxl_primary_console_exec_0x040700

Add missing "int". Signed-off-by: Wei Liu --- tools/libxl/libxl.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h index 030aad5..ae21302 100644 --- a/tools/libxl/libxl.h +++ b/tools/libxl/libxl.h @@ -1476,8

Re: [Xen-devel] [OSSTEST PATCH RFC v2 13/14] make-flight: create 5 xtf jobs

Wei Liu writes ("[OSSTEST PATCH RFC v2 13/14] make-flight: create 5 xtf jobs"): > Create jobs only for x86 and set host flag diverse-xtf-x86. I think I acked this one previously. Anyway, Acked-by: Ian Jackson ___ Xen-devel

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

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 returned numeric values) and OSStest results: > +# > +# SUCCESS(0) -> pass

Re: [Xen-devel] [OSSTEST PATCH RFC v2 12/14] sg-run-job: test-xtf recipe

Wei Liu writes ("[OSSTEST PATCH RFC v2 12/14] sg-run-job: test-xtf recipe"): > Install XTF, run FEP test and then run all available tests. Acked-by: Ian Jackson ___ Xen-devel mailing list Xen-devel@lists.xen.org

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

Wei Liu writes ("[OSSTEST PATCH RFC v2 10/14] Introduce ts-xtf-fep"): > Test the availability of FEP during runtime. ... > +$output =~ m/^(\d+)$/ or die "$output ?"; > + > +return $1; > +} > + > +exit fep_test(); I think something in this script should log the exit status. Digging the

Re: [Xen-devel] [OSSTEST PATCH RFC v2 09/14] mfi-common: create xtf build job for 4.8 onwards

Wei Liu writes ("[OSSTEST PATCH RFC v2 09/14] mfi-common: create xtf build job for 4.8 onwards"): > Signed-off-by: Wei Liu FAOD I am expecting xtf to be useable for older branches by the time this patch series is non-RFC. Thanks, Ian.

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

Wei Liu writes ("[OSSTEST PATCH RFC v2 08/14] Introduce ts-xtf-install"): > Extract XTF to the desire location. ^d Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [OSSTEST PATCH RFC v2 05/14] BuildSupport: move buildcmd_stamped_logged here

Wei Liu writes ("[OSSTEST PATCH RFC v2 05/14] BuildSupport: move buildcmd_stamped_logged here"): > ... so that other build scripts can use it, too. > > It now accepts one more parameter called "component" to be useful in > other build scripts. Acked-by: Ian Jackson

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

Wei Liu writes ("[OSSTEST PATCH RFC v2 06/14] Introduce ts-xtf-build"): > Clone, build and package XTF for later use. > > Signed-off-by: Wei Liu Acked-by: Ian Jackson ___ Xen-devel mailing list

[Xen-devel] Update on http to https migration

Hi all, a quick note that we now moved most of our websites to https: For the following websites, no http sites are available 1) xenproject.org There are a couple of known issues: The documentation and mailing list pages contains a form to xen.markmail.org which is not available as https

Re: [Xen-devel] [PATCH 0/3] tools: support autoballooning of xenstore domain

Juergen Gross writes ("[PATCH 0/3] tools: support autoballooning of xenstore domain"): > Support xenstore domain autoballooning by: > - adding --maxmem parameter to init-xenstore-domain > - build xenstore stubdom with Mini-OS CONFIG_BALLOON set > - add XENSTORE_MAX_DOMAIN_SIZE parameter to

Re: [Xen-devel] [OSSTEST PATCH RFC v2 03/14] ap-common: add xtf tree

Wei Liu writes ("[OSSTEST PATCH RFC v2 03/14] ap-common: add xtf tree"): > Signed-off-by: Wei Liu Acked-by: Ian Jackson ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [OSSTEST PATCH RFC v2 01/14] ts-xen-build: always compile in FEP support

Wei Liu writes ("[OSSTEST PATCH RFC v2 01/14] ts-xen-build: always compile in FEP support"): > By default FEP depends on debug flag. When we are near release the debug > flag will be turned off. In order to test a release build, we explicitly > enable FEP in build configuration. Acked-by: Ian

[Xen-devel] [PATCH RFC] libxl: make firmware_override able to cope with relative path

And also document that option in xl.cfg(5). Signed-off-by: Wei Liu --- Cc: Ian Jackson Cc: Andrew Cooper I suppose this should be able to make xtf free from absolute paths in config files. --- docs/man/xl.cfg.pod.5.in

Re: [Xen-devel] Build problems with xen 4.7

Hi, On Fri, May 13, 2016 at 11:23:29AM -0400, Konrad Rzeszutek Wilk wrote: >On Fri, May 13, 2016 at 03:25:52PM +0100, M A Young wrote: >> On Fri, 13 May 2016, Jan Beulich wrote: >> >> > >>> On 13.05.16 at 15:49, wrote: >> > > ... >> > > >> > > Still an issue - with

Re: [Xen-devel] pci passthrough kills qemu-xen

On Wed, Jul 27, Konrad Rzeszutek Wilk wrote: > > Xen 4.7.20160704T103633.a492556-1.xen47 > > (XEN) Xen version 4.7.20160704T103633.a492556-1.xen47 (abuild@) (gcc (SUSE > > Linux) 4.8.5) debug=n Mon Jul 4 12:36:33 UTC 2016 > > Could you recompile it with debug=y? Its attached, nothing special

Re: [Xen-devel] [PATCH V2] x86/hvm: Allow guest_request vm_events coming from userspace

On 08/08/2016 02:34 PM, Jan Beulich wrote: On 08.08.16 at 10:06, wrote: >> Allow guest userspace code to request that a vm_event be sent out >> via VMCALL. This functionality seems to be handy for a number of >> Xen developers, as stated on the mailing list (thread

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

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

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

On 08/08/16 15:01, Jan Beulich wrote: On 08.08.16 at 15:42, wrote: >> On 05/08/16 16:35, Jan Beulich wrote: >> On 04.08.16 at 17:49, wrote: In general, the hooks provide flexibility when having to deal with unforeseen cases,

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

On 08/08/2016 09:56 AM, Jan Beulich wrote: On 08.08.16 at 15:41, wrote: >> While AMD APM suggests that reserved MSR bits are not supposed to be >> touched, it is not clear how (or whether) HW enforces this for PMU >> registers. At least on some family 10h

Re: [Xen-devel] [PATCH 1/2] AMD/VPMU: 0xc0010000 - 0xc001007 MSRs are in PMU range

>>> On 08.08.16 at 16:06, wrote: > On 08/08/2016 09:53 AM, Jan Beulich wrote: > On 08.08.16 at 15:41, wrote: >>> --- a/xen/arch/x86/traps.c >>> +++ b/xen/arch/x86/traps.c >>> @@ -2903,6 +2903,7 @@ static int emulate_privileged_op(struct

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)"): >> I'm having, however, a hard time imagining a class 2 bug for any >> of the hvmop-s that are being converted by the hvmctl series: >> These act on

Re: [Xen-devel] [PATCH 1/2] AMD/VPMU: 0xc0010000 - 0xc001007 MSRs are in PMU range

On 08/08/2016 09:53 AM, Jan Beulich wrote: On 08.08.16 at 15:41, wrote: >> --- a/xen/arch/x86/traps.c >> +++ b/xen/arch/x86/traps.c >> @@ -2903,6 +2903,7 @@ static int emulate_privileged_op(struct cpu_user_regs >> *regs) >> { >>

Re: [Xen-devel] Proposed plan and URL name for new VM to download xen tarballs (ftp.xenproject.org)

Lars Kurth writes ("Re: Proposed plan and URL name for new VM to download xen tarballs (ftp.xenproject.org)"): > I don't mind. I can ask Credativ whether that is doable from a load > perspective. But the answer is probably yes. If it isn't doable then moving the release tarballs load elsewhere

Re: [Xen-devel] Proposed plan and URL name for new VM to download xen tarballs (ftp.xenproject.org)

> On 8 Aug 2016, at 14:51, Ian Jackson wrote: > > Lars Kurth writes ("Proposed plan and URL name for new VM to download xen > tarballs (ftp.xenproject.org)"): >> To fix this, the current plan of record is to >> - Copy existing tarballs to an existing or new VM >> -

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

>>> On 08.08.16 at 15:42, wrote: > On 05/08/16 16:35, Jan Beulich wrote: > On 04.08.16 at 17:49, wrote: >>> In general, the hooks provide flexibility when having to deal with >>> unforeseen cases, but their application should be rarely

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 15:41, wrote: > While AMD APM suggests that reserved MSR bits are not supposed to be > touched, it is not clear how (or whether) HW enforces this for PMU > registers. At least on some family 10h processors writes of these bits > are apparently

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

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 cause damage to other parts of dom0. ... > Ah, okay, I think I

Re: [Xen-devel] [PATCH 1/2] AMD/VPMU: 0xc0010000 - 0xc001007 MSRs are in PMU range

>>> On 08.08.16 at 15:41, wrote: > --- a/xen/arch/x86/traps.c > +++ b/xen/arch/x86/traps.c > @@ -2903,6 +2903,7 @@ static int emulate_privileged_op(struct cpu_user_regs > *regs) > { > vpmu_msr = 1; > case

Re: [Xen-devel] Proposed plan and URL name for new VM to download xen tarballs (ftp.xenproject.org)

Lars Kurth writes ("Proposed plan and URL name for new VM to download xen tarballs (ftp.xenproject.org)"): > To fix this, the current plan of record is to > - Copy existing tarballs to an existing or new VM > - To expose that VM via the new public URL ftp.xenproject.org (this is > non-browsable,

[Xen-devel] [libvirt test] 100331: regressions - trouble: blocked/broken/fail/pass

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

Re: [Xen-devel] PVH hypercall interface

On 08/08/2016 08:13 AM, Marek Marczykowski-Górecki wrote: > Thanks for the explanation. What is the current state of HVMlite? I see > "none" is valid value for "device_model_version" already, but if I try > to start such guest, it fails at x86_compat call (tries to boot it as PV > guest). I guess

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

On 05/08/16 16:35, Jan Beulich wrote: On 04.08.16 at 17:49, wrote: >> In general, the hooks provide flexibility when having to deal with >> unforeseen cases, but their application should be rarely required (< >> 10%)." > > But the greater flexibility of course comes

[Xen-devel] [PATCH 1/2] AMD/VPMU: 0xc0010000 - 0xc001007 MSRs are in PMU range

We need to check for older PMU MSR range when emulating MSR accesses for PV guests. Signed-off-by: Boris Ostrovsky --- xen/arch/x86/traps.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c index 767d0b0..79a3516 100644

[Xen-devel] [PATCH 0/2] AMD VPMU fixes

A couple of AMD VPMU fixes * Handle original (pre-family 15h) MSR range reserved for PMU use * Stop reporting error back to the guest when reserved PMU MSR bits are modified since apparently guests (Linux at least) may assume those bits to be zero. Just make sure those bits are set/cleared

  1   2   >