Re: [Xen-devel] Big.LITTLE support (WAS Re: Xen ARM community call)

Hi Julien, On Tue, Nov 22, 2016 at 02:28:39PM +, Julien Grall wrote: >Hello Anastassios, > >On 09/11/16 22:50, Anastassios Nanos wrote: >>Hi Julien, all, >> >>>I would like to start organizing a recurring community call to discuss and >>>sync-up on upcoming features for Xen ARM. >> >>great

[Xen-devel] [libvirt test] 102550: regressions - FAIL

flight 102550 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/102550/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt-pair 16 debian-fixup/dst_hostfail REGR. vs. 102503 Regressions which are

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

flight 102543 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/102543/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt13 saverestore-support-check fail REGR. vs. 101275

Re: [Xen-devel] Xen virtual IOMMU high level design doc

On 2016年11月24日 12:09, Edgar E. Iglesias wrote: Hi, > > > > > > I have a few questions. > > > > > > If I understand correctly, you'll be emulating an Intel IOMMU in Xen. > > > So guests will essentially create intel iommu style page-tables. > > > > > > If we

Re: [Xen-devel] [PATCH 12/15] x86/hvm: Rename hvm_copy_*_guest_virt() to hvm_copy_*_guest_linear()

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Wednesday, November 23, 2016 11:39 PM > > The functions use linear addresses, not virtual addresses, as no segmentation > is used. (Lots of other code in Xen makes this mistake.) > > Signed-off-by: Andrew Cooper

Re: [Xen-devel] [PATCH 10/15] x86/hvm: Extend the hvm_copy_*() API with a pagefault_info pointer

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Wednesday, November 23, 2016 11:39 PM > > which is filled with pagefault information should one occur. > > No functional change. > > Signed-off-by: Andrew Cooper > Reviewed-by: Jan Beulich

Re: [Xen-devel] [PATCH 08/15] x86/hvm: Reposition the modification of raw segment data from the VMCB/VMCS

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Wednesday, November 23, 2016 11:39 PM > > Intel VT-x and AMD SVM provide access to the full segment descriptor cache via > fields in the VMCB/VMCS. However, the bits which are actually checked by > hardware and preserved across

Re: [Xen-devel] [PATCH 07/15] x86/vmx: Use hvm_{get, set}_segment_register() rather than vmx_{get, set}_segment_register()

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Wednesday, November 23, 2016 11:39 PM > > No functional change at this point, but this is a prerequisite for forthcoming > functional changes. > > Make vmx_get_segment_register() private to vmx.c like all the other Vendor > get/set

Re: [Xen-devel] [PATCH 06/15] x86/emul: Rework emulator event injection

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Wednesday, November 23, 2016 11:39 PM > > The emulator needs to gain an understanding of interrupts and exceptions > generated by its actions. > > Move hvm_emulate_ctxt.{exn_pending,trap} into struct x86_emulate_ctxt so they > are

Re: [Xen-devel] [PATCH 04/15] x86/emul: Rename HVM_DELIVER_NO_ERROR_CODE to X86_EVENT_NO_EC

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Wednesday, November 23, 2016 11:39 PM > > and move it to live with the other x86_event infrastructure in x86_emulate.h. > Switch it and x86_event.error_code to being signed, matching the rest of the > code. > > Signed-off-by:

Re: [Xen-devel] [PATCH 03/15] x86/emul: Rename hvm_trap to x86_event and move it into the emulation infrastructure

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Wednesday, November 23, 2016 11:39 PM > > The x86 emulator needs to gain an understanding of interrupts and exceptions > generated by its actions. The naming choice is to match both the Intel and > AMD terms, and to avoid 'trap'

Re: [Xen-devel] [PATCH 01/15] x86/hvm: Rename hvm_emulate_init() and hvm_emulate_prepare() for clarity

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Wednesday, November 23, 2016 11:39 PM > > * Move hvm_emulate_init() to immediately hvm_emulate_prepare(), as they are >very closely related. > * Rename hvm_emulate_prepare() to hvm_emulate_init_once() and >

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

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

[Xen-devel] [xen-4.7-testing test] 102536: tolerable FAIL - PUSHED

flight 102536 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/102536/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-i386-xl-qemut-winxpsp3-vcpus1 6 xen-boot fail in 102518 pass in 102536 test-armhf-armhf-xl-xsm

[Xen-devel] [xen-unstable baseline-only test] 68086: tolerable FAIL

This run is configured for baseline tests only. flight 68086 xen-unstable real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68086/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-xtf-amd64-amd64-4 10 xtf-fep

Re: [Xen-devel] Xen virtual IOMMU high level design doc

On Thu, Nov 24, 2016 at 02:00:21AM +, Tian, Kevin wrote: > > From: Stefano Stabellini [mailto:sstabell...@kernel.org] > > Sent: Thursday, November 24, 2016 3:09 AM > > > > On Wed, 23 Nov 2016, Edgar E. Iglesias wrote: > > > On Wed, Aug 17, 2016 at 08:05:51PM +0800, Lan, Tianyu wrote: > > > >

[Xen-devel] [qemu-upstream-4.4-testing baseline-only test] 68087: regressions - FAIL

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

Re: [Xen-devel] Xen virtual IOMMU high level design doc V3

On 2016年11月22日 18:24, Jan Beulich wrote: On 17.11.16 at 16:36, wrote: >> 2) Build ACPI DMAR table in toolstack >> Now tool stack can boot ACPI DMAR table according VM configure and pass >> though it to hvmloader via xenstore ACPI PT channel. But the vIOMMU MMIO >>

Re: [Xen-devel] Xen virtual IOMMU high level design doc

> From: Stefano Stabellini [mailto:sstabell...@kernel.org] > Sent: Thursday, November 24, 2016 3:09 AM > > On Wed, 23 Nov 2016, Edgar E. Iglesias wrote: > > On Wed, Aug 17, 2016 at 08:05:51PM +0800, Lan, Tianyu wrote: > > > Hi All: > > > The following is our Xen vIOMMU high level design for

[Xen-devel] PATCH v3] Compile TianoCore under Fedora Core 25

Hey! Changelog: v3: It is perfect! - Redid commit per Jordan suggestion - Redid the failure scenario per Laszlo suggestion - Redid the testing v2: - Redid it per Laszlo suggestion, added the URL to the bugzilla system - Tested it under more OSes This patch allows me to compile TianoCore

[Xen-devel] [PATCH v3] OvmfPkg/build.sh: Make GCC5 the default toolchain, catch GCC43 and earlier

v2: * Changes suggested by Laszlo: - change the catch-all (*) to GCC5, from GCC44 - remove the (5.*.*) pattern from GCC49 - generate error for GCC < 4.4 In v3, also generate error for really GCC < 4.4, like GCC 1. Reviewed-by: Laszlo Ersek Reviewed-by: Jordan Justen

[Xen-devel] [PATCH LIVEPATCH-BUILD-TOOLS] create-diff-object: Update fixup offsets in .rela.ex_table

From: Ross Lagerwall When pruning entries from the fixup table, update the offsets in .rela.ex_table otherwise the relas might point to the wrong fixup entry or even out of the .fixup section. Signed-off-by: Ross Lagerwall Signed-off-by:

Re: [Xen-devel] Problems with livepatching

On Thu, Nov 24, 2016 at 12:13:43AM +, M A Young wrote: > On Wed, 23 Nov 2016, Andrew Cooper wrote: > > > On 23/11/2016 23:06, M A Young wrote: > > > I have been experimenting with live patching with the recent batch of > > > security updates on Fedora xen with very limited success. I had

[Xen-devel] [qemu-upstream-4.7-testing test] 102532: regressions - FAIL

flight 102532 qemu-upstream-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/102532/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt-xsm 13 saverestore-support-check fail REGR. vs. 100711

Re: [Xen-devel] Problems with livepatching

On Wed, 23 Nov 2016, Andrew Cooper wrote: > On 23/11/2016 23:06, M A Young wrote: > > I have been experimenting with live patching with the recent batch of > > security updates on Fedora xen with very limited success. I had most > > attempts with a test build of xen-4.8.0-rc6, and of the

Re: [Xen-devel] Problems with livepatching

On 23/11/2016 23:06, M A Young wrote: > I have been experimenting with live patching with the recent batch of > security updates on Fedora xen with very limited success. I had most > attempts with a test build of xen-4.8.0-rc6, and of the updates I have > tried only xsa192.patch uploads

[Xen-devel] Problems with livepatching

I have been experimenting with live patching with the recent batch of security updates on Fedora xen with very limited success. I had most attempts with a test build of xen-4.8.0-rc6, and of the updates I have tried only xsa192.patch uploads successfully. For example with xsa191.patch the

[Xen-devel] [qemu-upstream-unstable test] 102534: tolerable FAIL - PUSHED

flight 102534 qemu-upstream-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/102534/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail like 101634

Re: [Xen-devel] [Qemu-devel] [PATCH for-2.8 v3] xen_disk: split discard input to match internal representation

Am 23. November 2016 21:44:50 MEZ, schrieb Olaf Hering : >Is this a can for 2.x? candidate Olaf ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2] OvmfPkg/build.sh: Make GCC5 the default toolchain, catch GCC43 and earlier

On 11/23/16 16:01, Konrad Rzeszutek Wilk wrote: > On Wed, Nov 23, 2016 at 03:55:11PM +0100, Laszlo Ersek wrote: >> On 11/23/16 03:36, Konrad Rzeszutek Wilk wrote: >>> From Laszlo: >>> " change the catch-all (*) to GCC5, from GCC44 >>> - remove the (5.*.*) pattern from GCC49 >>> - add a branch

[Xen-devel] [qemu-upstream-4.5-testing test] 102533: regressions - FAIL

flight 102533 qemu-upstream-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/102533/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-vhd 6 xen-boot fail REGR. vs. 99725

Re: [Xen-devel] [Qemu-devel] [PATCH for-2.8 v3] xen_disk: split discard input to match internal representation

Am 23. November 2016 13:27:13 MEZ, schrieb Kevin Wolf : >Am 23.11.2016 um 12:40 hat Eric Blake geschrieben: >> Qualifies as a bug fix, so requesting 2.8 inclusion. >> Reviewed-by: Eric Blake Is this a can for 2.x? Olaf

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

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

Re: [Xen-devel] xenbits.xen.org gitweb summaries advertise https version, but that url leads to a blank page.

On 23/11/16 21:26, Julien Grall wrote: On 23/11/16 20:10, Sander Eikelenboom wrote: Hi Sander, The summaries [1] on the xenbits.xen.org gitweb advertise that it should be reachable with http, git and https urls, however the https url [2] leads to a blank page. Is that expected (I can

Re: [Xen-devel] xenbits.xen.org gitweb summaries advertise https version, but that url leads to a blank page.

On 23/11/16 20:10, Sander Eikelenboom wrote: Hi Sander, The summaries [1] on the xenbits.xen.org gitweb advertise that it should be reachable with http, git and https urls, however the https url [2] leads to a blank page. Is that expected (I can imagine it was switched off to lower

[Xen-devel] xenbits.xen.org gitweb summaries advertise https version, but that url leads to a blank page.

Hi Lars, The summaries [1] on the xenbits.xen.org gitweb advertise that it should be reachable with http, git and https urls, however the https url [2] leads to a blank page. Is that expected (I can imagine it was switched off to lower serverload, however I wouldn't expect it to be advertised

Re: [Xen-devel] [PATCH 08/15] x86/hvm: Reposition the modification of raw segment data from the VMCB/VMCS

On 23/11/16 19:41, Boris Ostrovsky wrote: > On 11/23/2016 02:28 PM, Andrew Cooper wrote: >>> SVM requires attributes of any NULL segment to be zero. >> Where is this claim made? Vol2 recommends that the VMM clear all >> attributes, but the wording of the previous paragraph suggests that the >>

Re: [Xen-devel] Xen ARM small task (WAS: Re: [Xen Question])

On Tue, 22 Nov 2016, Julien Grall wrote: > On 22/11/16 19:06, Stefano Stabellini wrote: > > On Mon, 21 Nov 2016, Julien Grall wrote: > > > On 21/11/2016 21:13, Edgar E. Iglesias wrote: > > > > On Mon, Nov 21, 2016 at 01:01:15PM -0800, Stefano Stabellini wrote: > > > > > On Mon, 21 Nov 2016, Edgar

Re: [Xen-devel] [PATCH 08/15] x86/hvm: Reposition the modification of raw segment data from the VMCB/VMCS

On 11/23/2016 02:28 PM, Andrew Cooper wrote: > >> SVM requires attributes of any NULL segment to be zero. > Where is this claim made? Vol2 recommends that the VMM clear all > attributes, but the wording of the previous paragraph suggests that the > attributes would be ignored in this case. The

Re: [Xen-devel] [PATCH v1] libxl: Make an ACPI support build for ARM64 configurable.

On 23/11/16 19:28, Julien Grall wrote: > > > On 23/11/16 15:47, Andrii Anisov wrote: >> Hello Julien, > > Hi Andrii, > >>> The ACPI support is pretty much contained in a single file and I am >>> not sure you will win much space. >>> Can you explain why the ACPI guest support should be optional? >>

Re: [Xen-devel] [PATCH 08/15] x86/hvm: Reposition the modification of raw segment data from the VMCB/VMCS

On 23/11/16 19:01, Boris Ostrovsky wrote: > On 11/23/2016 10:38 AM, Andrew Cooper wrote: >> Intel VT-x and AMD SVM provide access to the full segment descriptor cache >> via >> fields in the VMCB/VMCS. However, the bits which are actually checked by >> hardware and preserved across vmentry/exit

Re: [Xen-devel] [PATCH v1] libxl: Make an ACPI support build for ARM64 configurable.

On 23/11/16 15:47, Andrii Anisov wrote: Hello Julien, Hi Andrii, The ACPI support is pretty much contained in a single file and I am not sure you will win much space. Can you explain why the ACPI guest support should be optional? This would increase the system configurability and would

Re: [Xen-devel] [RFC] Shared coprocessor framework

> I was thinking of something trivial but enough to prove the point. It is already implemented in a hack'n'slash way. So we are pretty confident in the approach and looking forward to make generic and scalable implementation. And upstreamable, of course. Sincerely, Andrii Anisov.

Re: [Xen-devel] Xen virtual IOMMU high level design doc

On Wed, 23 Nov 2016, Edgar E. Iglesias wrote: > On Wed, Aug 17, 2016 at 08:05:51PM +0800, Lan, Tianyu wrote: > > Hi All: > > The following is our Xen vIOMMU high level design for detail > > discussion. Please have a look. Very appreciate for your comments. > > This design doesn't cover

Re: [Xen-devel] [RFC] Shared coprocessor framework

> I was thinking of something trivial but enough to prove the point. > Something like a very simple accelerator, maybe a data copy accelerator. > A GPU is certainly not trivial :-) Indeed. But we still have targets to reach and shortage in resources to spread over simple examples ;) Sincerely,

Re: [Xen-devel] Low-hanging fruit bugs for starting contributor

On 22/11/16 15:49, Elazar Leibovich wrote: > Hi, > For someone wishing to start contributing to Xen hypervisor, what > would you recommend as an easy, educational, bug he could start with? Not a bug pe say, but something I have just tripped over again and remember that I had already decided to

Re: [Xen-devel] [PATCH 08/15] x86/hvm: Reposition the modification of raw segment data from the VMCB/VMCS

On 11/23/2016 10:38 AM, Andrew Cooper wrote: > Intel VT-x and AMD SVM provide access to the full segment descriptor cache via > fields in the VMCB/VMCS. However, the bits which are actually checked by > hardware and preserved across vmentry/exit are inconsistent, and the vendor > accessor

Re: [Xen-devel] [RFC] Shared coprocessor framework

On Wed, 23 Nov 2016, Andrii Anisov wrote: > Stefano, > > Please see my answers below: > > > > Thank you for the document, I think is a very good start. I also see the > > need for this framework. Please add more details about the proposed > > interface (Xen API, hypercalls, etc) in the next

Re: [Xen-devel] [PATCH v9 07/13] x86: add multiboot2 protocol support for EFI platforms

On 29/09/16 22:42, Daniel Kiper wrote: > This way Xen can be loaded on EFI platforms using GRUB2 and > other boot loaders which support multiboot2 protocol. > > Signed-off-by: Daniel Kiper > --- > v9 - suggestions/fixes: >- use .L labels instead of numeric ones in

Re: [Xen-devel] [PATCH] xen_disk: convert discard input to byte ranges

On Wed, 23 Nov 2016, Olaf Hering wrote: > On Wed, Nov 23, Olaf Hering wrote: > > > > > +if (!blk_split_discard(ioreq, req->sector_number, > > > > req->nr_sectors)) { > > > > +goto err; > > > How is error handling supposed to work here? > > In the guest the cmd is stuck,

Re: [Xen-devel] [PATCH v3] xen_disk: split discard input to match internal representation

On Wed, 23 Nov 2016, Olaf Hering wrote: > The guest sends discard requests as u64 sector/count pairs, but the > block layer operates internally with s64/s32 pairs. The conversion > leads to IO errors in the guest, the discard request is not processed. > > domU.cfg: > 'vdev=xvda, format=qcow2,

Re: [Xen-devel] [Qemu-devel] [PATCH for-2.8 v3] xen_disk: split discard input to match internal representation

On Wed, 23 Nov 2016, Kevin Wolf wrote: > Am 23.11.2016 um 12:40 hat Eric Blake geschrieben: > > On 11/23/2016 04:39 AM, Olaf Hering wrote: > > > The guest sends discard requests as u64 sector/count pairs, but the > > > block layer operates internally with s64/s32 pairs. The conversion > > > leads

Re: [Xen-devel] Xen ARM small task (WAS: Re: [Xen Question])

Hi Edgar, On 23/11/16 16:38, Edgar E. Iglesias wrote: On Wed, Nov 23, 2016 at 06:26:06PM +0200, Artem Mygaiev wrote: On 23.11.16 17:19, Julien Grall wrote: There is a couple of usecase where we cannot use PV console: - Running unmodified baremetal application as guest. Those applications

Re: [Xen-devel] [PATCH 3/3] xen: ignore direction in bufioreq handling

On Wed, 23 Nov 2016, Paul Durrant wrote: > > -Original Message- > > From: Jan Beulich [mailto:jbeul...@suse.com] > > Sent: 23 November 2016 09:25 > > To: qemu-de...@nongnu.org > > Cc: Anthony Perard ; Paul Durrant > > ; Stefano Stabellini

Re: [Xen-devel] Xen virtual IOMMU high level design doc

On Wed, Aug 17, 2016 at 08:05:51PM +0800, Lan, Tianyu wrote: > Hi All: > The following is our Xen vIOMMU high level design for detail > discussion. Please have a look. Very appreciate for your comments. > This design doesn't cover changes when root port is moved to hypervisor. > We may design

Re: [Xen-devel] [PATCH 2/3] xen: slightly simplify bufioreq handling

On Wed, 23 Nov 2016, Jan Beulich wrote: > There's no point setting fields always receiving the same value on each > iteration, as handle_ioreq() doesn't alter them anyway. Set state and > count once ahead of the loop, drop the redundant clearing of > data_is_ptr, and avoid the meaningless setting

Re: [Xen-devel] [PATCH 1/3] xen: fix quad word bufioreq handling

On Wed, 23 Nov 2016, Jan Beulich wrote: > >>> On 23.11.16 at 11:45, wrote: > > No, if QEMU is using a default ioreq server (i.e. the legacy way of doing > > things) then it's vulnerable to the guest messing with the rings and I'd > > forgotten that migrated-in guests

Re: [Xen-devel] [qemu-mainline test] 102527: regressions - trouble: broken/fail/pass

On Wed, Nov 23, 2016 at 04:49:40PM +, osstest service owner wrote: > flight 102527 qemu-mainline real [real] > http://logs.test-lab.xenproject.org/osstest/logs/102527/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: >

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

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

Re: [Xen-devel] [PATCH] libxl: fix creation of pkgconf install dir

On Wed, Nov 23, 2016 at 04:56:39PM +, Roger Pau Monne wrote: > When PKG_INSTALLDIR was introduced the creation of the previous pkgconf > install > directory was not changed. Fix this by correctly using PKG_INSTALLDIR for the > directory creation in libxl Makefile. > > Signed-off-by: Roger

Re: [Xen-devel] [PATCH 13/15] x86/hvm: Avoid __hvm_copy() raising #PF behind the emulators back

On 23/11/16 16:39, Tim Deegan wrote: > At 15:38 + on 23 Nov (1479915536), Andrew Cooper wrote: >> Drop the call to hvm_inject_page_fault() in __hvm_copy(), and require callers >> to inject the pagefault themselves. >> >> No functional change. >> >> Signed-off-by: Andrew Cooper

Re: [Xen-devel] [PATCH 04/15] x86/emul: Rename HVM_DELIVER_NO_ERROR_CODE to X86_EVENT_NO_EC

On 11/23/2016 10:38 AM, Andrew Cooper wrote: > and move it to live with the other x86_event infrastructure in x86_emulate.h. > Switch it and x86_event.error_code to being signed, matching the rest of the > code. > > Signed-off-by: Andrew Cooper Reviewed-by: Boris

[Xen-devel] [qemu-upstream-4.4-testing test] 102531: tolerable FAIL - PUSHED

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

Re: [Xen-devel] [PATCH 09/15] x86/emul: Avoid raising faults behind the emulators back

On 23/11/16 16:50, Tim Deegan wrote: > At 16:40 + on 23 Nov (1479919254), Andrew Cooper wrote: >> On 23/11/16 16:31, Tim Deegan wrote: >>> At 15:38 + on 23 Nov (1479915532), Andrew Cooper wrote: Introduce a new x86_emul_pagefault() similar to x86_emul_hw_exception(), and

Re: [Xen-devel] [PATCH 03/15] x86/emul: Rename hvm_trap to x86_event and move it into the emulation infrastructure

On 11/23/2016 10:38 AM, Andrew Cooper wrote: > The x86 emulator needs to gain an understanding of interrupts and exceptions > generated by its actions. The naming choice is to match both the Intel and > AMD terms, and to avoid 'trap' specifically as it has an architectural meaning > different to

[Xen-devel] [PATCH] libxl: fix creation of pkgconf install dir

When PKG_INSTALLDIR was introduced the creation of the previous pkgconf install directory was not changed. Fix this by correctly using PKG_INSTALLDIR for the directory creation in libxl Makefile. Signed-off-by: Roger Pau Monné --- Cc: Ian Jackson

Re: [Xen-devel] [PATCH 09/15] x86/emul: Avoid raising faults behind the emulators back

At 16:40 + on 23 Nov (1479919254), Andrew Cooper wrote: > On 23/11/16 16:31, Tim Deegan wrote: > > At 15:38 + on 23 Nov (1479915532), Andrew Cooper wrote: > >> Introduce a new x86_emul_pagefault() similar to x86_emul_hw_exception(), > >> and > >> use this instead of

[Xen-devel] [qemu-mainline test] 102527: regressions - trouble: broken/fail/pass

flight 102527 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/102527/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qcow2 9 debian-di-installfail REGR. vs. 101909

Re: [Xen-devel] [PATCH 06/15] x86/emul: Rework emulator event injection

At 09:33 -0700 on 23 Nov (1479893609), Jan Beulich wrote: > >>> On 23.11.16 at 17:19, wrote: > > Hi, > > > > At 15:38 + on 23 Nov (1479915529), Andrew Cooper wrote: > >> The emulator needs to gain an understanding of interrupts and exceptions > >> generated by its actions. > >>

Re: [Xen-devel] [PATCH 14/15] x86/hvm: Prepare to allow use of system segments for memory references

> -Original Message- > From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: 23 November 2016 15:39 > To: Xen-devel > Cc: Andrew Cooper ; Jan Beulich > ; Paul Durrant > Subject:

Re: [Xen-devel] [PATCH 01/15] x86/hvm: Rename hvm_emulate_init() and hvm_emulate_prepare() for clarity

On 23/11/16 16:41, Boris Ostrovsky wrote: > On 11/23/2016 10:38 AM, Andrew Cooper wrote: >> * Move hvm_emulate_init() to immediately hvm_emulate_prepare(), as they are >>very closely related. >> * Rename hvm_emulate_prepare() to hvm_emulate_init_once() and >>hvm_emulate_init() to

Re: [Xen-devel] [PATCH 09/15] x86/emul: Avoid raising faults behind the emulators back

On 23/11/16 16:31, Tim Deegan wrote: > At 15:38 + on 23 Nov (1479915532), Andrew Cooper wrote: >> Introduce a new x86_emul_pagefault() similar to x86_emul_hw_exception(), and >> use this instead of hvm_inject_page_fault() from emulation codepaths. >> >> Replace one hvm_inject_hw_exception() in

Re: [Xen-devel] [PATCH 11/15] x86/hvm: Reimplement hvm_copy_*_nofault() in terms of no pagefault_info

At 16:35 + on 23 Nov (1479918931), Tim Deegan wrote: > At 15:38 + on 23 Nov (1479915534), Andrew Cooper wrote: > > No functional change. > > > > Signed-off-by: Andrew Cooper > > Shouldn't this also update the comments to describe the new semantics > of

Re: [Xen-devel] [PATCH 01/15] x86/hvm: Rename hvm_emulate_init() and hvm_emulate_prepare() for clarity

>>> On 23.11.16 at 16:38, wrote: > * Move hvm_emulate_init() to immediately hvm_emulate_prepare(), as they are >very closely related. > * Rename hvm_emulate_prepare() to hvm_emulate_init_once() and >hvm_emulate_init() to hvm_emulate_init_per_insn() to make it

Re: [Xen-devel] [PATCH 06/15] x86/emul: Rework emulator event injection

On 23/11/16 16:19, Tim Deegan wrote: > Hi, > > At 15:38 + on 23 Nov (1479915529), Andrew Cooper wrote: >> The emulator needs to gain an understanding of interrupts and exceptions >> generated by its actions. >> >> Move hvm_emulate_ctxt.{exn_pending,trap} into struct x86_emulate_ctxt so they >>

Re: [Xen-devel] [PATCH 01/15] x86/hvm: Rename hvm_emulate_init() and hvm_emulate_prepare() for clarity

On 11/23/2016 10:38 AM, Andrew Cooper wrote: > * Move hvm_emulate_init() to immediately hvm_emulate_prepare(), as they are >very closely related. > * Rename hvm_emulate_prepare() to hvm_emulate_init_once() and >hvm_emulate_init() to hvm_emulate_init_per_insn() to make it clearer how to >

Re: [Xen-devel] [PATCH 13/15] x86/hvm: Avoid __hvm_copy() raising #PF behind the emulators back

At 15:38 + on 23 Nov (1479915536), Andrew Cooper wrote: > Drop the call to hvm_inject_page_fault() in __hvm_copy(), and require callers > to inject the pagefault themselves. > > No functional change. > > Signed-off-by: Andrew Cooper > index afacd5f..88d4642

Re: [Xen-devel] [PATCH 10/15] x86/hvm: Extend the hvm_copy_*() API with a pagefault_info pointer

> -Original Message- > From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: 23 November 2016 15:39 > To: Xen-devel > Cc: Andrew Cooper ; Paul Durrant > ; Tim (Xen.org) ; Jun Nakajima >

Re: [Xen-devel] Xen ARM small task (WAS: Re: [Xen Question])

On Wed, Nov 23, 2016 at 06:26:06PM +0200, Artem Mygaiev wrote: > On 23.11.16 17:19, Julien Grall wrote: > > There is a couple of usecase where we cannot use PV console: > > - Running unmodified baremetal application as guest. Those > > applications will not have PV driver. > Well, I somehow

[Xen-devel] [PATCH v9] sndif: add ABI for para-virtual sound

Hi, all! First of all we would like to thank you for valuable comments! Please find the next version of the ABI for the PV sound. Thank you, Oleksandr Andrushchenko Oleksandr Grytsov Oleksandr Andrushchenko (1): xen: add para-virtual sound interface header files

[Xen-devel] [PATCH v9] xen: add para-virtual sound interface header files

This is the ABI for the two halves of a para-virtualized sound driver to communicate with each to other. Signed-off-by: Oleksandr Andrushchenko Signed-off-by: Oleksandr Grytsov Signed-off-by: Oleksandr Dmytryshyn

Re: [Xen-devel] [PATCH 12/15] x86/hvm: Rename hvm_copy_*_guest_virt() to hvm_copy_*_guest_linear()

At 15:38 + on 23 Nov (1479915535), Andrew Cooper wrote: > The functions use linear addresses, not virtual addresses, as no segmentation > is used. (Lots of other code in Xen makes this mistake.) > > Signed-off-by: Andrew Cooper Acked-by: Tim Deegan

Re: [Xen-devel] [PATCH 11/15] x86/hvm: Reimplement hvm_copy_*_nofault() in terms of no pagefault_info

At 15:38 + on 23 Nov (1479915534), Andrew Cooper wrote: > No functional change. > > Signed-off-by: Andrew Cooper Shouldn't this also update the comments to describe the new semantics of hvm_copy_*()? Tim. ___

Re: [Xen-devel] [PATCH 06/15] x86/emul: Rework emulator event injection

>>> On 23.11.16 at 17:19, wrote: > Hi, > > At 15:38 + on 23 Nov (1479915529), Andrew Cooper wrote: >> The emulator needs to gain an understanding of interrupts and exceptions >> generated by its actions. >> >> Move hvm_emulate_ctxt.{exn_pending,trap} into struct

Re: [Xen-devel] [PATCH 10/15] x86/hvm: Extend the hvm_copy_*() API with a pagefault_info pointer

At 15:38 + on 23 Nov (1479915533), Andrew Cooper wrote: > which is filled with pagefault information should one occur. > > No functional change. > > Signed-off-by: Andrew Cooper > Reviewed-by: Jan Beulich Acked-by: Tim Deegan

Re: [Xen-devel] [PATCH 09/15] x86/emul: Avoid raising faults behind the emulators back

At 15:38 + on 23 Nov (1479915532), Andrew Cooper wrote: > Introduce a new x86_emul_pagefault() similar to x86_emul_hw_exception(), and > use this instead of hvm_inject_page_fault() from emulation codepaths. > > Replace one hvm_inject_hw_exception() in the shadow emulation codepaths. > >

Re: [Xen-devel] Xen ARM small task (WAS: Re: [Xen Question])

On 23.11.16 17:19, Julien Grall wrote: > There is a couple of usecase where we cannot use PV console: > - Running unmodified baremetal application as guest. Those > applications will not have PV driver. Well, I somehow missed that requirement is to run *unmodified* applications... I think it

Re: [Xen-devel] [PATCH 03/15] x86/emul: Rename hvm_trap to x86_event and move it into the emulation infrastructure

On 23/11/16 16:12, Paul Durrant wrote: >> diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c >> index f24e211..d0c3185 100644 >> --- a/xen/arch/x86/hvm/emulate.c >> +++ b/xen/arch/x86/hvm/emulate.c >> @@ -1679,7 +1679,7 @@ static int hvmemul_invlpg( >> * violations, so

Re: [Xen-devel] [PATCH 04/15] x86/emul: Rename HVM_DELIVER_NO_ERROR_CODE to X86_EVENT_NO_EC

> -Original Message- > From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: 23 November 2016 15:39 > To: Xen-devel > Cc: Andrew Cooper ; Jan Beulich > ; Paul Durrant ; Jun > Nakajima

Re: [Xen-devel] [PATCH 06/15] x86/emul: Rework emulator event injection

Hi, At 15:38 + on 23 Nov (1479915529), Andrew Cooper wrote: > The emulator needs to gain an understanding of interrupts and exceptions > generated by its actions. > > Move hvm_emulate_ctxt.{exn_pending,trap} into struct x86_emulate_ctxt so they > are visible to the emulator. This removes

Re: [Xen-devel] [PATCH 13/15] x86/hvm: Avoid __hvm_copy() raising #PF behind the emulators back

On 23/11/16 15:38, Andrew Cooper wrote: > diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c > index afacd5f..88d4642 100644 > --- a/xen/arch/x86/mm/shadow/common.c > +++ b/xen/arch/x86/mm/shadow/common.c > @@ -198,6 +198,7 @@ hvm_read(enum x86_segment seg, > case

Re: [Xen-devel] [PATCH KERNEL] xen/events: use xen_vcpu_id mapping for EVTCHNOP_status

On 11/23/2016 07:38 AM, Vitaly Kuznetsov wrote: > EVTCHNOP_status hypercall returns Xen's idea of vcpu id so we need to > compare it against xen_vcpu_id mapping, not the Linux cpu id. > > Suggested-by: Radim Krcmar > Signed-off-by: Vitaly Kuznetsov

Re: [Xen-devel] [PATCH 03/15] x86/emul: Rename hvm_trap to x86_event and move it into the emulation infrastructure

> -Original Message- > From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: 23 November 2016 15:39 > To: Xen-devel > Cc: Andrew Cooper ; Jan Beulich > ; Paul Durrant ; Jun > Nakajima

Re: [Xen-devel] [PATCH 02/15] x86/emul: Simplfy emulation state setup

At 15:38 + on 23 Nov (1479915525), Andrew Cooper wrote: > The current code to set up emulation state is ad-hoc and error prone. > > * Consistently zero all emulation state structures. > * Avoid explicitly initialising some state to 0. > * Explicitly identify all input and output state in

Re: [Xen-devel] [PATCH 02/15] x86/emul: Simplfy emulation state setup

> -Original Message- > From: Andrew Cooper > Sent: 23 November 2016 16:01 > To: Paul Durrant ; Xen-devel de...@lists.xen.org> > Cc: Jan Beulich ; Tim (Xen.org) ; George > Dunlap > Subject: Re: [PATCH

Re: [Xen-devel] [PATCH v3] xen_disk: split discard input to match internal representation

On Wed, Nov 23, 2016 at 10:39:12AM +, Olaf Hering wrote: > The guest sends discard requests as u64 sector/count pairs, but the > block layer operates internally with s64/s32 pairs. The conversion > leads to IO errors in the guest, the discard request is not processed. > > domU.cfg: >

Re: [Xen-devel] [PATCH 02/15] x86/emul: Simplfy emulation state setup

On 23/11/16 15:58, Paul Durrant wrote: >> diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c >> b/xen/arch/x86/x86_emulate/x86_emulate.c >> index 04f0dac..c5d9664 100644 >> --- a/xen/arch/x86/x86_emulate/x86_emulate.c >> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c >> @@ -1904,6 +1904,8 @@

Re: [Xen-devel] [RFC PATCH 02/24] ARM: GICv3: allocate LPI pending and property table

Hi Andre, On 15/11/16 11:32, Andre Przywara wrote: On 01/11/16 17:22, Julien Grall wrote: On 28/09/2016 19:24, Andre Przywara wrote: The ARM GICv3 ITS provides a new kind of interrupt called LPIs. The pending bits and the configuration data (priority, enable bits) for those LPIs are stored in

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

flight 102522 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/102522/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-xtf-amd64-amd64-3 65 leak-check/check fail in 102500 pass in 102522

Re: [Xen-devel] [PATCH 01/15] x86/hvm: Rename hvm_emulate_init() and hvm_emulate_prepare() for clarity

On Wed, Nov 23, 2016 at 03:38:44PM +, Andrew Cooper wrote: > * Move hvm_emulate_init() to immediately hvm_emulate_prepare(), as they are >very closely related. > * Rename hvm_emulate_prepare() to hvm_emulate_init_once() and >hvm_emulate_init() to hvm_emulate_init_per_insn() to make

  1   2   >