flight 100821 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100821/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 27733778fc6a855e0dfde2071f011f3d7b394867
baseline version:
ovmf d74135cd0f8d00d2126df
On 9/9/2016 1:26 PM, Yu Zhang wrote:
>>> On 02.09.16 at 12:47, wrote:
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -95,6 +95,41 @@ static const struct hvm_io_handler null_handler = {
> .ops = &null_ops
> };
>
> +static int mem_read(const struct hvm_io_handl
On 08/09/16 16:10, Boris Ostrovsky wrote:
> 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 t
On 9/9/2016 1:24 PM, Yu Zhang wrote:
On 9/2/2016 6:47 PM, Yu Zhang wrote:
Routine hvmemul_do_io() may need to peek the p2m type of a gfn to
select the ioreq server. For example, operations on gfns with
p2m_ioreq_server type will be delivered to a corresponding ioreq
server, and this requires
On 9/5/2016 9:31 PM, Jan Beulich wrote:
On 02.09.16 at 12:47, wrote:
@@ -178,8 +179,27 @@ static int hvmemul_do_io(
break;
case X86EMUL_UNHANDLEABLE:
{
-struct hvm_ioreq_server *s =
-hvm_select_ioreq_server(curr->domain, &p);
+struct hvm_ioreq
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 which
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 is
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
test-amd64-i386-xl-qemut
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 xentrac
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
tes
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
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
Regress
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
test-amd64-i386
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 v
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 acp
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
>> ---
>> New in v3
> Ah, here we go.
>
>> --- a/tools/l
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) {
>
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
test-amd64-amd64-xl-qemuu-
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 @
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 wrong
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 we
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 present
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 who
[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: [PATCH Altp2m cleanup v4 3/4] Move altp2m specific functions to
altp2m files.
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 1
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
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
Xen-devel@lists.
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, i
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 an
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
Cc: ian.jack...@eu.ci
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
>
> This
[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 ;
george.dun...@citrix.com
Subject: Re: [Xen-devel] [PATCH Altp2m cleanup v4 2/4] altp2m clea
>>> 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 start building ld with PE sup
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
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
>
> Subject: Re: [PATCH Altp2m
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 v
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 : 1;
> > unsigned
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
---
Osstest/TestSupport.pm | 3 ++
[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: [PATCH Altp2m cleanup v4 2/4] altp2m cleanup work
>>> On 08.09.16 at 00:04, wro
[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: [PATCH Altp2m cleanup v4 1/4] x86/HVM: adjust feature checking in
MSR intercept h
>>> 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;
> +
> +/* set to 1 the first
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 guest-
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
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
>>> 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() )
> +{
> +rc = 0;
> +
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 "sett
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 1
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 name
>>> 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 summary of changes from previous version here.
> @
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 to make it easier for new
contributors to c
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 emulating the next instruction
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 reposit
> 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 to conduct a license and patent review, WITHOUT
>>> 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 Cooper
Reviewed-by: Jan Beu
>>> 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 state.
>
> It is important to
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 wro
> -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: [PATCH 3/4] x86/hvm: Optimise segment accesses in
> hvmemul_write_segment()
>
> There is no need to
>>> 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)
> +$(ACPI_BUILD_DIR)/dsdt_anycpu_q
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 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x8
>>> 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 constified acpi_numa's
> pointers (initialize pointers as
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
CC: Paul Durrant
---
xen/arch/x86/hvm/emulat
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 occur
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 resul
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 d
>>> 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.
> --- a/tools/libacpi/Makefile
> +++ b/tools/libacpi/Makefile
> @@
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
>>> 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 for build.c that defines vari
>>> 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
Acked-by: Jan Beulich
_
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
> still applicable). #UD when vex.l is set. Various adjustments to
> t
>>> 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
Acked-by: Jan Beulich
Albeit I'd p
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 test tool change.
--- a/tools/tests/x86_emulator/test_x86_emulator.c
+
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 Andrew's and my own review
comments (where still applicable). #UD when vex.l is set. Vario
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
@@ -1172,6 +1172,8 @@
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
+++ b/xen/arch/x86/x86_emulate/x86_emulat
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 @@ x86_emulate(
switc
>>> 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
> @@ -70,18 +70,20 @@ static void s
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 (certai
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 4ac14ceae076439dcea92
>>> 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 mailing list
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
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 allow
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 @@ x86_emulate(
>>> 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
This is a prereq for switching PV privileged op emulation to the
generic instruction emulator. Since handle_xsetbv() is already capable
of dealing with all guest kinds, avoid introducing another hook here.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86
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 struct domain *d)
+{
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) ope
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 int priv_op_read_cr(u
... 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
#include
+#includ
... 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
@@ -835,7 +835,7 @@ static
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
+++ b/tools/tests/x86_emulator/x86_emu
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 cannot_emulate;
}
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 deal with the new me
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 th
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 +279,12 @@ static const
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
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
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
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
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 @@
/* All operands are
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
test-armhf-armhf-x
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 and
1 - 100 of 150 matches
Mail list logo