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

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

Re: [Xen-devel] [PATCH] xen: use a common function for pv and hvm guest backend register calls

On 02/08/16 20:27, Stefano Stabellini wrote: > On Tue, 2 Aug 2016, Juergen Gross wrote: >> Instead of calling xen_be_register() for each supported backend type >> for hvm and pv guests in their machine init functions use a common >> function in order not to have to add new backends twice. >> >>

[Xen-devel] [ovmf baseline-only test] 66892: trouble: blocked/broken/pass

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

Re: [Xen-devel] [PATCH v4] x86/cpuid: AVX-512 Feature Detection

> On 25/07/16 07:09, Kang, Luwei wrote: > First of all - please don't top post. > > > What about remove the dependency between AVX2 and AVX512F > >> ( AVX2: > [AVX512F], ) ? > > Yes, that's what I think we want, but we need Andrew's agreement here. > > >>> Hi

[Xen-devel] [PATCH] tools:libxl: return tty path for all serials

When specifying a serial list in domain config, users of libxl_console_get_tty cannot get the tty path of a second specified pty serial, since right now it always returns the tty path of serial 0. Signed-off-by: Bob Liu --- tools/libxl/libxl.c |2 +- 1 file changed, 1

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

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

[Xen-devel] [xen-4.6-testing baseline-only test] 66887: tolerable trouble: broken/fail/pass

This run is configured for baseline tests only. flight 66887 xen-4.6-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/66887/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemut-winxpsp3 3 host-install(3)

[Xen-devel] [ovmf baseline-only test] 66890: regressions - FAIL

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

[Xen-devel] [DRAFT v4] PV Calls protocol design document (former XenSock)

Hi all, This is the design document of the PV Calls protocol. You can find prototypes of the Linux frontend and backend drivers here: git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git pvcalls-4 To use them, make sure to enable CONFIG_PVCALLS in your kernel config and add

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

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

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

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

Re: [Xen-devel] [PATCH] arm/mem_access: properly handle traps caused by no-longer current settings

On Tue, Aug 2, 2016 at 4:05 PM, Julien Grall wrote: > > > On 02/08/2016 22:34, Tamas K Lengyel wrote: >> >> On Tue, Aug 2, 2016 at 2:02 PM, Julien Grall wrote: >>> >>> Hello Tamas, >>> >>> Thank you for taking care of this bug. >>> >>> On 02/08/2016

Re: [Xen-devel] [PATCH] arm/mem_access: properly handle traps caused by no-longer current settings

On 02/08/2016 22:34, Tamas K Lengyel wrote: On Tue, Aug 2, 2016 at 2:02 PM, Julien Grall wrote: Hello Tamas, Thank you for taking care of this bug. On 02/08/2016 19:53, Tamas K Lengyel wrote: When mem_access settings change, the active vCPUs may still cause a

Re: [Xen-devel] [PATCH] arm/mem_access: properly handle traps caused by no-longer current settings

On Tue, Aug 2, 2016 at 2:02 PM, Julien Grall wrote: > Hello Tamas, > > Thank you for taking care of this bug. > > On 02/08/2016 19:53, Tamas K Lengyel wrote: >> >> When mem_access settings change, the active vCPUs may still cause a >> violation >> until the TLB gets flushed.

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

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

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

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

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

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

[Xen-devel] [ovmf baseline-only test] 66888: trouble: blocked/broken/pass

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

Re: [Xen-devel] [PATCH] arm/mem_access: properly handle traps caused by no-longer current settings

Hello Tamas, Thank you for taking care of this bug. On 02/08/2016 19:53, Tamas K Lengyel wrote: When mem_access settings change, the active vCPUs may still cause a violation until the TLB gets flushed. Instead of just reinjecting the violation to the guest, in this patch we direct the vCPU to

Re: [Xen-devel] [PATCH v4 1/4] tools: remove systemd xenstore socket definitions

> On 2 Aug 2016, at 12:07, Wei Liu wrote: > > On Tue, Aug 02, 2016 at 12:39:25PM +0200, Juergen Gross wrote: >> On a system with systemd the xenstore sockets are created via systemd. >> Remove the related configuration files in order to be able to decide >> at runtime

Re: [Xen-devel] [PATCH 1/8] x86/time: improve cross-CPU clock monotonicity (and more)

On 15/06/16 11:26, Jan Beulich wrote: > Using the bare return value from read_platform_stime() is not suitable > when local_time_calibration() is going to use its fast path: Divergence > of several dozen microseconds between NOW() return values on different > CPUs results when platform and local

Re: [Xen-devel] [PATCH 4/8] x86/time: calibrate TSC against platform timer

On 20/06/16 16:19, Jan Beulich wrote: On 20.06.16 at 16:20, wrote: >> On 15/06/16 11:28, Jan Beulich wrote: >>> --- a/xen/arch/x86/i8259.c >>> +++ b/xen/arch/x86/i8259.c >>> @@ -359,12 +359,7 @@ void __init init_IRQ(void) >>> >>> apic_intr_init(); >>> >>>

Re: [Xen-devel] [PATCH 5/8] x86/time: correctly honor late clearing of TSC related feature flags

On 04/07/16 16:53, Jan Beulich wrote: On 04.07.16 at 17:39, wrote: >> On 20/06/16 16:20, Jan Beulich wrote: >> On 20.06.16 at 16:32, wrote: On 15/06/16 11:28, Jan Beulich wrote: > --- a/xen/arch/x86/time.c > +++

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

> > Can you try > > > > ((void *)(md) + (m)->desc_size - 1) < > > (m)->map_end; \ > > > > instead? with the 'baseline' as referenced + a patched kernel > Can you try >((void *)(md) + (m)->desc_size - 1) < (m)->map_end;

Re: [Xen-devel] live migrating hvm from 4.4 to 4.5 fails due to kvmvapic

On Tue, 2 Aug 2016, Olaf Hering wrote: > As a followup to the issue below, and the one which "just" popped in in > qemu-2.6+: > > Why is the machine description for xen not fixed? xenfv comes from a time when QEMU didn't have machine description versioning. To have versioning, it is possible to

[Xen-devel] [PATCH] arm/mem_access: properly handle traps caused by no-longer current settings

When mem_access settings change, the active vCPUs may still cause a violation until the TLB gets flushed. Instead of just reinjecting the violation to the guest, in this patch we direct the vCPU to retry the access where appropriate or we crash the domain where the mem_access settings are

Re: [Xen-devel] [PATCH 1/9] x86/hypercall: Move some of the hvm hypercall infrastructure into hypercall.h

On Tue, 2 Aug 2016, Jan Beulich wrote: > >>> On 02.08.16 at 16:59, wrote: > > On 02/08/16 15:54, Jan Beulich wrote: > > On 02.08.16 at 16:26, wrote: > >>> On 02/08/16 15:17, Jan Beulich wrote: > Well, I find it quite odd for hypercall

Re: [Xen-devel] [PATCH v7 09/15] hvmloader: Check modules whereabouts in perform_tests

On Thu, Jul 28, 2016 at 03:08:29PM +0100, Andrew Cooper wrote: > On 28/07/16 11:50, Anthony PERARD wrote: > > As perform_tests() is going to clear memory past 4MB, we check that the > > memory can be use or we skip the tests. > > > > Signed-off-by: Anthony PERARD > >

Re: [Xen-devel] [PATCH] xen: use a common function for pv and hvm guest backend register calls

On Tue, 2 Aug 2016, Gerd Hoffmann wrote: > On Di, 2016-08-02 at 08:32 +0200, Juergen Gross wrote: > > Instead of calling xen_be_register() for each supported backend type > > for hvm and pv guests in their machine init functions use a common > > function in order not to have to add new backends

Re: [Xen-devel] [PATCH] xen: use a common function for pv and hvm guest backend register calls

On Tue, 2 Aug 2016, Juergen Gross wrote: > Instead of calling xen_be_register() for each supported backend type > for hvm and pv guests in their machine init functions use a common > function in order not to have to add new backends twice. > > This at once fixes the error that hvm domains

Re: [Xen-devel] [PATCH v7 08/15] hvmloader: Locate the BIOS blob

On Thu, Jul 28, 2016 at 02:44:24PM +0100, Andrew Cooper wrote: > On 28/07/16 11:50, Anthony PERARD wrote: > > @@ -293,8 +340,17 @@ int main(void) > > } > > > > printf("Loading %s ...\n", bios->name); > > -if ( bios->bios_load ) > > -bios->bios_load(bios); > > +

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

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

Re: [Xen-devel] [PATCH] xen: use a common function for pv and hvm guest backend register calls

On Tue, Aug 02, 2016 at 08:32:32AM +0200, Juergen Gross wrote: > Instead of calling xen_be_register() for each supported backend type > for hvm and pv guests in their machine init functions use a common > function in order not to have to add new backends twice. > > This at once fixes the error

Re: [Xen-devel] [PATCH] systemd: remove hard-coded pid file in xendriverdomain service

Wei Liu: > On Tue, Aug 02, 2016 at 02:41:58PM +0100, Ian Jackson wrote: >> Wei Liu writes ("[PATCH] systemd: remove hard-coded pid file in >> xendriverdomain service"): >>> Per the discussion in [0], the hard-coded pid file can be removed >>> completely. Systemd has no trouble figuring out the

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

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

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

flight 99902 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/99902/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-xl 15 guest-start/debian.repeat fail in 99894 pass in 99902

Re: [Xen-devel] [PATCH] libxl: use llabs() instead abs() for int64_t argument

On 02/08/16 18:25, Juergen Gross wrote: > Commit 57f8b13c724023c78fa15a80452d1de3e51a1418 ("libxl: memory size > in kb requires 64 bit variable") introduced a bug: abs() shouldn't > be called with an int64_t argument. llabs() is to be used here. Possibly worth identifying that this was caught by

[Xen-devel] [PATCH] libxl: use llabs() instead abs() for int64_t argument

Commit 57f8b13c724023c78fa15a80452d1de3e51a1418 ("libxl: memory size in kb requires 64 bit variable") introduced a bug: abs() shouldn't be called with an int64_t argument. llabs() is to be used here. Signed-off-by: Juergen Gross --- tools/libxl/libxl.c | 2 +- 1 file changed, 1

Re: [Xen-devel] [PATCH v2 00/25] arm/altp2m: Introducing altp2m to ARM.

On Tue, Aug 2, 2016 at 10:40 AM, Julien Grall wrote: > > > On 02/08/16 17:05, George Dunlap wrote: >> >> On 02/08/16 16:48, Tamas K Lengyel wrote: >>> >>> On Tue, Aug 2, 2016 at 5:17 AM, George Dunlap >>> wrote: On 02/08/16 08:38, Julien

Re: [Xen-devel] [PATCH v2 00/25] arm/altp2m: Introducing altp2m to ARM.

On Tue, Aug 2, 2016 at 10:40 AM, Julien Grall wrote: > > > On 02/08/16 17:05, George Dunlap wrote: >> >> On 02/08/16 16:48, Tamas K Lengyel wrote: >>> >>> On Tue, Aug 2, 2016 at 5:17 AM, George Dunlap >>> wrote: On 02/08/16 08:38, Julien

Re: [Xen-devel] [PATCH v1 Altp2m cleanup 1/3] altp2m cleanup work

(Removing Paul, adding Lars) Ravi, I just got to this thread, and I was quite disappointed with both the code and the interaction here. In patch 1, the naming of the min/max is obviously inappropriate, and a.cmd is compared to HVMOP_cmd_max twice in a row. In patch 3, unused elements of the

Re: [Xen-devel] [PATCH v2 00/25] arm/altp2m: Introducing altp2m to ARM.

On 02/08/16 17:05, George Dunlap wrote: On 02/08/16 16:48, Tamas K Lengyel wrote: On Tue, Aug 2, 2016 at 5:17 AM, George Dunlap wrote: On 02/08/16 08:38, Julien Grall wrote: Hello Tamas, On 01/08/2016 21:41, Tamas K Lengyel wrote: On Mon, Aug 1, 2016 at 1:55 PM,

Re: [Xen-devel] [PATCH v1 Altp2m cleanup 1/3] altp2m cleanup work

On Thu, Jun 23, 2016 at 7:23 PM, Lai, Paul C wrote: > I'm opposed to moving HVMOP_cmd_min and HVMOP_cmd_max somewhere else. That > would make reading/understanding of the macros more difficult. This practice > is common. Also, If min & max are defined elsewhere, it will

Re: [Xen-devel] [PATCH v2] mem_access: sanitize code around sending vm_event request

On Tue, Aug 2, 2016 at 10:13 AM, Jan Beulich wrote: On 02.08.16 at 18:06, wrote: >> On Tue, Aug 2, 2016 at 9:23 AM, Tamas K Lengyel >> wrote: >>> On Aug 2, 2016 06:45, "Jan Beulich" wrote:

Re: [Xen-devel] [PATCH v2 00/25] arm/altp2m: Introducing altp2m to ARM.

On Tue, Aug 2, 2016 at 10:08 AM, Andrew Cooper wrote: > On 02/08/16 08:34, Julien Grall wrote: >> Hi Andrew, >> >> On 02/08/2016 00:14, Andrew Cooper wrote: >>> On 01/08/2016 19:15, Julien Grall wrote: On 01/08/16 18:10, Sergej Proskurin wrote: > > Hello

Re: [Xen-devel] [PATCH v2] mem_access: sanitize code around sending vm_event request

>>> On 02.08.16 at 18:06, wrote: > On Tue, Aug 2, 2016 at 9:23 AM, Tamas K Lengyel > wrote: >> On Aug 2, 2016 06:45, "Jan Beulich" wrote: >>> >>> On 01.08.16 at 18:52, wrote: >>> > +int

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

>>> On 02.08.16 at 17:04, wrote: > On Tue, Aug 2, 2016, at 07:50 AM, Jan Beulich wrote: >> - one with some suitable variant of reboot= > > What exactly is "some suitable variant of reboot" ? I can't really tell you which of the possible "reboot=" option values would work on

Re: [Xen-devel] [PATCH RFC 01/12] x86/paging: introduce paging_set_allocation

>>> On 02.08.16 at 17:49, wrote: > On Tue, Aug 02, 2016 at 11:47:22AM +0200, Roger Pau Monne wrote: >> On Fri, Jul 29, 2016 at 05:47:24PM +0100, Andrew Cooper wrote: >> > As this is for the construction of dom0, it would be better to take a >> > preemptible pointer, loop in

Re: [Xen-devel] [PATCH v2 00/25] arm/altp2m: Introducing altp2m to ARM.

On Tue, Aug 2, 2016 at 10:11 AM, Julien Grall wrote: > > > On 02/08/16 17:00, Tamas K Lengyel wrote: >> >> On Tue, Aug 2, 2016 at 1:38 AM, Julien Grall wrote: >> Hi Julien, >> as I said our use-case is purely external so I don't have an actual >>

Re: [Xen-devel] [PATCH v2 00/25] arm/altp2m: Introducing altp2m to ARM.

On 02/08/16 08:34, Julien Grall wrote: > Hi Andrew, > > On 02/08/2016 00:14, Andrew Cooper wrote: >> On 01/08/2016 19:15, Julien Grall wrote: >>> On 01/08/16 18:10, Sergej Proskurin wrote: Hello all, >>> >>> Hello Sergej, >>> The following patch series can be found on Github[0] and

Re: [Xen-devel] [PATCH v2 00/25] arm/altp2m: Introducing altp2m to ARM.

On 02/08/16 17:00, Tamas K Lengyel wrote: On Tue, Aug 2, 2016 at 1:38 AM, Julien Grall wrote: Hi Julien, as I said our use-case is purely external so I don't have an actual use-case for anything being accessible from within the guest. However, I could imagine the gfn

[Xen-devel] [PATCH v5 3/4] tools: use pidfile for test if xenstored is running

Instead of trying to read xenstore via xenstore-read use the pidfile of xenstored for the test whether xenstored is running. This prepares support of xenstore domain, as trying to read xenstore will block for ever in case xenstore domain is started after trying to read. Signed-off-by: Juergen

Re: [Xen-devel] [PATCH] libxl: create xenstore nodes for control/feature-XXX flags

On Mon, Aug 01, 2016 at 03:19:35PM +0100, Wei Liu wrote: > On Mon, Aug 01, 2016 at 09:57:10AM +0100, Paul Durrant wrote: > > The xenstore-paths documentation specifies various control/feature-XXX > > flags to allow a guest to tell a toolstack about its abilities to > > respond to values written to

Re: [Xen-devel] [PATCH v2 00/25] arm/altp2m: Introducing altp2m to ARM.

On Tue, Aug 2, 2016 at 10:05 AM, George Dunlap wrote: > On 02/08/16 16:48, Tamas K Lengyel wrote: >> On Tue, Aug 2, 2016 at 5:17 AM, George Dunlap >> wrote: >>> On 02/08/16 08:38, Julien Grall wrote: Hello Tamas, On 01/08/2016

[Xen-devel] [PATCH v5 0/4] tools: make xenstore domain/daemon configurable

Add a configuration option to /etc/sysconfig/xencommons to let the user configure whether he wants to start xenstore service as a daemon or as a stubdom. Changes in V5: - patch 2: undo &> to 2> conversion Changes in V4: - patch 1: remove sd_booted() test, undo unintended white space changes -

[Xen-devel] [PATCH v5 4/4] tools: make xenstore domain easy configurable

Add configuration entries to sysconfig.xencommons for selection of the xenstore type (domain or daemon) and start the selected xenstore service via a script called from sysvinit or systemd. Signed-off-by: Juergen Gross Acked-by: Wei Liu --- V3: - remove

[Xen-devel] [PATCH v5 2/4] tools: split out xenstored starting form xencommons

In order to prepare starting a xenstore domain split out the starting of the xenstore daemon from the xencommons script into a dedicated launch-xenstore script. A rerun of autogen.sh is required. Signed-off-by: Juergen Gross --- V5: undo &> to 2> conversion --- .gitignore

[Xen-devel] [PATCH v5 1/4] tools: remove systemd xenstore socket definitions

On a system with systemd the xenstore sockets are created via systemd. Remove the related configuration files in order to be able to decide at runtime whether the sockets should be created or not. This will enable Xen to start xenstore either via a daemon or via a stub domain. As the xenstore

Re: [Xen-devel] [PATCH v3] libxl: memory size in kb requires 64 bit variable

On Tue, Aug 02, 2016 at 10:49:24AM +0100, Wei Liu wrote: > On Thu, Jul 28, 2016 at 03:35:19PM +0200, Juergen Gross wrote: > > libxl_set_memory_target() and several other interface functions of > > libxl use a 32 bit sized parameter for a memory size value in kBytes. > > This limits the maximum

Re: [Xen-devel] [PATCH] docs: define semantics of vncpasswd in xl.cfg

On Mon, Aug 01, 2016 at 10:44:45AM +0100, Ian Jackson wrote: > Jim Fehlig writes ("[PATCH] docs: define semantics of vncpasswd in xl.cfg"): > > A recent discussion around LSN-2016-0001 [1] included defining > > the sematics of an empty string for a VNC password. It was stated > > that "libxl

Re: [Xen-devel] [PATCH v9] x86/mem-sharing: mem-sharing a range of memory

On Tue, Aug 02, 2016 at 01:17:01PM +0100, Wei Liu wrote: > On Mon, Aug 01, 2016 at 11:14:27AM -0600, Tamas K Lengyel wrote: > > Currently mem-sharing can be performed on a page-by-page basis from the > > control > > domain. However, this process is quite wasteful when a range of pages have > >

Re: [Xen-devel] [PATCH] libxl: fix printing hotplug arguments/environment

Pushed. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2] mem_access: sanitize code around sending vm_event request

On Tue, Aug 2, 2016 at 9:23 AM, Tamas K Lengyel wrote: > On Aug 2, 2016 06:45, "Jan Beulich" wrote: >> >> >>> On 01.08.16 at 18:52, wrote: >> > --- a/xen/arch/x86/hvm/hvm.c >> > +++ b/xen/arch/x86/hvm/hvm.c >> > @@

Re: [Xen-devel] [PATCH v2 00/25] arm/altp2m: Introducing altp2m to ARM.

On 02/08/16 16:48, Tamas K Lengyel wrote: > On Tue, Aug 2, 2016 at 5:17 AM, George Dunlap > wrote: >> On 02/08/16 08:38, Julien Grall wrote: >>> Hello Tamas, >>> >>> On 01/08/2016 21:41, Tamas K Lengyel wrote: On Mon, Aug 1, 2016 at 1:55 PM, Julien Grall

Re: [Xen-devel] [PATCH v2 00/25] arm/altp2m: Introducing altp2m to ARM.

On Tue, Aug 2, 2016 at 1:38 AM, Julien Grall wrote: > Hello Tamas, > > On 01/08/2016 21:41, Tamas K Lengyel wrote: >> >> On Mon, Aug 1, 2016 at 1:55 PM, Julien Grall wrote: we did discuss whether altp2m on ARM should be exposed to guests or

Re: [Xen-devel] monitor access to pages with a specific p2m_type_t

On Tue, Aug 2, 2016 at 12:19 AM, sepanta s wrote: > > > On Sat, Jul 23, 2016 at 3:49 PM, sepanta s wrote: > >> Hi, Is there any sample code which I can undestand how to capture the events on the gfns which have p2m_ram_shared enabled ?

Re: [Xen-devel] [PATCH RFC 01/12] x86/paging: introduce paging_set_allocation

On Tue, Aug 02, 2016 at 11:47:22AM +0200, Roger Pau Monne wrote: > On Fri, Jul 29, 2016 at 05:47:24PM +0100, Andrew Cooper wrote: > > On 29/07/16 17:28, Roger Pau Monne wrote: > > > diff --git a/xen/arch/x86/mm/paging.c b/xen/arch/x86/mm/paging.c > > > index 107fc8c..1b270df 100644 > > > ---

Re: [Xen-devel] [PATCH v2 00/25] arm/altp2m: Introducing altp2m to ARM.

On Tue, Aug 2, 2016 at 5:17 AM, George Dunlap wrote: > On 02/08/16 08:38, Julien Grall wrote: >> Hello Tamas, >> >> On 01/08/2016 21:41, Tamas K Lengyel wrote: >>> On Mon, Aug 1, 2016 at 1:55 PM, Julien Grall >>> wrote: > we did discuss whether

Re: [Xen-devel] What distros have Xen 4.7 packages that work on UEFI hardware?

> The level of support you get is somewhat proportional to the amount of money > you spend. I shared that comment here, and the immediate follow-on response was: "Great. Money's not the problem. Which commercial entity provides a supported solution?" We're happy to consider Oracle, Redhat,

Re: [Xen-devel] [PATCH v2 2/2] xen: drain submit queue in xen-usb before removing device

On Tue, Aug 02, 2016 at 02:14:04PM +0200, Juergen Gross wrote: > When unplugging a device in the Xen pvusb backend drain the submit > queue before deallocation of the control structures. Otherwise there > will be bogus memory accesses when I/O contracts are finished. > > Correlated to this issue

Re: [Xen-devel] [PATCH v2] mem_access: sanitize code around sending vm_event request

On Aug 2, 2016 06:45, "Jan Beulich" wrote: > > >>> On 01.08.16 at 18:52, wrote: > > --- a/xen/arch/x86/hvm/hvm.c > > +++ b/xen/arch/x86/hvm/hvm.c > > @@ -1707,7 +1707,7 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned long gla, > > int

Re: [Xen-devel] [PATCH v9] x86/mem-sharing: mem-sharing a range of memory

On Aug 2, 2016 06:17, "Wei Liu" wrote: > > On Mon, Aug 01, 2016 at 11:14:27AM -0600, Tamas K Lengyel wrote: > > Currently mem-sharing can be performed on a page-by-page basis from the control > > domain. However, this process is quite wasteful when a range of pages have to >

Re: [Xen-devel] Discussion about virtual iommu support for Xen guest

On 5/27/2016 4:19 PM, Lan Tianyu wrote: > As for the individual issue of 288vcpu support, there are already issues > with 64vcpu guests at the moment. While it is certainly fine to remove > the hard limit at 255 vcpus, there is a lot of other work required to > even get 128vcpu guests stable.

Re: [Xen-devel] [PATCH 1/9] x86/hypercall: Move some of the hvm hypercall infrastructure into hypercall.h

>>> On 02.08.16 at 16:59, wrote: > On 02/08/16 15:54, Jan Beulich wrote: > On 02.08.16 at 16:26, wrote: >>> On 02/08/16 15:17, Jan Beulich wrote: Well, I find it quite odd for hypercall argument counts to differ between arches. I.e.

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

On Tue, Aug 2, 2016, at 07:50 AM, Jan Beulich wrote: > - one with some suitable variant of reboot= What exactly is "some suitable variant of reboot" ? ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

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

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

Re: [Xen-devel] [PATCH 1/9] x86/hypercall: Move some of the hvm hypercall infrastructure into hypercall.h

On 02/08/16 15:54, Jan Beulich wrote: On 02.08.16 at 16:26, wrote: >> On 02/08/16 15:17, Jan Beulich wrote: >> On 02.08.16 at 16:04, wrote: On 02/08/16 14:28, Jan Beulich wrote: On 02.08.16 at 15:14,

Re: [Xen-devel] [PATCH 1/9] x86/hypercall: Move some of the hvm hypercall infrastructure into hypercall.h

>>> On 02.08.16 at 16:26, wrote: > > On 02/08/16 15:17, Jan Beulich wrote: > On 02.08.16 at 16:04, wrote: >>> On 02/08/16 14:28, Jan Beulich wrote: >>> On 02.08.16 at 15:14, wrote: > On 02/08/16 13:50, Jan

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

>>> On 02.08.16 at 16:25, wrote: > On Tue, Aug 2, 2016, at 07:13 AM, Jan Beulich wrote: >> Unless /mapbs really produces an _exactly_ identical crash, I'd like to >> see that boot's output at maximum log level. I don't recall "efi=no-rs" >> having been mentioned before on this

Re: [Xen-devel] [RFC Design Doc v2] Add vNVDIMM support for Xen

>>> On 18.07.16 at 02:29, wrote: > 4.2.2 Detection of Host pmem Devices > > The detection and initialize host pmem devices require a non-trivial > driver to interact with the corresponding ACPI namespace devices, > parse namespace labels and make necessary recovery

Re: [Xen-devel] live migrating hvm from 4.4 to 4.5 fails due to kvmvapic

As a followup to the issue below, and the one which "just" popped in in qemu-2.6+: Why is the machine description for xen not fixed? Shouldnt the be some sort of verification of old and new 'xenfv' when a new qemu rc1 is done? Is there a way to dump the machine description in text form? Olaf

[Xen-devel] [PATCH] xen/PCI: Update ACPI Check to include SGI Ux3

From: root These systems use variations of SGI3* for ID string. Instead of adding abother set of strings do what Linux did in commit 526018bc and look at first three letters. Signed-off-by: Boris Ostrovsky ---

Re: [Xen-devel] [PATCH 1/9] x86/hypercall: Move some of the hvm hypercall infrastructure into hypercall.h

On 02/08/16 15:17, Jan Beulich wrote: On 02.08.16 at 16:04, wrote: On 02/08/16 14:28, Jan Beulich wrote: On 02.08.16 at 15:14, wrote: On 02/08/16 13:50, Jan Beulich wrote: On 18.07.16 at 11:51, wrote: ---

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

On Tue, Aug 2, 2016, at 07:13 AM, Jan Beulich wrote: > > You keep stating what you don't see. > > Because you keep being vague... I have attempted to provide everything that's been asked of me. If you don't like it that's fine. State with specificity what it is you want. > Unless /mapbs

Re: [Xen-devel] [PATCH] xen/kconfig: unify messages of options moved from command line to kconfig

>>> On 02.08.16 at 15:58, wrote: > On Mon, Aug 01, 2016 at 09:21:28AM -0600, Jan Beulich wrote: >> >>> On 26.07.16 at 17:45, wrote: >> > Change the message so that it mentions running from the top level directory >> > and using '-C xen' in order to

Re: [Xen-devel] [PATCH 4/9] x86/pv: Implement pv_hypercall() in C

>>> On 02.08.16 at 16:06, wrote: > On 02/08/16 14:12, Jan Beulich wrote: > On 18.07.16 at 11:51, wrote: >>> +long pv_hypercall(struct cpu_user_regs *regs) >>> +{ >>> +struct vcpu *curr = current; >>> +#ifndef NDEBUG >>> +unsigned

Re: [Xen-devel] [PATCH v3] xen: Make VPMU init message look less scary

On 08/02/2016 03:22 AM, Juergen Gross wrote: The default for the Xen hypervisor is to not enable VPMU in order to avoid security issues. In this case the Linux kernel will issue the message "Could not initialize VPMU for cpu 0, error -95" which looks more like an error than a normal state.

Re: [Xen-devel] [PATCH v4 2/4] tools: split out xenstored starting form xencommons

On Tue, Aug 02, 2016 at 02:48:54PM +0100, Ian Jackson wrote: > Wei Liu writes ("Re: [PATCH v4 2/4] tools: split out xenstored starting form > xencommons"): > > On Tue, Aug 02, 2016 at 01:20:40PM +0200, Juergen Gross wrote: > > > Still confused? > > > > Ah, the 2> vs &> thing is really subtle. I

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

>>> On 02.08.16 at 15:54, wrote: > > On Tue, Aug 2, 2016, at 06:38 AM, Jan Beulich wrote: >> Well, without going through the _full_ thread again, what I could >> easily find is >> >> "So full console output from boot -> crash now doesn't look any different >> than > >>

Re: [Xen-devel] [PATCH v2] xen: rename xen_pmu_init() in sys-hypervisor.c

On 08/02/2016 02:53 AM, Juergen Gross wrote: There are two functions with name xen_pmu_init() in the kernel. Rename the one in drivers/xen/sys-hypervisor.c to avoid shadowing the one in arch/x86/xen/pmu.c To avoid the same problem in future rename some more functions. Signed-off-by: Juergen

Re: [Xen-devel] [PATCH v2 23/25] arm/altp2m: Extend libxl to activate altp2m on ARM.

Hi Wei, On 08/02/2016 01:59 PM, Wei Liu wrote: > On Mon, Aug 01, 2016 at 07:10:26PM +0200, Sergej Proskurin wrote: >> The current implementation allows to set the parameter HVM_PARAM_ALTP2M. >> This parameter allows further usage of altp2m on ARM. For this, we >> define an additional, common

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

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' operation, first, the qemu device invokes the read operation on local buffers and on

[Xen-devel] Publishing livepatch instructions for XSAs from livepatch wiki

Hey, My goal for Xen 4.8 is to get OSSTest to regularly test livepatch mechanism. I am struggling with OSSTest but I am sure I will figure it out. But in the meantime I was wondering what the community feels about publishing step-by-step instructions on how to use livepatching for XSAs. When

[Xen-devel] [PATCH v4 0/2] qemu-qdisk: Implementation of grant copy operation.

Hi, It is a proposition for implementation of grant copy operation in qemu-qdisk and interface in libxc/libs. Changes since v3: Interface: - revert to cast from xengnttab_grant_copy_segment_t to ioctl_gntdev_grant_copy. - added compile-time check to compare the libs

Re: [Xen-devel] [PATCH 4/9] x86/pv: Implement pv_hypercall() in C

On 02/08/16 14:12, Jan Beulich wrote: On 18.07.16 at 11:51, wrote: >> +long pv_hypercall(struct cpu_user_regs *regs) >> +{ >> +struct vcpu *curr = current; >> +#ifndef NDEBUG >> +unsigned long old_rip = regs->rip; >> +#endif >> +long ret; >> +

[Xen-devel] [PATCH v4 1/2] Interface for grant copy operation in libs.

In a linux part an ioctl(gntdev, IOCTL_GNTDEV_GRANT_COPY, ..) system call is invoked. In mini-os the operation is yet not implemented. For the OSs that does not implement gnttab the call of the grant copy operation causes abort. Signed-off-by: Paulina Szubarczyk ---

Re: [Xen-devel] [PATCH 1/9] x86/hypercall: Move some of the hvm hypercall infrastructure into hypercall.h

Hi Jan, On 02/08/16 14:28, Jan Beulich wrote: On 02.08.16 at 15:14, wrote: On 02/08/16 13:50, Jan Beulich wrote: On 18.07.16 at 11:51, wrote: --- a/xen/include/asm-x86/hypercall.h +++ b/xen/include/asm-x86/hypercall.h @@ -5,9 +5,21 @@

Re: [Xen-devel] [PATCH] xen/kconfig: unify messages of options moved from command line to kconfig

On Mon, Aug 01, 2016 at 09:21:28AM -0600, Jan Beulich wrote: > >>> On 26.07.16 at 17:45, wrote: > > Change the message so that it mentions running from the top level directory > > and using '-C xen' in order to call the 'menuconfig' target inside of the > > xen directory

Re: [Xen-devel] [PATCH] systemd: remove hard-coded pid file in xendriverdomain service

On Tue, Aug 02, 2016 at 02:41:58PM +0100, Ian Jackson wrote: > Wei Liu writes ("[PATCH] systemd: remove hard-coded pid file in > xendriverdomain service"): > > Per the discussion in [0], the hard-coded pid file can be removed > > completely. Systemd has no trouble figuring out the pid of devd all

[Xen-devel] [PATCH v2] x86/hap: use the right cache attributes when MTRR is disabled

Currently the code that calculates the cache attributes of the HAP page tables assume that if MTRR are disabled the memory type is UC, this can cause issues if MTRR are never enabled because the guest only plans to use PAT. In order to solve this modify epte_get_entry_emt so that is takes into

  1   2   3   >