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

On 9/9/2016 1:22 PM, Yu Zhang wrote: On 9/2/2016 6:47 PM, Yu Zhang wrote: A new HVMOP - HVMOP_map_mem_type_to_ioreq_server, is added to let one ioreq server claim/disclaim its responsibility for the handling of guest pages with p2m type p2m_ioreq_server. Users of this HVMOP can specify

Re: [Xen-devel] [PATCH v3 1/1] xen: move TLB-flush filtering out into populate_physmap during vm creation

Thank you all very much for the feedback. I will address them in the next version. > > Did you go through and check that there is nothing this information > > can already get derived from? I can't immediately point you at > > anything, but it feels like there should. > > > Indeed. And if there

[Xen-devel] [xen-4.4-testing test] 100815: tolerable FAIL - PUSHED

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

Re: [Xen-devel] [RFC PATCH] x86/apicv: fix RTC periodic timer and apicv issue

On August 30, 2016 1:58 PM, Tian Kevin < kevin.t...@intel.com > wrote: >> From: Xuquan (Euler) [mailto:xuqu...@huawei.com] >> Sent: Friday, August 19, 2016 8:59 PM >> >> When Xen apicv is enabled, wall clock time is faster on Windows7-32 >> guest with high payload (with 2vCPU, captured from

[Xen-devel] [xen-4.6-testing test] 100816: regressions - FAIL

flight 100816 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/100816/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-debianhvm-amd64 15 guest-localmigrate/x10 fail REGR. vs. 100779

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

This run is configured for baseline tests only. flight 67676 qemu-mainline real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/67676/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-i386-pvgrub 10 guest-start

[Xen-devel] [xen-4.7-testing test] 100813: regressions - FAIL

flight 100813 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/100813/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-debianhvm-amd64 13 guest-localmigrate fail REGR. vs. 100777

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

flight 100814 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/100814/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-arndale 11 guest-start fail REGR. vs. 100769

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

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

Re: [Xen-devel] [PATCH v3 18/19] libxl/acpi: Build ACPI tables for HVMlite guests

On 09/08/2016 10:20 AM, Jan Beulich wrote: >> >> >> /* >> diff --git a/tools/libacpi/libacpi.h b/tools/libacpi/libacpi.h >> index d803139..b0ff5aa 100644 >> --- a/tools/libacpi/libacpi.h >> +++ b/tools/libacpi/libacpi.h >> @@ -48,6 +48,15 @@ struct acpi_ctxt { >> void (*free)(struct

Re: [Xen-devel] [PATCH v3 13/19] acpi: Makefile should better tolerate interrupts

On 09/08/2016 10:15 AM, Jan Beulich wrote: On 07.09.16 at 20:59, wrote: >> Intermediate stages of building a target should be made with >> temporary files that are copied to final target in the end. >> >> Signed-off-by: Boris Ostrovsky

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

On Thu, 8 Sep 2016, Paulina Szubarczyk wrote: > > > @@ -582,6 +722,9 @@ static int ioreq_runio_qemu_aio(struct ioreq *ioreq) > > > } > > > default: > > > /* unknown operation (shouldn't happen -- parse catches this) */ > > > +if (!ioreq->blkdev->feature_grant_copy) {

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

flight 100809 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/100809/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 9 debian-install fail like 100780

Re: [Xen-devel] [PATCH v3 09/19] acpi/hvmloader: Include file/paths adjustments

On 09/08/2016 10:05 AM, Jan Beulich wrote: >> >> diff --git a/tools/firmware/hvmloader/acpi/libacpi.h >> b/tools/firmware/hvmloader/acpi/libacpi.h >> index 3bcd226..d803139 100644 >> --- a/tools/firmware/hvmloader/acpi/libacpi.h >> +++ b/tools/firmware/hvmloader/acpi/libacpi.h >> @@ -84,6 +84,13

[Xen-devel] [PATCH] xen/x86: Fix build with clang following c/s 4fa0105

https://travis-ci.org/xen-project/xen/jobs/158494027#L2344 Clang complains: emulate.c:2016:14: error: comparison of unsigned enum expression < 0 is always false [-Werror,-Wtautological-compare] if ( seg < 0 || seg >= ARRAY_SIZE(hvmemul_ctxt->seg_reg) ) ~~~ ^ ~ Clang is

Re: [Xen-devel] [PATCH] arm/xen: fix SMP guests boot

On Thu, 8 Sep 2016, Vitaly Kuznetsov wrote: > Commit 88e957d6e47f ("xen: introduce xen_vcpu_id mapping") broke SMP ARM > guests on Xen. When FIFO-based event channels are in use (this is the > default), evtchn_fifo_alloc_control_block() is called on CPU_UP_PREPARE > event and this happens before

Re: [Xen-devel] [OSSTEST PATCH v3 20/25] mfi-common: create xtf build job for 4.4 onwards

On Thu, Sep 08, 2016 at 06:41:26PM +0100, Ian Jackson wrote: > Wei Liu writes ("Re: [OSSTEST PATCH v3 20/25] mfi-common: create xtf build > job for 4.4 onwards"): > > The following fixup patch is required to properly filter out unnecessary > > branches. > > Right. > > AFAICT the diff you

Re: [Xen-devel] [OSSTEST PATCH v3 25/25] Create XTF branch

On Thu, Sep 08, 2016 at 06:45:06PM +0100, Ian Jackson wrote: > Wei Liu writes ("Re: [OSSTEST PATCH v3 25/25] Create XTF branch"): > > On Thu, Sep 08, 2016 at 03:47:38PM +0100, Ian Jackson wrote: > > > Thanks. It's not entirely clear from your comments above whether this > > > is a diff for the

Re: [Xen-devel] [PATCH Altp2m cleanup v4 3/4] Move altp2m specific functions to altp2m files.

[Paul2] in-line -Original Message- From: Jan Beulich [mailto:jbeul...@suse.com] Sent: Thursday, September 8, 2016 8:02 AM To: Lai, Paul C Cc: george.dun...@citrix.com; Sahita, Ravi ; xen-devel Subject: Re:

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

flight 100822 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/100822/ 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] [OSSTEST PATCH v3 25/25] Create XTF branch

Wei Liu writes ("Re: [OSSTEST PATCH v3 25/25] Create XTF branch"): > On Thu, Sep 08, 2016 at 03:47:38PM +0100, Ian Jackson wrote: > > Thanks. It's not entirely clear from your comments above whether this > > is a diff for the whole of your series, including 20/25 (add build > > jobs), or just for

Re: [Xen-devel] [OSSTEST PATCH v3 24/25] make-flight: create 5 xtf jobs

Wei Liu writes ("Re: [OSSTEST PATCH v3 24/25] make-flight: create 5 xtf jobs"): > This is a fixup patch to switch from xenbranch_wants_xtf_tests to > branch_wants_xtf_tests. Right. Please retain my ack. Ian. ___ Xen-devel mailing list

Re: [Xen-devel] [OSSTEST PATCH v3 20/25] mfi-common: create xtf build job for 4.4 onwards

Wei Liu writes ("Re: [OSSTEST PATCH v3 20/25] mfi-common: create xtf build job for 4.4 onwards"): > The following fixup patch is required to properly filter out unnecessary > branches. Right. AFAICT the diff you present is of the results of the original v3 20/25 plus your fixup patch ? If so,

Re: [Xen-devel] [OSSTEST PATCH v3 25/25] Create XTF branch

On Thu, Sep 08, 2016 at 03:47:38PM +0100, Ian Jackson wrote: > Wei Liu writes ("Re: [OSSTEST PATCH v3 25/25] Create XTF branch"): > > On Tue, Sep 06, 2016 at 03:03:50PM +0100, Ian Jackson wrote: > > > Wei Liu writes ("[OSSTEST PATCH v3 25/25] Create XTF branch"): > > > > This branch contains Xen

Re: [Xen-devel] [OSSTEST PATCH v3 24/25] make-flight: create 5 xtf jobs

This is a fixup patch to switch from xenbranch_wants_xtf_tests to branch_wants_xtf_tests. From ac5eaf4e4f10fb7da604a8bee41b1af1b27ad96f Mon Sep 17 00:00:00 2001 From: Wei Liu Date: Thu, 8 Sep 2016 17:54:08 +0100 Subject: [OSSTEST PATCH] fixup! make-flight: create 5 xtf jobs

Re: [Xen-devel] [OSSTEST PATCH v3 20/25] mfi-common: create xtf build job for 4.4 onwards

On Tue, Sep 06, 2016 at 03:06:02PM +0100, Ian Jackson wrote: > Wei Liu writes ("[OSSTEST PATCH v3 20/25] mfi-common: create xtf build job > for 4.4 onwards"): > > Xen 4.4 is the oldest one that we still provide security support at this > > point in time. > > > > Signed-off-by: Wei Liu

Re: [Xen-devel] [PATCH Altp2m cleanup v4 2/4] altp2m cleanup work

[Paul2] in-line -Original Message- From: Tamas K Lengyel [mailto:tamas.k.leng...@gmail.com] Sent: Thursday, September 8, 2016 9:07 AM To: Lai, Paul C Cc: Jan Beulich ; xen-devel ; Sahita, Ravi

Re: [Xen-devel] [PATCH] fix EFI part of "symbols: Generate an xen-sym.map"

>>> On 08.09.16 at 18:21, wrote: > On Thu, Sep 08, 2016 at 06:45:36AM -0600, Jan Beulich wrote: >> Commit 6ea24e53f1 introduced two problems: It left out a semicolon and >> typo-ed the source file name of the EFI map file install command. > > I really need Fedora to

Re: [Xen-devel] [PATCH] fix EFI part of "symbols: Generate an xen-sym.map"

On Thu, Sep 08, 2016 at 06:45:36AM -0600, Jan Beulich wrote: > Commit 6ea24e53f1 introduced two problems: It left out a semicolon and > typo-ed the source file name of the EFI map file install command. I really need Fedora to start building ld with PE support. > > Signed-off-by: Jan Beulich

Re: [Xen-devel] [PATCH Altp2m cleanup v4 2/4] altp2m cleanup work

On Thu, Sep 8, 2016 at 9:50 AM, Lai, Paul C wrote: > [Paul] in-line > > -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Thursday, September 8, 2016 7:47 AM > To: Lai, Paul C > Cc: george.dun...@citrix.com; Sahita, Ravi

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

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

Re: [Xen-devel] [PATCH v3 1/1] xen: move TLB-flush filtering out into populate_physmap during vm creation

On Thu, 2016-09-08 at 09:36 -0600, Jan Beulich wrote: > > > > > > > > > > > > > On 08.09.16 at 07:30, wrote: > > --- a/xen/include/xen/sched.h > > +++ b/xen/include/xen/sched.h > > @@ -474,6 +474,9 @@ struct domain > >  unsigned int guest_request_enabled   

[Xen-devel] [OSSTEST PATCH] TestSupport: use qemu-img to create vhd image

We would like to delete blktap2 from xen.git at some point, but vhd-util is part of blktap2. Let's switch to use qemu-img to create vhd image to remove the dependency on blktap2 in osstest. Note that vhd format is named "vpc" in qemu-img. Signed-off-by: Wei Liu ---

Re: [Xen-devel] [PATCH Altp2m cleanup v4 2/4] altp2m cleanup work

[Paul] in-line -Original Message- From: Jan Beulich [mailto:jbeul...@suse.com] Sent: Thursday, September 8, 2016 7:47 AM To: Lai, Paul C Cc: george.dun...@citrix.com; Sahita, Ravi ; xen-devel Subject: Re:

Re: [Xen-devel] [PATCH Altp2m cleanup v4 1/4] x86/HVM: adjust feature checking in MSR intercept handling

[Paul] in-line -Original Message- From: Jan Beulich [mailto:jbeul...@suse.com] Sent: Thursday, September 8, 2016 3:33 AM To: Lai, Paul C Cc: george.dun...@citrix.com; Sahita, Ravi ; xen-devel Subject: Re:

Re: [Xen-devel] [PATCH v3 1/1] xen: move TLB-flush filtering out into populate_physmap during vm creation

>>> On 08.09.16 at 07:30, wrote: > --- a/xen/include/xen/sched.h > +++ b/xen/include/xen/sched.h > @@ -474,6 +474,9 @@ struct domain > unsigned int guest_request_enabled : 1; > unsigned int guest_request_sync : 1; > } monitor; > + > +

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

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

Re: [Xen-devel] [xen-unstable test] 100789: regressions - FAIL [and 2 more messages]

On Thu, Sep 08, 2016 at 03:23:38PM +0100, Ian Jackson wrote: > Wei Liu writes ("Re: [Xen-devel] [xen-unstable test] 100789: regressions - > FAIL"): > > I see three ways to move this forward. > > > > 3. Retire these two tests. > > Do we expect users still to want VHD support ? We still allegedly

Re: [Xen-devel] [PATCH v3 1/1] xen: move TLB-flush filtering out into populate_physmap during vm creation

On 08/09/16 15:49, Dario Faggioli wrote: > On Thu, 2016-09-08 at 13:19 +0200, Juergen Gross wrote: >> The first scheduling is done via unpausing the domain. Why not >> setting >> the flag to true in that path? >> > That could be a good idea. > > And in general, I'm all for finding a place and/or a

Re: [Xen-devel] [PATCH Altp2m cleanup v4 3/4] Move altp2m specific functions to altp2m files.

>>> On 08.09.16 at 00:04, wrote: > @@ -65,6 +66,56 @@ altp2m_vcpu_destroy(struct vcpu *v) > vcpu_unpause(v); > } > > +int > +altp2m_domain_init(struct domain *d) > +{ > +int rc; > +unsigned int i; > + > +if ( !hvm_altp2m_supported() ) > +{ > +

Re: [Xen-devel] [PATCH v3 1/1] xen: move TLB-flush filtering out into populate_physmap during vm creation

On Thu, 2016-09-08 at 13:19 +0200, Juergen Gross wrote: > The first scheduling is done via unpausing the domain. Why not > setting > the flag to true in that path? > That could be a good idea. And in general, I'm all for finding a place and/or a state that better represents the condition of

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

flight 100818 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/100818/ 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] [OSSTEST PATCH v3 25/25] Create XTF branch

Wei Liu writes ("Re: [OSSTEST PATCH v3 25/25] Create XTF branch"): > On Tue, Sep 06, 2016 at 03:03:50PM +0100, Ian Jackson wrote: > > Wei Liu writes ("[OSSTEST PATCH v3 25/25] Create XTF branch"): > > > This branch contains Xen and Linux build jobs and all jobs which contain > > > xtf in their

Re: [Xen-devel] [PATCH Altp2m cleanup v4 2/4] altp2m cleanup work

>>> On 08.09.16 at 00:04, wrote: > Indent goto labels by one space > Inline (header) altp2m functions > Define default behavior in switch > Define max and min for range of altp2m macroed values > > Signed-off-by: Paul Lai > --- Missing a brief

Re: [Xen-devel] [PATCH v2] Remove ambiguities in the COPYING file; add CONTRIBUTING file

On 08/09/16 15:36, Lars Kurth wrote: >> On 16 Aug 2016, at 09:19, George Dunlap wrote: >> >> On Mon, Aug 15, 2016 at 11:24 AM, Andrew Cooper >> wrote: >>> On 12/08/16 10:37, Lars Kurth wrote: COPYING file: The motivation of this change is

Re: [Xen-devel] [PATCH 1/4] hvm/fep: Allow testing of instructions crossing the -1 -> 0 virtual boundary

On 08/09/16 15:28, Jan Beulich wrote: On 08.09.16 at 16:11, wrote: >> The Force Emulation Prefix is named to follow its PV counterpart for cpuid or >> rdtsc, but isn't really an instruction prefix. It behaves as a break-out >> into >> Xen, with the purpose of

[Xen-devel] Unable to build with gcc 6 because of etherboot

This is a follow on to a message I sent to xen-users: https://lists.xen.org/archives/html/xen-devel/2015-08/msg01924.html I am trying to compile Xen 4.7.0 with gcc 6.1.1, but I get an error related to etherboot. It was suggested to update the etherboot Makefile to the head of the etherboot

Re: [Xen-devel] [PATCH v2] Remove ambiguities in the COPYING file; add CONTRIBUTING file

> On 16 Aug 2016, at 09:19, George Dunlap wrote: > > On Mon, Aug 15, 2016 at 11:24 AM, Andrew Cooper > wrote: >> On 12/08/16 10:37, Lars Kurth wrote: >>> COPYING file: >>> The motivation of this change is to make it easier for new >>> contributors

Re: [Xen-devel] [PATCH 3/4] x86/hvm: Optimise segment accesses in hvmemul_write_segment()

>>> On 08.09.16 at 16:11, wrote: > There is no need to read the segment information from VMCS/VMCB and cache it, > just to clobber the cached content immediately afterwards. > > Write straight into the cache and set the accessed/dirty bits. > > Signed-off-by: Andrew

Re: [Xen-devel] [PATCH 1/4] hvm/fep: Allow testing of instructions crossing the -1 -> 0 virtual boundary

>>> On 08.09.16 at 16:11, wrote: > The Force Emulation Prefix is named to follow its PV counterpart for cpuid or > rdtsc, but isn't really an instruction prefix. It behaves as a break-out into > Xen, with the purpose of emulating the next instruction in the current

Re: [Xen-devel] [PATCH v3 1/1] xen: move TLB-flush filtering out into populate_physmap during vm creation

Wei Liu writes ("Re: [PATCH v3 1/1] xen: move TLB-flush filtering out into populate_physmap during vm creation"): > On Thu, Sep 08, 2016 at 01:01:40PM +0200, Dario Faggioli wrote: > > On Thu, 2016-09-08 at 11:50 +0100, Wei Liu wrote: > > > On Thu, Sep 08, 2016 at 01:30:03PM +0800, Dongli Zhang

Re: [Xen-devel] [PATCH 3/4] x86/hvm: Optimise segment accesses in hvmemul_write_segment()

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

Re: [Xen-devel] [PATCH v3 12/19] libacpi: Build DSDT for PVH guests

>>> On 07.09.16 at 20:59, wrote: > @@ -32,15 +32,22 @@ $(H_SRC): $(ACPI_BUILD_DIR)/%.h: %.asl iasl > $(MK_DSDT): mk_dsdt.c > $(HOSTCC) $(HOSTCFLAGS) $(CFLAGS_xeninclude) -o $@ mk_dsdt.c > > -$(ACPI_BUILD_DIR)/dsdt_anycpu_qemu_xen.asl: dsdt.asl $(MK_DSDT) >

[Xen-devel] [PATCH 4/4] x86/hvm: Perform a user instruction fetch for a FEP in userspace

This matches hardware behaviour, and prevents erroneous failures when a guest has SMEP/SMAP active and issues a FEP from userspace. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich --- xen/arch/x86/hvm/hvm.c | 4 +++- 1 file changed, 3

Re: [Xen-devel] [PATCH v3 18/19] libxl/acpi: Build ACPI tables for HVMlite guests

>>> On 07.09.16 at 20:59, wrote: > Signed-off-by: Boris Ostrovsky > --- > Changes in v3: > * Some constification of call parameters > * Format adjustments > * New acpi_mem_free hook (a nop) > * Changes in init_acpi_config() to deal with

[Xen-devel] [PATCH 3/4] x86/hvm: Optimise segment accesses in hvmemul_write_segment()

There is no need to read the segment information from VMCS/VMCB and cache it, just to clobber the cached content immediately afterwards. Write straight into the cache and set the accessed/dirty bits. Signed-off-by: Andrew Cooper --- CC: Jan Beulich

[Xen-devel] [PATCH 1/4] hvm/fep: Allow testing of instructions crossing the -1 -> 0 virtual boundary

The Force Emulation Prefix is named to follow its PV counterpart for cpuid or rdtsc, but isn't really an instruction prefix. It behaves as a break-out into Xen, with the purpose of emulating the next instruction in the current state. It is important to be able to test legal situations which

[Xen-devel] [PATCH 2/4] x86/segment: Bounds check accesses to emulation ctxt->seg_reg[]

HVM HAP codepaths have space for all segment registers in the seg_reg[] cache (with x86_seg_none still risking an array overrun), while the shadow codepaths only have space for the user segments. Range check the input segment of *_get_seg_reg() against the size of the array used to cache the

Re: [Xen-devel] [xen-unstable test] 100789: regressions - FAIL [and 2 more messages]

Wei Liu writes ("Re: [Xen-devel] [xen-unstable test] 100789: regressions - FAIL"): > I see three ways to move this forward. > > 3. Retire these two tests. Do we expect users still to want VHD support ? We still allegedly support VHD for guests. So we shouldn't retire these tests unless we are

Re: [Xen-devel] [PATCH v3 13/19] acpi: Makefile should better tolerate interrupts

>>> On 07.09.16 at 20:59, wrote: > Intermediate stages of building a target should be made with > temporary files that are copied to final target in the end. > > Signed-off-by: Boris Ostrovsky > --- > New in v3 Ah, here we go. > ---

Re: [Xen-devel] [PATCH v2] xen/pciback: support driver_override

On 09/02/2016 08:30 AM, Juergen Gross wrote: > Support the driver_override scheme introduced with commit 782a985d7af2 > ("PCI: Introduce new device binding path using pci_dev.driver_override") > > As pcistub_probe() is called for all devices (it has to check for a > match based on the slot address

Re: [Xen-devel] [PATCH v3 09/19] acpi/hvmloader: Include file/paths adjustments

>>> On 07.09.16 at 20:59, wrote: > In prepearation to moving acpi sources into generally available > libacpi: > > 1. Pass IOAPIC/LAPIC/PCI mask values via struct acpi_config > 2. Modify include files search paths to point to acpi directory > 3. Macro-ise include file

Re: [Xen-devel] [PATCH v3 08/19] acpi/hvmloader: Link ACPI object files directly

>>> On 07.09.16 at 20:59, wrote: > ACPI sources will be available to various component which will build > them according to their own rules. ACPI's Makefile will only generate > necessary source files. > > Signed-off-by: Boris Ostrovsky

Re: [Xen-devel] [PATCH 4/5] x86/emulate: add support for {, v}movq xmm, xmm/m64

On Thursday 08 September 2016 07:45:19 Jan Beulich wrote: > From: Mihai Donțu > > Signed-off-by: Mihai Donțu > Signed-off-by: Jan Beulich > --- > v4: Re-base on decoding changes. Address my own review comments (where >

Re: [Xen-devel] [PATCH v3 06/19] acpi/hvmloader: Replace mem_alloc() and virt_to_phys() with memory ops

>>> On 07.09.16 at 20:59, wrote: > Components that wish to use ACPI builder will need to provide their own > mem_alloc() and virt_to_phys() routines. Pointers to these routines will > be passed to the builder as memory ops. > > Signed-off-by: Boris Ostrovsky

[Xen-devel] [PATCH 4/5] x86/emulate: add support for {, v}movq xmm, xmm/m64

From: Mihai Donțu Signed-off-by: Mihai Donțu Signed-off-by: Jan Beulich --- v4: Re-base on decoding changes. Address my own review comments (where still applicable). #UD when vex.l is set. Various adjustments to the

[Xen-devel] [PATCH 5/5] x86/emulate: add support for {, v}movd {, x}mm, r/m32 and {, v}movq {, x}mm, r/m64

From: Zhi Wang Found that Windows driver was using a SSE2 instruction MOVD. Signed-off-by: Zhi Wang Signed-off-by: Mihai Donțu Signed-off-by: Jan Beulich --- v4: Re-base on decoding changes. Address

[Xen-devel] [PATCH 3/5] x86emul: support RTM instructions

Minimal emulation: XBEGIN aborts right away, hence - XABORT is just a no-op, - XEND always raises #GP, - XTEST always signals neither RTM nor HLE are active. Signed-off-by: Jan Beulich --- a/xen/arch/x86/x86_emulate/x86_emulate.c +++ b/xen/arch/x86/x86_emulate/x86_emulate.c

[Xen-devel] [PATCH 1/5] x86emul: support UMIP

To make this complete, also add support for SLDT and STR. Note that by just looking at the guest CR4 bit, this is independent of actually making available the UMIP feature to guests. Signed-off-by: Jan Beulich --- a/xen/arch/x86/x86_emulate/x86_emulate.c +++

[Xen-devel] [PATCH 2/5] x86emul: consolidate segment register handling

Use a single set of variables throughout the huge switch() statement, allowing to funnel SLDT/STR into the mov-from-sreg code path. Signed-off-by: Jan Beulich --- a/xen/arch/x86/x86_emulate/x86_emulate.c +++ b/xen/arch/x86/x86_emulate/x86_emulate.c @@ -2494,7 +2494,8 @@

Re: [Xen-devel] [PATCH v3 02/19] acpi/hvmloader: Collect processor and NUMA info in hvmloader

>>> On 07.09.16 at 20:59, wrote: > Changes in v3: > * Constified acpi_numa's pointers > * Constified acpi_config call parameter where possible Thanks, but how about ... > --- a/tools/firmware/hvmloader/acpi/build.c > +++ b/tools/firmware/hvmloader/acpi/build.c > @@

[Xen-devel] [PATCH 0/5] x86: further insn emulator improvements

These are really independent of and I prefer them to be a separate series, but won't apply without that one in place. The final two I decided to pick up from Mihai, as it seemed natural for me to do the rebasing on top of the major earlier changes, and as I'd like to get the original issue

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

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

Re: [Xen-devel] [PATCH 07/17] x86emul: move x86_execute() common epilogue code

>>> On 08.09.16 at 15:13, wrote: > Only code movement, no functional change. > > Signed-off-by: Jan Beulich Just noticed the title was left stale - should really be "x86emul: move x86_emulate() common epilogue code". Jan

[Xen-devel] [PATCH 17/17] x86emul: don't assume a memory operand

Especially for x86_insn_operand_ea() to return dependable segment information even when the caller didn't consider applicability we shouldn't have ea.type start out as OP_MEM. Make it OP_NONE instead, and set it to OP_MEM when we actually encounter memory like operands. This requires to eliminate

[Xen-devel] [PATCH 16/17] x86/PV: use generic emulator for privileged instruction handling

There's a new emulator return code being added to allow bypassing certain operations (see the code comment). Its handling in the epilogue code involves moving the raising of the single step trap until after registers were updated. This should probably have been that way from the beginning, to

[Xen-devel] [PATCH 15/17] x86emul: sort opcode 0f01 special case switch() statement

Sort the special case opcode 0f01 entries numerically, insert blank lines between each of the cases, and properly place opening braces. Signed-off-by: Jan Beulich --- a/xen/arch/x86/x86_emulate/x86_emulate.c +++ b/xen/arch/x86/x86_emulate/x86_emulate.c @@ -4192,6 +4192,14 @@

Re: [Xen-devel] [PATCH 04/17] x86emul: track only rIP in emulator state

>>> On 08.09.16 at 15:08, wrote: Please disregard this one - it got sent out with the wrong number in the subject. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

[Xen-devel] [PATCH 13/17] x86/PV: split out dealing with MSRs from privileged instruction handling

This is in preparation for using the generic emulator here. Signed-off-by: Jan Beulich --- a/xen/arch/x86/traps.c +++ b/xen/arch/x86/traps.c @@ -2373,6 +2373,332 @@ static inline uint64_t guest_misc_enable return val; } +static inline bool is_cpufreq_controller(const

[Xen-devel] [PATCH 12/17] x86/PV: split out dealing with DRn from privileged instruction handling

This is in preparation for using the generic emulator here. Some care is needed temporarily to not unduly alter guest register state: The local variable "res" can only go away once this code got fully switched over to using x86_emulate(). Also switch to IS_ERR_VALUE() instead of (incorrectly)

[Xen-devel] [PATCH 11/17] x86/PV: split out dealing with CRn from privileged instruction handling

This is in preparation for using the generic emulator here. Signed-off-by: Jan Beulich --- a/xen/arch/x86/traps.c +++ b/xen/arch/x86/traps.c @@ -2242,6 +2242,107 @@ unsigned long guest_to_host_gpr_switch(u void (*pv_post_outb_hook)(unsigned int port, u8 value); +static

[Xen-devel] [PATCH 10/17] x86/32on64: use generic instruction decoding for call gate emulation

... instead of custom handling. Note that we can't use generic emulation, as the emulator's far branch support is rather rudimentary at this point in time. Signed-off-by: Jan Beulich --- a/xen/arch/x86/traps.c +++ b/xen/arch/x86/traps.c @@ -28,6 +28,7 @@ #include #include

[Xen-devel] [PATCH 09/17] SVM: use generic instruction decoding

... instead of custom handling. To facilitate this break out init code from _hvm_emulate_one() into the new hvm_emulate_init(), and make hvmemul_insn_fetch( globally available. Signed-off-by: Jan Beulich --- a/xen/arch/x86/hvm/emulate.c +++ b/xen/arch/x86/hvm/emulate.c @@

[Xen-devel] [PATCH 08/17] x86emul: generate and make use of canonical opcode representation

This representation is then being made available to interested callers, to facilitate replacing their custom decoding. This entails combining the three main switch statements into one. Signed-off-by: Jan Beulich --- a/tools/tests/x86_emulator/x86_emulate.c +++

[Xen-devel] [PATCH 07/17] x86emul: move x86_execute() common epilogue code

Only code movement, no functional change. Signed-off-by: Jan Beulich --- This is just to ease review of a later patch. --- a/xen/arch/x86/x86_emulate/x86_emulate.c +++ b/xen/arch/x86/x86_emulate/x86_emulate.c @@ -4111,56 +4111,7 @@ x86_emulate( default: goto

[Xen-devel] [PATCH 06/17] x86emul: add EVEX decoding

This way we can at least size (and e.g. skip) them if needed, and we also won't raise the wrong fault due to not having read all relevant bytes. Signed-off-by: Jan Beulich --- TBD: I'm kind of undecided whether to right away propagate evex.R into modrm_reg (and then also

[Xen-devel] [PATCH 04/17] x86emul: complete decoding of two-byte instructions

This way we can at least size (and e.g. skip) them if needed, and we also won't raise the wrong fault due to not having read all relevant bytes. This at once adds correct raising of #UD for the three "ud" flavors (Intel names only "ud2", but AMD names all three of them in their opcode maps), as

[Xen-devel] [PATCH 05/17] x86emul: add XOP decoding

This way we can at least size (and e.g. skip) them if needed, and we also won't raise the wrong fault due to not having read all relevant bytes. Signed-off-by: Jan Beulich --- a/xen/arch/x86/x86_emulate/x86_emulate.c +++ b/xen/arch/x86/x86_emulate/x86_emulate.c @@ -279,6

[Xen-devel] [PATCH 03/17] x86emul: track only rIP in emulator state

Now that all decoding happens in x86_decode() there's no need to keep the local registers copy in struct x86_emulate_state. Only rIP gets updated in the decode phase, so only that register needs tracking there. All other (read-only) registers can be read from the original structure (but sadly, due

[Xen-devel] [PATCH 04/17] x86emul: track only rIP in emulator state

Now that all decoding happens in x86_decode() there's no need to keep the local registers copy in struct x86_emulate_state. Only rIP gets updated in the decode phase, so only that register needs tracking there. All other (read-only) registers can be read from the original structure (but sadly, due

[Xen-devel] [PATCH 02/17] x86emul: fetch all insn bytes during the decode phase

This way we can offer to callers the service of just sizing instructions, and we also can better guarantee not to raise the wrong fault due to not having read all relevant bytes. Signed-off-by: Jan Beulich --- a/xen/arch/x86/x86_emulate/x86_emulate.c +++

[Xen-devel] [PATCH 01/17] x86emul: split instruction decoding from execution

This is only the mechanical part, a subsequent patch will make non- mechanical adjustments to actually do all decoding in this new function. Signed-off-by: Jan Beulich --- a/xen/arch/x86/x86_emulate/x86_emulate.c +++ b/xen/arch/x86/x86_emulate/x86_emulate.c @@ -48,7 +48,9 @@

[Xen-devel] [xen-unstable test] 100803: regressions - FAIL

flight 100803 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/100803/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt-vhd 9 debian-di-installfail REGR. vs. 100773

Re: [Xen-devel] [xen-unstable test] 100789: regressions - FAIL

On Thu, Sep 08, 2016 at 10:43:59AM +0100, Wei Liu wrote: > On Thu, Sep 08, 2016 at 05:32:00AM +, osstest service owner wrote: > > flight 100789 xen-unstable real [real] > > http://logs.test-lab.xenproject.org/osstest/logs/100789/ > > > > Regressions :-( > > > > Tests which did not succeed

[Xen-devel] [PATCH 00/17] x86: split insn emulator decode and execution

..., complete the decoder, leverage decoding for SVM instruction sizing and PV 32-bit call gate emulation, and use the emulator for PV priv-op handling. 01: x86emul: split instruction decoding from execution 02: x86emul: fetch all insn bytes during the decode phase 03: x86emul: track only rIP in

Re: [Xen-devel] [PATCH] fix EFI part of "symbols: Generate an xen-sym.map"

On Thu, Sep 08, 2016 at 06:45:36AM -0600, Jan Beulich wrote: > Commit 6ea24e53f1 introduced two problems: It left out a semicolon and > typo-ed the source file name of the EFI map file install command. > > Signed-off-by: Jan Beulich > Acked-by: Wei Liu

[Xen-devel] [xen-unstable-smoke test] 100812: regressions - trouble: blocked/broken/pass

flight 100812 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/100812/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf 4 host-build-prep fail REGR. vs. 100800 Tests which

[Xen-devel] [PATCH] fix EFI part of "symbols: Generate an xen-sym.map"

Commit 6ea24e53f1 introduced two problems: It left out a semicolon and typo-ed the source file name of the EFI map file install command. Signed-off-by: Jan Beulich --- a/xen/Makefile +++ b/xen/Makefile @@ -67,7 +67,7 @@ _install: $(TARGET)$(CONFIG_XEN_INSTALL_ if [ -r

[Xen-devel] Xen Security Advisory 187 (CVE-2016-7094) - x86 HVM: Overflow of sh_ctxt->seg_reg[]

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xen Security Advisory CVE-2016-7094 / XSA-187 version 3 x86 HVM: Overflow of sh_ctxt->seg_reg[] UPDATES IN VERSION 3 Fix the backports xsa187-4.6-0002-*.patch and

[Xen-devel] Xen Security Advisory 188 (CVE-2016-7154) - use after free in FIFO event channel code

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xen Security Advisory CVE-2016-7154 / XSA-188 version 3 use after free in FIFO event channel code UPDATES IN VERSION 3 Public release. ISSUE DESCRIPTION

  1   2   >