[Xen-devel] [qemu-mainline baseline-only test] 44397: regressions - FAIL

- commit 53db932604dfa7bb9241d132e0173894cf54261c Merge: 975eb6a fd3c136 Author: Peter Maydell <peter.mayd...@linaro.org> Date: Mon May 9 13:42:25 2016 +0100 Merge remote-tracking branch 'remotes/kraxel/tags/pull-vga-20160509-1' into staging vga security fixes (CVE-2016-3710, CVE-2016-37

Re: [Xen-devel] Xen 4.7 Test Day Instructions for RC2+ : Call to action for people who added new features / functionality to Xen 4.7

On 10/05/16 04:18, Dario Faggioli wrote: > [removing Vitaly, adding Juergen] > > On Mon, 2016-05-09 at 17:55 +0100, Lars Kurth wrote: >> >>> On 9 May 2016, at 17:03, George Dunlap >>> wrote: >>> On Mon, May 9, 2016 at 4:28 PM, Lars Kurth >>>

Re: [Xen-devel] [PATCH v4 02/10] IOMMU: handle IOMMU mapping and unmapping failures

On May 10, 2016 12:14 AM, Jan Beulich wrote: > >>> On 06.05.16 at 10:54, wrote: > > --- a/xen/drivers/passthrough/iommu.c > > +++ b/xen/drivers/passthrough/iommu.c > > @@ -240,21 +240,47 @@ int iommu_map_page(struct domain *d, > unsigned long gfn, unsigned

Re: [Xen-devel] Xen 4.7 Test Day Instructions for RC2+ : Call to action for people who added new features / functionality to Xen 4.7

On 5/9/16 10:28 AM, Lars Kurth wrote: > Hi all, > > I added the following sections based on git logs to man pages. Authors are on > the CC list and should review and modify (or suggest edits by replying to > this thread). I added/updated/added TODO's to: > > I do have some questions, to ... >

Re: [Xen-devel] Xen 4.7 Test Day Instructions for RC2+ : Call to action for people who added new features / functionality to Xen 4.7

>>> On 5/9/2016 at 11:28 PM, in message <6db04875-03d4-4542-b06c-2b0412d08...@gmail.com>, Lars Kurth wrote: > Hi all, > > I added the following sections based on git logs to man pages. Authors are > on the CC list and should review and modify (or suggest edits by

Re: [Xen-devel] Xen 4.7 Test Day Instructions for RC2+ : Call to action for people who added new features / functionality to Xen 4.7

[removing Vitaly, adding Juergen] On Mon, 2016-05-09 at 17:55 +0100, Lars Kurth wrote: >  > > On 9 May 2016, at 17:03, George Dunlap > > wrote: > > On Mon, May 9, 2016 at 4:28 PM, Lars Kurth > > wrote: > > >  > > > - George: are there any

[Xen-devel] [qemu-upstream-unstable test] 93919: regressions - FAIL

flight 93919 qemu-upstream-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/93919/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. vs. 92434

[Xen-devel] [ovmf test] 93918: regressions - FAIL

flight 93918 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/93918/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm5 xen-build fail REGR. vs. 65543

Re: [Xen-devel] Xen 4.7 Test Day Instructions for RC2+ : Call to action for people who added new features / functionality to Xen 4.7

On 2016/5/10 0:17, Julien Grall wrote: > (CC Shannon, Stefano and Steve) > > Hi Lars, > > On 09/05/16 16:28, Lars Kurth wrote: >> Hi all, >> >> I added the following sections based on git logs to man pages. Authors >> are on the CC list and should review and modify (or suggest edits by >>

Re: [Xen-devel] [PATCH 0/3] libxl: support Xen migration stream V2

On 05/03/2016 07:19 AM, Wei Liu wrote: > On Mon, May 02, 2016 at 07:01:16PM -0600, Jim Fehlig wrote: >> Hi all, >> >> This patch adds support for Xen migration stream V2 to the libvirt >> libxl driver. In the process it fixes save/restore and migration >> tests in OSSTest, which have been failing

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

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

Re: [Xen-devel] [PATCH] tools: Restrict configuration of qemu processes

On 05/09/2016 10:35 AM, Ian Jackson wrote: > Ian Jackson writes ("Re: [Xen-devel] [PATCH] tools: Restrict configuration of > qemu processes"): >> Jim Fehlig writes ("[Xen-devel] [PATCH] tools: Restrict configuration of >> qemu processes"): >>> Commit 6ef823fd added '-nodefaults' to the qemu args

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

flight 93903 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/93903/ 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.

Re: [Xen-devel] [PATCH RFC 00/20] Make ACPI builder available to components other than hvmloader

On 04/05/2016 09:25 PM, Boris Ostrovsky wrote: > This is an RFC for making hvmloader's ACPI builder available to both the > toolstack and the hypervisor, as discussed in > http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg01228.html When do people think they will get a chance to

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

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

Re: [Xen-devel] [PATCH v2 for-4.7 4/5] x86/svm: Don't unconditionally use a new ASID in svm_invlpg_intercept()

On 05/09/2016 02:27 PM, Andrew Cooper wrote: > paging_invlpg() already returns a boolean indicating whether an invalidation > is necessary or not. A return value of 0 indicates that the specified virtual > address wasn't shadowed (or has already been flushed), cannot currently be > cached in the

Re: [Xen-devel] [PATCH v2 for-4.7 5/5] x86/hvm: Fix invalidation for emulated invlpg instructions

On 05/09/2016 02:27 PM, Andrew Cooper wrote: > hap_invlpg() is reachable from the instruction emulator, which means > introspection and tests using hvm_fep can end up here. As such, crashing the > domain is not an appropriate action to take. > > Fixing this involves rearranging the callgraph. > >

Re: [Xen-devel] [PATCH for-qemu-trad] Fix build with newer version of GNUTLS

On Thu, May 05, 2016 at 11:14:44AM +0100, Wei Liu wrote: > gnutls_kx_set_priority, gnutls_certificate_type_set_priority and > gnutls_protocol_set_priority were deprecated and eventually removed in > GNUTLS 3.4. Application should use gnutls_priority_set_direct instead > per [0]. > >

Re: [Xen-devel] crash on boot with 4.6.1 on fedora 24

On 05/09/2016 01:22 PM, Kevin Moraga wrote: > > On 05/09/2016 11:15 AM, Boris Ostrovsky wrote: >> On 05/09/2016 12:40 PM, Kevin Moraga wrote: >>> On 05/09/2016 09:53 AM, Jan Beulich wrote: >>> On 09.05.16 at 16:52, wrote: > On 05/09/2016 04:08 AM, Jan Beulich wrote:

[Xen-devel] [PATCH v2 for-4.7 2/5] x86/hvm: Raise #SS faults for %ss-based segmentation violations

Raising #GP under such circumstances is architecturally wrong. (Refer to the Intel or AMD manuals describing the conditions under which the Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Acked-by: Tim Deegan --- CC: Paul

[Xen-devel] [PATCH v2 for-4.7 1/5] x86/hvm: Always return the linear address from hvm_virtual_to_linear_addr()

Some callers need the linear address (with appropriate segment base), whether or not the limit or canonical check succeeds. While modifying the function, change the return type to bool_t to match its semantics. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich

[Xen-devel] [PATCH v2 for-4.7 3/5] x86/hvm: Correct the emulated interaction of invlpg with segments

The `invlpg` instruction is documented to take a memory address, and is not documented to suffer faults from segmentation violations. It is also explicitly documented to be a NOP when issued on a non-canonical address. Experimentally, and subsequently confirmed by both Intel and AMD, the

[Xen-devel] [PATCH v2 for-4.7 0/5] Fixes for invlpg handling for HVM guests

Turns out there are a lot of broken corner cases. Changes in v2: * Some improvements to commit messages * Split part of the original patch 4 out, to make the new patch 5 clearer * Add vcpu parameter to new invlpg() function, and avoid assuming 'current' * Modify paging_invlpg() to be void,

[Xen-devel] [PATCH v2 for-4.7 5/5] x86/hvm: Fix invalidation for emulated invlpg instructions

hap_invlpg() is reachable from the instruction emulator, which means introspection and tests using hvm_fep can end up here. As such, crashing the domain is not an appropriate action to take. Fixing this involves rearranging the callgraph. paging_invlpg() is now the central entry point. It

[Xen-devel] [PATCH v2 for-4.7 4/5] x86/svm: Don't unconditionally use a new ASID in svm_invlpg_intercept()

paging_invlpg() already returns a boolean indicating whether an invalidation is necessary or not. A return value of 0 indicates that the specified virtual address wasn't shadowed (or has already been flushed), cannot currently be cached in the TLB. This is a performance optimisation.

[Xen-devel] ARM bare metal application test

Hello, > I don't think toolstack tries to load kernel to that guest physical > address -- reading from Ivan's log it suggests toolstack loaded the > kernel to 0x40008000. > That (0x8000800) is the address set in PC, right? I don't think > toolstack is in a position to sanitise that nor should

Re: [Xen-devel] dumping Xen stack

> -Original Message- > From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Monday, May 09, 2016 1:14 PM > To: Zytaruk, Kelly; xen-devel@lists.xen.org > Subject: Re: [Xen-devel] dumping Xen stack > > On 09/05/16 18:11, Zytaruk, Kelly wrote: > > > >> -Original Message-

Re: [Xen-devel] ARM bare metal application test

On 09/05/16 18:39, Wei Liu wrote: On Mon, May 09, 2016 at 05:47:38PM +0100, Julien Grall wrote: On 09/05/16 17:43, Ivan Pavić2 wrote: Hello Julien, Hello Ivan, Julien Grall wrote: Guest are booting with MMU disabled, so 0x80008000 will be the physical address. The toolstack will

Re: [Xen-devel] Xen 4.7 Test Day Instructions for RC2+ : Call to action for people who added new features / functionality to Xen 4.7

> On 9 May 2016, at 18:37, Konrad Rzeszutek Wilk wrote: > > On Mon, May 09, 2016 at 04:28:52PM +0100, Lars Kurth wrote: >> Hi all, >> >> I added the following sections based on git logs to man pages. Authors are >> on the CC list and should review and modify (or

Re: [Xen-devel] ARM bare metal application test

On Mon, May 09, 2016 at 05:47:38PM +0100, Julien Grall wrote: > > > On 09/05/16 17:43, Ivan Pavić2 wrote: > >Hello Julien, > > Hello Ivan, > > > > >Julien Grall wrote: > >>Guest are booting with MMU disabled, so 0x80008000 will be the physical > >>address. > > > >>The toolstack will load the

Re: [Xen-devel] Xen 4.7 Test Day Instructions for RC2+ : Call to action for people who added new features / functionality to Xen 4.7

On Mon, May 09, 2016 at 04:28:52PM +0100, Lars Kurth wrote: > Hi all, > > I added the following sections based on git logs to man pages. Authors are on > the CC list and should review and modify (or suggest edits by replying to > this thread). I added/updated/added TODO's to: > > I do have

Re: [Xen-devel] crash on boot with 4.6.1 on fedora 24

On 05/09/2016 11:15 AM, Boris Ostrovsky wrote: > On 05/09/2016 12:40 PM, Kevin Moraga wrote: >> On 05/09/2016 09:53 AM, Jan Beulich wrote: >> On 09.05.16 at 16:52, wrote: On 05/09/2016 04:08 AM, Jan Beulich wrote: On 09.05.16 at 00:51,

Re: [Xen-devel] crash on boot with 4.6.1 on fedora 24

On 05/09/2016 12:40 PM, Kevin Moraga wrote: > > On 05/09/2016 09:53 AM, Jan Beulich wrote: > On 09.05.16 at 16:52, wrote: >>> On 05/09/2016 04:08 AM, Jan Beulich wrote: >>> On 09.05.16 at 00:51, wrote: > I'm try to compile kernel 4.4.8 (using

Re: [Xen-devel] Xen 4.7 Test Day Instructions for RC2+ : Call to action for people who added new features / functionality to Xen 4.7

On Mon, May 9, 2016 at 11:28 AM, Lars Kurth wrote: > Hi all, > > I added the following sections based on git logs to man pages. Authors are on > the CC list and should review and modify (or suggest edits by replying to > this thread). I added/updated/added TODO's to: >

Re: [Xen-devel] dumping Xen stack

On 09/05/16 18:11, Zytaruk, Kelly wrote: > >> -Original Message- >> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] >> Sent: Monday, May 09, 2016 12:40 PM >> To: Zytaruk, Kelly; xen-devel@lists.xen.org >> Subject: Re: [Xen-devel] dumping Xen stack >> >> On 09/05/16 17:37, Zytaruk,

Re: [Xen-devel] Xen 4.7 Test Day Instructions for RC2+ : Call to action for people who added new features / functionality to Xen 4.7

On 09/05/16 17:56, Lars Kurth wrote: On 9 May 2016, at 17:17, Julien Grall wrote: (CC Shannon, Stefano and Steve) Hi Lars, On 09/05/16 16:28, Lars Kurth wrote: Hi all, I added the following sections based on git logs to man pages. Authors are on the CC list and

Re: [Xen-devel] dumping Xen stack

> -Original Message- > From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Monday, May 09, 2016 12:40 PM > To: Zytaruk, Kelly; xen-devel@lists.xen.org > Subject: Re: [Xen-devel] dumping Xen stack > > On 09/05/16 17:37, Zytaruk, Kelly wrote: > > Does Xen have an equivalent

Re: [Xen-devel] [PATCH v6 1/6] libxl: handle error from libxl__need_xenpv_qemu() correctly

Ian Jackson writes ("Re: [PATCH v6 1/6] libxl: handle error from libxl__need_xenpv_qemu() correctly"): > Wei Liu writes ("Re: [PATCH v6 1/6] libxl: handle error from > libxl__need_xenpv_qemu() correctly"): > > On Thu, Mar 31, 2016 at 07:49:01AM +0200, Juergen Gross wrote: > > > In case

Re: [Xen-devel] [PATCH v3 for-4.7 07/16] libxc: fix usage of uninitialized variable

Ian Jackson writes ("Re: [PATCH v3 for-4.7 07/16] libxc: fix usage of uninitialized variable"): > Wei Liu writes ("Re: [PATCH v3 for-4.7 07/16] libxc: fix usage of > uninitialized variable"): > > Ian, this is a backport candidate. > > Noted, thanks. Backported to 4.6 and 4.5. Ian.

Re: [Xen-devel] [PATCH] tools: handle xl migrate --debug in legacy stream

Ian Jackson writes ("Re: [PATCH] tools: handle xl migrate --debug in legacy stream"): > Andrew Cooper writes ("Re: [PATCH] tools: handle xl migrate --debug in legacy > stream"): > > Ian: This is also a backport candidate for 4.6 > > Queued for backport. Pushed to 4.6. Ian.

[Xen-devel] ARM bare metal application test

Hello Julien, Julien Grall wrote: > Guest are booting with MMU disabled, so 0x80008000 will be the physical > address. > The toolstack will load the kernel at this physical address. However, > the start of the guest RAM for Xen 4.7 is 0x4000 (see > include/public/arch-arm.h). Can you try to

Re: [Xen-devel] Xen 4.7 Test Day Instructions for RC2+ : Call to action for people who added new features / functionality to Xen 4.7

> On 9 May 2016, at 17:17, Julien Grall wrote: > > (CC Shannon, Stefano and Steve) > > Hi Lars, > > On 09/05/16 16:28, Lars Kurth wrote: >> Hi all, >> >> I added the following sections based on git logs to man pages. Authors are >> on the CC list and should review and

[Xen-devel] [PATCH] tools: configure correct trace backend for QEMU

Newer versions of the QEMU source have replaced the 'stderr' trace backend with 'log'. This patch adjusts the tools Makefile to test for the 'log' backend and specify it if it is available. Signed-off-by: Paul Durrant --- Cc: Ian Jackson Cc:

[Xen-devel] Odgovor: ARM bare metal application test

Hello, > Correct, so the end of the RAM bank would be 0x4200. I am a bit > surprised that the toolstack does not complain when trying to load the > kernel at 0x80008000. > Can you paste the dump of xl -vvv create... ? $ xl -vvv create dom.cfg Parsing config from dom.cfg libxl: debug:

Re: [Xen-devel] Xen 4.7 Test Day Instructions for RC2+ : Call to action for people who added new features / functionality to Xen 4.7

Reduced CC list > On 9 May 2016, at 17:03, George Dunlap wrote: > > On Mon, May 9, 2016 at 4:28 PM, Lars Kurth wrote: >> Hi all, >> >> I added the following sections based on git logs to man pages. Authors are >> on the CC list and should

[Xen-devel] [Vote] Minor change to governance document at http://www.xenproject.org/developers/governance.html (Vote before May 16th)

Hi all, as per the RFC at http://lists.xenproject.org/archives/html/xen-devel/2016-04/msg03191.html which received no concrete feedback other than it looks good, I want to call a formal vote on this proposal. As the proposal affects all subprojects, committers from the Hypervisor and XAPI

Re: [Xen-devel] ARM bare metal application test

On 09/05/16 17:43, Ivan Pavić2 wrote: Hello Julien, Hello Ivan, Julien Grall wrote: Guest are booting with MMU disabled, so 0x80008000 will be the physical address. The toolstack will load the kernel at this physical address. However, the start of the guest RAM for Xen 4.7 is

Re: [Xen-devel] [PATCH v2] xen-hvm: ignore background I/O sections

> -Original Message- > From: Paul Durrant [mailto:paul.durr...@citrix.com] > Sent: 09 May 2016 17:29 > To: qemu-de...@nongnu.org; xen-de...@lists.xenproject.org > Cc: Paul Durrant; Stefano Stabellini; Anthony Perard; Paolo Bonzini > Subject: [PATCH v2] xen-hvm: ignore background I/O

[Xen-devel] [PATCH v3] xen-hvm: ignore background I/O sections

Since Xen will correctly handle accesses to unimplemented I/O ports (by returning all 1's for reads and ignoring writes) there is no need for QEMU to register backgroud I/O sections. This patch therefore adds checks to xen_io_add/del so that sections with memory-region ops pointing at

[Xen-devel] [PATCH v2] xen-hvm: ignore background I/O sections

Since Xen will correctly handle accesses to unimplemented I/O ports (by returning all 1's for reads and ignoring writes) there is no need for QEMU to register backgroud I/O sections. This patch therefore adds checks to xen_io_add/del so that sections with memory-region ops pointing at

Re: [Xen-devel] [PATCH] xen-hvm: ignore background I/O sections

> -Original Message- > From: Paolo Bonzini [mailto:pbonz...@redhat.com] > Sent: 09 May 2016 17:39 > To: Paul Durrant; qemu-de...@nongnu.org; xen-de...@lists.xenproject.org > Cc: Stefano Stabellini; Anthony Perard > Subject: Re: [PATCH] xen-hvm: ignore background I/O sections > > > > On

Re: [Xen-devel] crash on boot with 4.6.1 on fedora 24

On 05/09/2016 09:53 AM, Jan Beulich wrote: On 09.05.16 at 16:52, wrote: >> On 05/09/2016 04:08 AM, Jan Beulich wrote: >> On 09.05.16 at 00:51, wrote: I'm try to compile kernel 4.4.8 (using fedora 23) to run with Xen 4.6.0 and Intel

Re: [Xen-devel] dumping Xen stack

On 09/05/16 17:37, Zytaruk, Kelly wrote: > Does Xen have an equivalent function to the Linux dump_stack() function? > > I am hitting a panic followed by a reboot and would like to find out where I > am coming from. At the point of a crash, the stack should be printed on the console.

Re: [Xen-devel] [PATCH] xen-hvm: ignore background I/O sections

On 09/05/2016 18:18, Paul Durrant wrote: > Since Xen will correctly handle accesses to unimplemented I/O ports (by > returning all 1's for reads and ignoring writes) there is no need for > QEMU to register backgroud I/O sections. > > This patch therefore adds checks to xen_io_add/del so that

[Xen-devel] dumping Xen stack

Does Xen have an equivalent function to the Linux dump_stack() function? I am hitting a panic followed by a reboot and would like to find out where I am coming from. Thanks, Kelly ___ Xen-devel mailing list Xen-devel@lists.xen.org

Re: [Xen-devel] [PATCH] tools: Restrict configuration of qemu processes

Ian Jackson writes ("Re: [Xen-devel] [PATCH] tools: Restrict configuration of qemu processes"): > Jim Fehlig writes ("[Xen-devel] [PATCH] tools: Restrict configuration of qemu > processes"): > > Commit 6ef823fd added '-nodefaults' to the qemu args created by > > libxl, which is a good step in

[Xen-devel] [PATCH] xen-hvm: ignore background I/O sections

Since Xen will correctly handle accesses to unimplemented I/O ports (by returning all 1's for reads and ignoring writes) there is no need for QEMU to register backgroud I/O sections. This patch therefore adds checks to xen_io_add/del so that sections with memory-region ops pointing at

Re: [Xen-devel] ARM bare metal application test

Hello Ivan, On 09/05/16 11:29, Ivan Pavić2 wrote: Julien Grail wrote: You can dump the registers of a vCPU with xenctx. $PREFIX/lib/xen/bin/xenctx domid $PREFIX is the path where xen tools have been installed (i.e --prefix on the configure). The default path is /usr/local/ Thanks for

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

flight 93911 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/93911/ 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] Odgovor: ARM bare metal application test

Konrad Rzeszutek Wilk wrote: > OK, but that makes an ELF file. I believe (based on the Booting) you need to > extract > the binary code out and also fixup the branch instructions (maybe make > __Start = 0;?). > The Booting says: > - The boot loader is expected to call the kernel image by

Re: [Xen-devel] [PATCH v4 02/10] IOMMU: handle IOMMU mapping and unmapping failures

>>> On 06.05.16 at 10:54, wrote: > --- a/xen/drivers/passthrough/iommu.c > +++ b/xen/drivers/passthrough/iommu.c > @@ -240,21 +240,47 @@ int iommu_map_page(struct domain *d, unsigned long gfn, > unsigned long mfn, > unsigned int flags) > { > const

Re: [Xen-devel] Overlaped PIO with multiple ioreq_server (Xen4.6.1)

> -Original Message- > From: Paul Durrant > Sent: 09 May 2016 17:02 > To: Paul Durrant; Paolo Bonzini; Martin Cerveny > Cc: xen-de...@lists.xensource.com; George Dunlap > Subject: RE: [Xen-devel] Overlaped PIO with multiple ioreq_server > (Xen4.6.1) > > > -Original Message- > >

Re: [Xen-devel] Ping: [PATCH] XSA-77: widen scope again

On 06/05/16 09:12, Jan Beulich wrote: On 29.04.16 at 11:35, wrote: >> As discussed on the hackathon, avoid us having to issue security >> advisories for issues affecting only heavily disaggregated tool stack >> setups, which no-one appears to use (or else they should step

Re: [Xen-devel] Overlaped PIO with multiple ioreq_server (Xen4.6.1)

> -Original Message- > From: Paolo Bonzini [mailto:pbonz...@redhat.com] > Sent: 09 May 2016 17:18 > To: Paul Durrant; Martin Cerveny > Cc: xen-de...@lists.xensource.com; George Dunlap > Subject: Re: [Xen-devel] Overlaped PIO with multiple ioreq_server > (Xen4.6.1) > > > > On 09/05/2016

Re: [Xen-devel] Overlaped PIO with multiple ioreq_server (Xen4.6.1)

On 09/05/2016 18:14, Paul Durrant wrote: >> -Original Message- >> From: Paul Durrant >> Sent: 09 May 2016 17:02 >> To: Paul Durrant; Paolo Bonzini; Martin Cerveny >> Cc: xen-de...@lists.xensource.com; George Dunlap >> Subject: RE: [Xen-devel] Overlaped PIO with multiple ioreq_server >>

Re: [Xen-devel] Xen 4.7 Test Day Instructions for RC2+ : Call to action for people who added new features / functionality to Xen 4.7

(CC Shannon, Stefano and Steve) Hi Lars, On 09/05/16 16:28, Lars Kurth wrote: Hi all, I added the following sections based on git logs to man pages. Authors are on the CC list and should review and modify (or suggest edits by replying to this thread). I added/updated/added TODO's to: I do

Re: [Xen-devel] [PATCH v4 01/10] vt-d: fix the IOMMU flush issue

>>> On 06.05.16 at 10:54, wrote: > -static void intel_iommu_iotlb_flush(struct domain *d, unsigned long gfn, > unsigned int page_count) > +static void iommu_flush_iotlb_page(struct domain *d, unsigned long gfn, > + unsigned int page_count)

Re: [Xen-devel] Xen 4.7 Test Day Instructions for RC2+ : Call to action for people who added new features / functionality to Xen 4.7

On Mon, May 9, 2016 at 4:28 PM, Lars Kurth wrote: > Hi all, > > I added the following sections based on git logs to man pages. Authors are on > the CC list and should review and modify (or suggest edits by replying to > this thread). I added/updated/added TODO's to: >

Re: [Xen-devel] Overlaped PIO with multiple ioreq_server (Xen4.6.1)

> -Original Message- > From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of > Paul Durrant > Sent: 09 May 2016 14:00 > To: Paolo Bonzini; Martin Cerveny > Cc: xen-de...@lists.xensource.com; George Dunlap > Subject: Re: [Xen-devel] Overlaped PIO with multiple ioreq_server >

Re: [Xen-devel] crash on boot with 4.6.1 on fedora 24

>>> On 09.05.16 at 16:52, wrote: > On 05/09/2016 04:08 AM, Jan Beulich wrote: > On 09.05.16 at 00:51, wrote: >>> I'm try to compile kernel 4.4.8 (using fedora 23) to run with Xen 4.6.0 >>> and Intel Skylake processor (Intel Core i7-6600U) >>> >>>

Re: [Xen-devel] ARM bare metal application test

On Mon, May 09, 2016 at 10:29:09AM +, Ivan Pavić2 wrote: > Julien Grail wrote: > > > You can dump the registers of a vCPU with xenctx. > > > $PREFIX/lib/xen/bin/xenctx domid > > > $PREFIX is the path where xen tools have been installed (i.e --prefix on > > the configure). The default path

Re: [Xen-devel] [PATCH for 4.7 4/4] xen: adopt .deinit_pdata and improve timer handling

On Mon, May 9, 2016 at 3:58 PM, Wei Liu wrote: > On Mon, May 09, 2016 at 03:46:23PM +0100, George Dunlap wrote: >> On Sat, May 7, 2016 at 10:19 PM, Meng Xu wrote: >> > On Tue, May 3, 2016 at 5:46 PM, Dario Faggioli >> >

Re: [Xen-devel] xc_altp2m_set_vcpu_enable_notify fail

> > You need to have appropriate log level set. > > Try adding loglvl=all guest_loglvl=all to your xen command line and > reboot. > > Wei. > I've enabled all the log level just as you said, but no outputs happen at HVMOP_altp2m_vcpu_enable_notify section of do_altp2m_op function, so does that

Re: [Xen-devel] [PATCH for-4.7 4/4] x86/hvm: Fix invalidation for emulated invlpg instructions

On 09/05/16 16:14, Tim Deegan wrote: > Hi, > > At 14:15 +0100 on 09 May (1462803342), Andrew Cooper wrote: >> hap_invlpg() is reachable from the instruction emulator, which means >> introspection and tests using hvm_fep can end up here. As such, crashing the >> domain is not an appropriate action

Re: [Xen-devel] Xen 4.7 Test Day Instructions for RC2+ : Call to action for people who added new features / functionality to Xen 4.7

Hi all, I added the following sections based on git logs to man pages. Authors are on the CC list and should review and modify (or suggest edits by replying to this thread). I added/updated/added TODO's to: I do have some questions, to ... - Konrad/Ross: is there any documentation for xSplice

[Xen-devel] [ovmf test] 93901: regressions - FAIL

flight 93901 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/93901/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543

Re: [Xen-devel] Xen does not work after changing scheduler's code

On Thu, Apr 28, 2016 at 11:46 AM, tutu sky wrote: > > hi Geoge, > I don't get your meaning. would you please repeat your question for me in > order to understand it? First, please don't top-post. My meaning was this: You said that running Xen inside of VMWare caused your

Re: [Xen-devel] crash on boot with 4.6.1 on fedora 24

On 05/09/2016 04:08 AM, Jan Beulich wrote: On 09.05.16 at 00:51, wrote: >> I'm try to compile kernel 4.4.8 (using fedora 23) to run with Xen 4.6.0 >> and Intel Skylake processor (Intel Core i7-6600U) >> >> This kernel is crashing almost in the same way as explained in

Re: [Xen-devel] [PATCH for 4.7 4/4] xen: adopt .deinit_pdata and improve timer handling

On Mon, May 09, 2016 at 03:46:23PM +0100, George Dunlap wrote: > On Sat, May 7, 2016 at 10:19 PM, Meng Xu wrote: > > On Tue, May 3, 2016 at 5:46 PM, Dario Faggioli > > wrote: > >> > >> The scheduling hooks API is now used properly, and no > >>

Re: [Xen-devel] [PATCH for 4.7 4/4] xen: adopt .deinit_pdata and improve timer handling

On Mon, May 9, 2016 at 10:52 AM, Dario Faggioli wrote: > On Mon, 2016-05-09 at 10:08 -0400, Meng Xu wrote: >> > I don't think things are confusing, neither right now, nor after >> > this >> > patch, but I'm open to others' opinion. :-) >> >> Hmm, I won't get confused

[Xen-devel] Xen Q35 & virtual VTD support

Hi All: We are researching how to add virtual VTD support for Xen HVM guest. Current qemu has a basic virtual VTD support for Q35. I'd like to confirm whether Xen supports Q35 or not. Can we reuse it for Xen? Thanks. The motivations of adding virtual VTD support for Xen prepare for 1) Shared

Re: [Xen-devel] [PATCH for 4.7 4/4] xen: adopt .deinit_pdata and improve timer handling

On Mon, 2016-05-09 at 10:08 -0400, Meng Xu wrote: > > I don't think things are confusing, neither right now, nor after > > this > > patch, but I'm open to others' opinion. :-) > > Hmm, I won't get confused with the comment from now on, but I'm > unsure > if someone else will or not. The tricky

Re: [Xen-devel] [PATCH for 4.7 4/4] xen: adopt .deinit_pdata and improve timer handling

On Sat, May 7, 2016 at 10:19 PM, Meng Xu wrote: > On Tue, May 3, 2016 at 5:46 PM, Dario Faggioli > wrote: >> >> The scheduling hooks API is now used properly, and no >> initialization or de-initialization happen in >> alloc/free_pdata any longer.

Re: [Xen-devel] [PATCH v4 6/6] hwmon: use smp_call_on_cpu() for dell-smm i8k

On 21/04/16 15:27, Pali Rohár wrote: > On Thursday 21 April 2016 15:12:52 Juergen Gross wrote: >> On 21/04/16 12:57, Pali Rohár wrote: >>> On Tuesday 05 April 2016 21:31:52 Pali Rohár wrote: On Tuesday 05 April 2016 16:54:14 Guenter Roeck wrote: > On Tue, Apr 05, 2016 at 07:10:07AM +0200,

Re: [Xen-devel] [PATCH for 4.7 1/4] xen: sched: avoid spuriously re-enabling IRQs in csched2_switch_sched()

On Fri, May 6, 2016 at 2:21 PM, Dario Faggioli wrote: > On Wed, 2016-05-04 at 18:34 +0100, George Dunlap wrote: >> On 04/05/16 18:21, Dario Faggioli wrote: >> > >> > After all, I'm fine with an ASSERT() too, but then I think we >> > should >> > add one to the same

Re: [Xen-devel] [PATCH] XSA-77: widen scope again

On 29/04/16 10:35, Jan Beulich wrote: > As discussed on the hackathon, avoid us having to issue security > advisories for issues affecting only heavily disaggregated tool stack > setups, which no-one appears to use (or else they should step up to get > things into shape). > > Signed-off-by: Jan

Re: [Xen-devel] [PATCH for 4.7 4/4] xen: adopt .deinit_pdata and improve timer handling

> > > > > I do have a minor comment about the patch, although it is not > > important at all and it is not really about this patch... > > > > > > > > @@ -614,7 +612,8 @@ rt_deinit(struct scheduler *ops) > > > { > > > struct rt_private *prv = rt_priv(ops); > > > > > > -

Re: [Xen-devel] [PATCH for-4.7 4/4] x86/hvm: Fix invalidation for emulated invlpg instructions

On 09/05/16 14:57, Jan Beulich wrote: On 09.05.16 at 15:15, wrote: >> --- a/xen/arch/x86/hvm/svm/svm.c >> +++ b/xen/arch/x86/hvm/svm/svm.c >> @@ -,10 +,13 @@ static void svm_invlpga_intercept( >> >> static void svm_invlpg_intercept(unsigned long vaddr)

Re: [Xen-devel] [PATCH V2] libxl: don't add cache mode for qdisk cdrom drives

On Thu, Apr 28, 2016 at 03:20:46PM -0600, Jim Fehlig wrote: > qemu commit 91a097e7 forbids specifying cache mode for empty > drives. Attempting to create a domain with an empty qdisk cdrom > drive results in > > qemu-system-x86_64: -drive if=ide,index=1,readonly=on,media=cdrom, >

Re: [Xen-devel] [PATCH for-4.7 4/4] x86/hvm: Fix invalidation for emulated invlpg instructions

>>> On 09.05.16 at 15:15, wrote: > --- a/xen/arch/x86/hvm/svm/svm.c > +++ b/xen/arch/x86/hvm/svm/svm.c > @@ -,10 +,13 @@ static void svm_invlpga_intercept( > > static void svm_invlpg_intercept(unsigned long vaddr) > { > -struct vcpu *curr = current; >

Re: [Xen-devel] [PATCH for-4.7 3/4] x86/hvm: Correct the emulated interaction of invlpg with segments

> -Original Message- > From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: 09 May 2016 14:16 > To: Xen-devel > Cc: Andrew Cooper; Jan Beulich; Paul Durrant; Wei Liu > Subject: [PATCH for-4.7 3/4] x86/hvm: Correct the emulated interaction of > invlpg with segments > > The

Re: [Xen-devel] [PATCH for-4.7 3/4] x86/hvm: Correct the emulated interaction of invlpg with segments

On 09/05/16 14:42, Jan Beulich wrote: On 09.05.16 at 15:15, wrote: >> The `invlpg` instruction is documented to take a memory address, and is not >> documented to suffer faults from segmentation violations. >> >> Experimentally, and subsequently confirmed by both

Re: [Xen-devel] [PATCH for-4.7 3/4] x86/hvm: Correct the emulated interaction of invlpg with segments

>>> On 09.05.16 at 15:15, wrote: > The `invlpg` instruction is documented to take a memory address, and is not > documented to suffer faults from segmentation violations. > > Experimentally, and subsequently confirmed by both Intel and AMD, the > instruction does take

Re: [Xen-devel] [PATCH for-4.7 2/4] x86/hvm: Raise #SS faults for %ss-based segmentation violations

On 09/05/16 14:15, Andrew Cooper wrote: > Raising #GP under such circumstances is architecturally wrong. You should include a reference to the relevant Intel and AMD manuals here. David > --- > CC: Jan Beulich > CC: Tim Deegan > CC: Paul Durrant

Re: [Xen-devel] [PATCH for-4.7 2/4] x86/hvm: Raise #SS faults for %ss-based segmentation violations

CC George as well On Mon, May 09, 2016 at 02:15:40PM +0100, Andrew Cooper wrote: > Raising #GP under such circumstances is architecturally wrong. > > Signed-off-by: Andrew Cooper > --- > CC: Jan Beulich > CC: Tim Deegan > CC: Paul

Re: [Xen-devel] [PATCH] xen/balloon: Fix declared-but-not-defined warning

On 09/05/16 15:29, Ross Lagerwall wrote: > Fix a declared-but-not-defined warning when building with > XEN_BALLOON_MEMORY_HOTPLUG=n. This fixes a regression introduced by > commit dfd74a1edfab > ("xen/balloon: Fix crash when ballooning on x86 32 bit PAE"). > > Signed-off-by: Ross Lagerwall

Re: [Xen-devel] [PATCH for-4.7 2/4] x86/hvm: Raise #SS faults for %ss-based segmentation violations

>>> On 09.05.16 at 15:15, wrote: > Raising #GP under such circumstances is architecturally wrong. > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich ___ Xen-devel

Re: [Xen-devel] [PATCH for-4.7 1/4] x86/hvm: Always return the linear address from hvm_virtual_to_linear_addr()

>>> On 09.05.16 at 15:15, wrote: > Some callers need the linear address (with appropriate segment base), whether > or not the limit or canonical check succeeds. > > While modifying the function, change the return type to bool_t to match its > semantics. > >

Re: [Xen-devel] [PATCH] x86: correct remaining extended CPUID level checks

On Mon, May 09, 2016 at 07:19:56AM -0600, Jan Beulich wrote: > We should consistently check the upper 16 bits to be equal 0x8000 and > only then the full value to be >= the desired level. > > Signed-off-by: Jan Beulich > --- > As to inclusion in 4.7 - I think this would be

Re: [Xen-devel] [PATCH v2] x86: cap address bits CPUID output

On Mon, May 09, 2016 at 07:15:47AM -0600, Jan Beulich wrote: > Don't use more or report more to guests than we are capable of > handling. > > At once > - correct the involved extended CPUID level checks, > - simplify the code in hvm_cpuid() and mtrr_top_of_ram(). > > Signed-off-by: Jan Beulich

  1   2   >