This run is configured for baseline tests only.
flight 75057 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75057/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75055
test
flight 125836 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125836/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
Regressions wh
flight 125830 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125830/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 3781f14c31e00f4f1a195c7ad427be4f84f5cdf5
baseline version:
ovmf 9e6c4f1527e6f72d6ada1
flight 125833 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125833/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
Regressions wh
flight 125815 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125815/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-xsm
flight 125809 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125809/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-pvops
Hi Juergen,
I love your patch! Perhaps something to improve:
[auto build test WARNING on block/for-next]
[also build test WARNING on v4.18-rc8 next-20180809]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci
flight 125831 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125831/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
Tests which ar
Fixes: 5bed25379565 ("xen/blkback: don't keep persistent grants too long")
Signed-off-by: kbuild test robot
---
blkback.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/block/xen-blkback/blkback.c
b/drivers/block/xen-blkback/blkback.c
index f341ac8..9eae7b24 1006
flight 125804 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125804/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken
build-arm64
On Thu, Aug 09, 2018 at 02:42:13PM -0500, Brian Woods wrote:
> @@ -237,8 +247,8 @@ static void __init print_details(enum ind_thunk thunk,
> uint64_t caps)
> - !boot_cpu_has(X86_FEATURE_SSBD_AMD_LS_CFG)? "" :
> - (opt_ssbd && ssbd_amd_ls_cfg_mask)? " SSBD+" : " SSBD-",
>
This series of patches is for enabling SSBD via the LS_CFG MSR for
family 15h-17h. The first patch make it so that the information is
correctly displayed on boot. The last patch is for further enablement
for Xen switching SSBD on or off internally, or for further control of
SSBD for guests via th
Adds support for modifying the LS_CFG MSR to enable SSBD on supporting
AMD CPUs. There needs to be locking logic for family 17h with SMT
enabled since both threads share the same MSR. Otherwise, a core just
needs to write to the LS_CFG MSR. For more information see:
https://developer.amd.com/wp-
Edit the initialization code for AMD's SSBD via the LS_CFG MSR and
enable it to pass the status to the initial spec-ctrl print_details at
boot.
Signed-off-by: Brian Woods
---
xen/arch/x86/cpu/amd.c| 13 ++---
xen/arch/x86/spec_ctrl.c | 9 +++--
xen/include/asm-x
flight 125829 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125829/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
Regressions wh
Hi Julien.
On Thu, Aug 9, 2018 at 7:20 PM, Julien Grall wrote:
>
>
> On 08/09/2018 05:18 PM, Oleksandr Tyshchenko wrote:
>>
>> On Thu, Aug 9, 2018 at 7:10 PM, Julien Grall wrote:
>>>
>>> Somehow I thought the platform was 64-bit and found a SOC name very
>>> similar
>>> to it. Sorry for the conf
As it currently stands, 'xpti=dom0' is indistinguishable from the default
value, which means it will be overridden by ARCH_CAPABILITIES_RDCL_NO on fixed
hardware.
Switch opt_xpti to use -1 as a default like all our other related options, and
clobber it as soon as we have a string to parse.
In add
On Mon, Aug 6, 2018 at 10:22 PM Marek Marczykowski-Górecki
wrote:
>
> From: Eric Shelton
>
> This patch creates an appropriate command line for the QEMU instance
> running in a Linux-based stubdomain.
>
> NOTE: a number of items are not currently implemented for Linux-based
> stubdomains, such as
On 08/09/2018 05:18 PM, Oleksandr Tyshchenko wrote:
On Thu, Aug 9, 2018 at 7:10 PM, Julien Grall wrote:
Somehow I thought the platform was 64-bit and found a SOC name very similar
to it. Sorry for the confusion. PSCI seems indeed not supported for that
platform.
R-Car Gen3 is ARM64 (H2 SoC -
On Thu, Aug 9, 2018 at 7:10 PM, Julien Grall wrote:
> Hi Oleksandr,
Hi Julien.
>
>
> On 08/07/2018 08:13 PM, Oleksandr Tyshchenko wrote:
>>
>> On Tue, Aug 7, 2018 at 8:21 PM, Julien Grall wrote:
>>>
>>> On 07/08/18 18:12, Oleksandr Tyshchenko wrote:
Hi, Julien
>>>
>>>
>>>
>>> Hi O
On Thu, Aug 9, 2018 at 7:18 PM, Oleksandr Tyshchenko
wrote:
> On Thu, Aug 9, 2018 at 7:10 PM, Julien Grall wrote:
>> Hi Oleksandr,
> Hi Julien.
Hi.
>
>>
>>
>> On 08/07/2018 08:13 PM, Oleksandr Tyshchenko wrote:
>>>
>>> On Tue, Aug 7, 2018 at 8:21 PM, Julien Grall wrote:
On 07/08/18 18
flight 125828 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125828/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
Regressions wh
Hi Oleksandr,
On 08/07/2018 08:13 PM, Oleksandr Tyshchenko wrote:
On Tue, Aug 7, 2018 at 8:21 PM, Julien Grall wrote:
On 07/08/18 18:12, Oleksandr Tyshchenko wrote:
Hi, Julien
Hi Oleksandr,
Hi Julien
On Tue, Aug 7, 2018 at 6:18 PM, Julien Grall wrote:
Hi,
On 06/08/18 19:35, Ole
On Thu, Aug 09, 2018 at 10:50:13AM +0100, Andrew Cooper wrote:
> Firstly, there is no 'offset' boundary check on the non-32-bit write path
> before the call to vlapic_read_aligned(), which allows an attacker to read
> beyond the end of vlapic->regs->data[], which is only 1024 bytes long.
>
> Howev
On Thu, Aug 09, 2018 at 04:42:16PM +0200, Juergen Gross wrote:
> skb_shinfo() can change when calling __pskb_pull_tail(): Don't cache
> its return value.
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Juergen Gross
Reviewed-by: Wei Liu
___
Xen-devel
skb_shinfo() can change when calling __pskb_pull_tail(): Don't cache
its return value.
Cc: sta...@vger.kernel.org
Signed-off-by: Juergen Gross
---
drivers/net/xen-netfront.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-n
flight 125800 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125800/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-pvops
flight 125826 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125826/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
Regressions wh
On Wed, 2018-08-08 at 10:35 -0700, Sarah Newman wrote:
> commit b3681dd548d06deb2e1573890829dff4b15abf46 upstream.
>
> This version applies to v4.9.
I think you can kill the 'xorl %ebx,%ebx' from error_entry too but yes,
this does want to go to 4.9 and earlier because the 'Fixes:' tag is a
bit of
On Mi, 2018-07-25 at 04:37 -0600, Jan Beulich wrote:
> >
> > >
> > > >
> > > > On 25.07.18 at 11:25, wrote:
> > On 07/24/2018 01:02 PM, Jan Beulich wrote:
> > >
> > > >
> > > > >
> > > > > >
> > > > > > On 24.07.18 at 13:26, wrote:
> > > > On 07/24/2018 09:55 AM, Jan Beulich wrote:
> > > >
>>> On 09.08.18 at 11:50, wrote:
> Firstly, there is no 'offset' boundary check on the non-32-bit write path
> before the call to vlapic_read_aligned(), which allows an attacker to read
> beyond the end of vlapic->regs->data[], which is only 1024 bytes long.
>
> However, as the backing memory is
>>> On 09.08.18 at 12:51, wrote:
> On Thu, Aug 09, 2018 at 04:29:51AM -0600, Jan Beulich wrote:
>> >>> On 09.08.18 at 12:01, wrote:
>> > In fact I think this would be clearer if something like:
>> >
>> > enum {
>> > NONE,
>> > RELAXED,
>> > STRICT,
>> > } iommu_hwdom = RELAXED;
>> >
> -Original Message-
> From: Andrew Cooper
> Sent: 09 August 2018 12:22
> To: Paul Durrant ; Xen-devel de...@lists.xen.org>
> Cc: Jan Beulich ; Stefano Stabellini
> ; Julien Grall ; Wei Liu
> ; Roger Pau Monne ; George
> Dunlap
> Subject: Re: [PATCH] common/gnttab: Explicitly default to g
On 09/08/18 12:17, Paul Durrant wrote:
>>
which rearranges large chunks of DOMCTL_createdomain
---
xen/common/grant_table.c | 40 +++-
1 file changed, 7 insertions(+), 33 deletions(-)
diff --git a/xen/common/grant_table.c b/xen/comm
> -Original Message-
> From: Andrew Cooper
> Sent: 09 August 2018 12:14
> To: Paul Durrant ; Xen-devel de...@lists.xen.org>
> Cc: Jan Beulich ; Stefano Stabellini
> ; Julien Grall ; Wei Liu
> ; Roger Pau Monne ; George
> Dunlap
> Subject: Re: [PATCH] common/gnttab: Explicitly default to g
On 09/08/18 11:41, Paul Durrant wrote:
>> -Original Message-
>> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
>> Sent: 09 August 2018 11:32
>> To: Xen-devel
>> Cc: Andrew Cooper ; Jan Beulich
>> ; Paul Durrant ; Stefano
>> Stabellini ; Julien Grall ; Wei
>> Liu ; Roger Pau Monne ;
On 09/08/18 11:55, Roger Pau Monné wrote:
> On Thu, Aug 09, 2018 at 11:31:58AM +0100, Andrew Cooper wrote:
>> For reasons which appear to be exclusively down to poor review of the grant
>> table v2 code, a grant table's version field was wasn't initialised during
>> creation.
>>
>> A number of prob
Am Thu, 9 Aug 2018 10:22:51 +
schrieb Paul Durrant :
> Oh sorry, I see the xen version is just staging. Still need the dom0 kernel
> version though.
Kernel 4.4, SLE12SP3.
Olaf
pgpe1ke1wdMmx.pgp
Description: Digitale Signatur von OpenPGP
___
Xen-
On Thu, Aug 09, 2018 at 11:31:58AM +0100, Andrew Cooper wrote:
> For reasons which appear to be exclusively down to poor review of the grant
> table v2 code, a grant table's version field was wasn't initialised during
> creation.
>
> A number of problems (including XSAs) have occurred in the past
On Thu, Aug 09, 2018 at 04:29:51AM -0600, Jan Beulich wrote:
> >>> On 09.08.18 at 12:01, wrote:
> > On Thu, Aug 09, 2018 at 01:00:59AM -0600, Jan Beulich wrote:
> >> >>> On 08.08.18 at 17:50, wrote:
> >> > On Wed, Aug 08, 2018 at 06:10:39AM -0600, Jan Beulich wrote:
> >> >> >>> On 08.08.18 at 12:
> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: 09 August 2018 11:32
> To: Xen-devel
> Cc: Andrew Cooper ; Jan Beulich
> ; Paul Durrant ; Stefano
> Stabellini ; Julien Grall ; Wei
> Liu ; Roger Pau Monne ;
> George Dunlap
> Subject: [PATCH] common/gnt
>>> On 09.08.18 at 12:31, wrote:
> For reasons which appear to be exclusively down to poor review of the grant
> table v2 code, a grant table's version field was wasn't initialised during
> creation.
>
> A number of problems (including XSAs) have occurred in the past trying trying
> to use a gran
>>> On 09.08.18 at 12:23, wrote:
> On Thu, Aug 09, 2018 at 01:36:57AM -0600, Jan Beulich wrote:
>> >>> On 08.08.18 at 18:18, wrote:
>> > On Wed, Aug 08, 2018 at 07:15:54AM -0600, Jan Beulich wrote:
>> >> >>> On 08.08.18 at 12:07, wrote:
>> >> > +/*
>> >> > + * If dom0-strict mode is enab
For reasons which appear to be exclusively down to poor review of the grant
table v2 code, a grant table's version field was wasn't initialised during
creation.
A number of problems (including XSAs) have occurred in the past trying trying
to use a grant table which hasn't been properly set up, and
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 09 August 2018 11:24
> To: Paul Durrant
> Cc: Andrew Cooper ; Wei Liu
> ; George Dunlap ; Ian
> Jackson ; Stefano Stabellini
> ; xen-devel ;
> Konrad Rzeszutek Wilk ; Tim (Xen.org)
>
> Subject: Re: [PATCH v23 1/2]
>>> On 09.08.18 at 12:01, wrote:
> On Thu, Aug 09, 2018 at 01:00:59AM -0600, Jan Beulich wrote:
>> >>> On 08.08.18 at 17:50, wrote:
>> > On Wed, Aug 08, 2018 at 06:10:39AM -0600, Jan Beulich wrote:
>> >> >>> On 08.08.18 at 12:07, wrote:
>> >> > +Note that all the above options are mutually exclu
flight 125823 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125823/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
Regressions wh
flight 125799 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125799/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-xsm
On Thu, Aug 09, 2018 at 01:36:57AM -0600, Jan Beulich wrote:
> >>> On 08.08.18 at 18:18, wrote:
> > On Wed, Aug 08, 2018 at 07:15:54AM -0600, Jan Beulich wrote:
> >> >>> On 08.08.18 at 12:07, wrote:
> >> > @@ -134,13 +135,67 @@ void arch_iommu_domain_destroy(struct domain *d)
> >> > {
> >> > }
>>> On 09.08.18 at 11:59, wrote:
> +static int gnttab_get_status_frame_mfn(struct domain *d,
> + unsigned long idx, mfn_t *mfn)
> +{
> +const struct grant_table *gt = d->grant_table;
> +
> +ASSERT(gt->gt_version == 2);
> +
> +if ( idx >= nr_status_
> -Original Message-
> From: Paul Durrant
> Sent: 09 August 2018 11:22
> To: 'Olaf Hering' ; xen-de...@lists.xen.org
> Subject: RE: [Xen-devel] qemu-3.0 fails with staging
>
> > -Original Message-
> > From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On
> Behalf
> > O
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Olaf Hering
> Sent: 09 August 2018 10:03
> To: xen-de...@lists.xen.org
> Subject: [Xen-devel] qemu-3.0 fails with staging
>
> This domU.cfg fails for me with staging+qemu-3.0, but qemu-2.1
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Jan Beulich
> Sent: 09 August 2018 08:01
> To: Roger Pau Monne
> Cc: Kevin Tian ; Stefano Stabellini
> ; Wei Liu ; George Dunlap
> ; Andrew Cooper
> ; Ian Jackson ; Tim
> (Xen.org) ; Julie
On Thu, Aug 09, 2018 at 01:00:59AM -0600, Jan Beulich wrote:
> >>> On 08.08.18 at 17:50, wrote:
> > On Wed, Aug 08, 2018 at 06:10:39AM -0600, Jan Beulich wrote:
> >> >>> On 08.08.18 at 12:07, wrote:
> >> > +Note that all the above options are mutually exclusive. Specifying more
> >> > than
> >>
This patch allows grant table frames to be mapped using the
XENMEM_acquire_resource memory op.
NOTE: This patch expands the on-stack mfn_list array in acquire_resource()
but it is still small enough to remain on-stack.
NOTE: This patch also removes a bogus comment above the
grant_to_s
A previous patch added support for priv-mapping guest resources directly
(rather than having to foreign-map, which requires P2M modification for
HVM guests).
This patch makes use of the new API to seed the guest grant table unless
the underlying infrastructure (i.e. privcmd) doesn't support it, in
These patches are the patches from my original resource mapping series
that did not make it into 4.11.
Paul Durrant (2):
common: add a new mappable resource type: XENMEM_resource_grant_table
tools/libxenctrl: use new xenforeignmemory API to seed grant table
tools/libxc/include/xc_dom.h
Firstly, there is no 'offset' boundary check on the non-32-bit write path
before the call to vlapic_read_aligned(), which allows an attacker to read
beyond the end of vlapic->regs->data[], which is only 1024 bytes long.
However, as the backing memory is a domheap page, and misaligned accesses get
>>> On 09.08.18 at 11:13, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 09 August 2018 10:07
>>
>> >>> On 09.08.18 at 10:55, wrote:
>> > Also, the grant table would have potentially grown even though the op will
>> > fail. Is that what's concerning you?
>>
>> But a failure pos
On Tue, Aug 07, 2018 at 04:16:08AM +0200, Marek Marczykowski-Górecki wrote:
> From: Eric Shelton
>
> This patch creates an appropriate command line for the QEMU instance
> running in a Linux-based stubdomain.
>
> NOTE: a number of items are not currently implemented for Linux-based
> stubdomains
flight 75056 distros-debian-wheezy real [real]
http://osstest.xensource.com/osstest/logs/75056/
Perfect :-)
All tests in this flight passed as required
baseline version:
flight 75038
jobs:
build-amd64 pass
build-armhf
On Tue, Aug 07, 2018 at 04:16:07AM +0200, Marek Marczykowski-Górecki wrote:
> From: Eric Shelton
>
> This enum gives the ability to select between a MiniOS-based QEMU
> traditional stub domain and a Linux-based QEMU upstream stub domain. To
> use the Linux-based stubdomain, the following two lin
This is used to save data from a single instance.
Signed-off-by: Alexandru Isaila
Reviewed-by: Paul Durrant
---
Changes since V14:
- Moved all the operations in the initializer.
---
xen/arch/x86/hvm/viridian.c | 30 +++---
1 file changed, 19 insertions(+), 11 de
This is used to save data from a single instance.
Signed-off-by: Alexandru Isaila
Reviewed-by: Jan Beulich
---
Changes since V13:
- Moved tsc_adjust to the initializer.
---
xen/arch/x86/hvm/hvm.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/xen/arc
This patch is aimed on using the new save_one fuctions in the hvm_save
Signed-off-by: Alexandru Isaila
---
Changes since V15:
- Moved declarations into their scopes
- Remove redundant NULL check
- Remove rc variable
- Change fault return to -ENODATA.
---
xen/arch
This is used to save data from a single instance.
Signed-off-by: Alexandru Isaila
---
Changes since v15:
- Drop comments
- Add BUILD_BUG_ON
- memcpy for sizeof().
Note: This patch is based on Roger Pau Monne's series[1]
---
xen/arch/x86/hvm/mtrr.c | 78 +
This is used to save data from a single instance.
Signed-off-by: Alexandru Isaila
---
Changes since v15:
- Drop struct vlapic *s.
---
xen/arch/x86/hvm/vlapic.c | 23 +++
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/ar
This is used to save data from a single instance.
Signed-off-by: Alexandru Isaila
Reviewed-by: Jan Beulich
---
Changes since V14:
- Remove err init
- Add blank line ahead of return
- Move xsave_enabled() check to the save_one func.
---
xen/arch/x86/hvm/hvm.c | 47 ++
Hi all,
This patch series addresses the ideea of saving data from a single vcpu
instance.
First it starts by adding *save_one functions, then it introduces a handler for
the
new save_one* funcs and makes use of it in the hvm_save and hvm_save_one funcs.
The final patches are used for clean up an
This is used to save data from a single instance.
Signed-off-by: Alexandru Isaila
Reviewed-by: Paul Durrant
Reviewed-by: Jan Beulich
---
Changes since V14:
- Remove err init
- Add blank line ahead of return.
---
xen/arch/x86/hvm/hvm.c | 106 +++-
This is used to save data from a single instance.
Signed-off-by: Alexandru Isaila
Reviewed-by: Jan Beulich
---
Changes since V11:
- Removed the memset and added init with {}.
---
xen/arch/x86/cpu/mcheck/vmce.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
Signed-off-by: Alexandru Isaila
Reviewed-by: Jan Beulich
---
Changes since V14:
- Change handler name from hvm_save_one_handler to
hvm_save_vcpu_handler.
---
xen/arch/x86/cpu/mcheck/vmce.c | 1 +
xen/arch/x86/hvm/hpet.c| 2 +-
xen/arch/x86/hvm/hvm.c | 6 +-
This patch removes the redundant save functions and renames the
save_one* to save. It then changes the domain param to vcpu in the
save funcs.
Signed-off-by: Alexandru Isaila
---
Changes since V15:
- Add if for hvm_sr_handlers[i].kind to separate HVMSR_PER_VCPU
from HVMSR_PER_D
This is used to save data from a single instance.
Signed-off-by: Alexandru Isaila
Reviewed-by: Jan Beulich
---
Changes since V14:
- Move all free fields to the initializer
- Add blank line to before the return
- Move v->pause_flags check to the save_one function.
---
xe
This is used to save data from a single instance.
Signed-off-by: Alexandru Isaila
---
Changes since v15:
- Drop struct vlapic *s.
---
xen/arch/x86/hvm/vlapic.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/
This patch is focused on moving changing hvm_save_one() to save one
typecode from one vcpu and now that the save functions get data from a
single vcpu we can pause the specific vcpu instead of the domain.
Signed-off-by: Alexandru Isaila
---
Changes since V15:
- Moved pause/unpause calls
On Tue, Aug 07, 2018 at 04:16:06AM +0200, Marek Marczykowski-Górecki wrote:
> When qemu is running in stubdomain, any attempt to initialize vnc/sdl
> there will crash it (on failed attempt to load a keymap from a file). If
> vfb is present, all those cases are skipped. But since
> b053f0c4c9e533f3d
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 09 August 2018 10:07
> To: Paul Durrant
> Cc: Andrew Cooper ; George Dunlap
> ; Ian Jackson ; Wei Liu
> ; Stefano Stabellini ; xen-
> devel ; Konrad Rzeszutek Wilk
> ; Tim (Xen.org)
> Subject: RE: [PATCH v22 1/2]
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 09 August 2018 10:09
> To: Paul Durrant
> Cc: Andrew Cooper ; George Dunlap
> ; Ian Jackson ; Wei Liu
> ; Stefano Stabellini ; xen-
> devel ; Konrad Rzeszutek Wilk
> ; Tim (Xen.org)
> Subject: RE: [PATCH v22 1/2]
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 09 August 2018 09:02
> To: xen-devel
> Cc: Andrew Cooper ; Paul Durrant
> ; George Dunlap
> Subject: [PATCH RFC] x86/HVM: meet xentrace's expectations on emulation
> event data
>
> According to the logic in hvm_m
>>> On 09.08.18 at 11:07, wrote:
On 09.08.18 at 10:55, wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: 09 August 2018 09:47
> >>
> >> >>> On 08.08.18 at 16:16, wrote:
> >> > @@ -1046,6 +1090,16 @@ static int acquire_resource(
> >> > xen_pfn_t gfn_list[ARRAY_SIZ
On Wed, Aug 08, 2018 at 04:02:09PM +0100, Anthony PERARD wrote:
> > But long term we might want to support VarStore (that is used to stored
> > config, right?). How are we going to do that in the future if we
> > repurpose it now?
>
> So, normally on QEMU/KVM, in order to use this VarStore, libvir
>>> On 09.08.18 at 10:55, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 09 August 2018 09:47
>>
>> >>> On 08.08.18 at 16:16, wrote:
>> > +static int gnttab_get_status_frame_mfn(struct domain *d,
>> > + unsigned long idx, mfn_t *mfn)
>> > +{
This domU.cfg fails for me with staging+qemu-3.0, but qemu-2.12 happens to work:
name='fv'
serial='pty'
vcpus='4'
memory=''
disk=[ 'vdev=xvda, format=raw, access=rw, target=/nfs_vmimages/disk0.raw' ]
vif=[ 'bridge=br0,mac=3e:27:63:30:c0:46,type=vif' ]
builder="hvm"
device_model_version="qemu-x
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 09 August 2018 09:47
> To: Paul Durrant
> Cc: Andrew Cooper ; Wei Liu
> ; George Dunlap ; Ian
> Jackson ; Stefano Stabellini
> ; xen-devel ;
> Konrad Rzeszutek Wilk ; Tim (Xen.org)
>
> Subject: Re: [PATCH v22 1/2]
>>> On 08.08.18 at 16:16, wrote:
> +static int gnttab_get_status_frame_mfn(struct domain *d,
> + unsigned long idx, mfn_t *mfn)
> +{
> +const struct grant_table *gt = d->grant_table;
> +
> +ASSERT(gt->gt_version == 2);
> +
> +if ( idx >= nr_status_
>>> On 09.08.18 at 10:20, wrote:
> On 8/9/18 10:54 AM, Jan Beulich wrote:
> On 08.08.18 at 16:26, wrote:
>>> 1. Is it possible to already have a valid interrupt written in
>>> VM_ENTRY_INTR_INFO at EXIT_REASON_EPT_VIOLATION-time in
>>> vmx_vmexit_handler()?
>>
>> You mean right after the exi
To allow for some code sharing where possible, copy VEX.L into EVEX.LR
even for VEX (or XOP) encoded insns. Make operand size determination
use this right away, at the same time adding consistency checks for the
EVEX scalar insn cases (the non-scalar ones aren't uniform enough for
the checking to b
Fix an inverted pair of checks, drop an incorrect instance of #UD
raising for non-64-bit mode, and add further generic checks.
Note: Other than SDM Vol 2 rev 067 states, EVEX.V' is _not_ ignored
outside of 64-bit mode when the field does not encode a register.
Just like EVEX. is re
Drop the pretty pointless conditionals from code testing AVX insns and
properly use AVX2 mnemonics in code testing AVX2 insns (the test harness
is already requiring sufficiently new a compiler/assembler).
Signed-off-by: Jan Beulich
--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/t
These are all VEX encoded, so the EVEX decoding logic continues to
remain unused at this point.
The new testcase is deliberately coded in assembly, as a C one would
have become almost unreadable due to the overwhelming amount of
__builtin_...() that would need to be used. After all the compiler ha
While deriving the first AVX512 pieces from existing code I've got the
(in the end wrong) impression that the emulation of these insns would be
broken. Besides testing that the instructions act as no-ops when the
controlling mask bits are all zero, add ones to also check that the data
merging actua
FMA insns, other than the earlier AVX additions, don't use the low
opcode bit to distinguish between single and double vector elements.
While the difference is benign for packed flavors, the scalar ones
need to use VEX.W here. Oddly enough the table entries didn't even use
simd_scalar_fp, but unifo
On 8/9/18 10:54 AM, Jan Beulich wrote:
On 08.08.18 at 16:26, wrote:
>> 1. Is it possible to already have a valid interrupt written in
>> VM_ENTRY_INTR_INFO at EXIT_REASON_EPT_VIOLATION-time in
>> vmx_vmexit_handler()?
>
> You mean right after the exit? Where would that come from? I'm
> afrai
1: fix FMA scalar operand sizes
2: extend MASKMOV{Q,DQU} tests
3: support AVX512 opmask insns
4: clean up AVX2 insn use in test harness
5: correct EVEX decoding
6: generalize vector length handling for AVX512/EVEX
While I also have ready a patch emulating the basic AVX512 moves,
its prereq to wide
According to the logic in hvm_mmio_assist_process(), 64 bits of data are
expected with 64-bit addresses, and 32 bits of data with 32-bit ones. I
don't think this is very reasonable, but I'm also not going to touch the
consumer side, the more that it is anyway not very helpful for the code
here to o
>>> On 08.08.18 at 16:26, wrote:
> 1. Is it possible to already have a valid interrupt written in
> VM_ENTRY_INTR_INFO at EXIT_REASON_EPT_VIOLATION-time in
> vmx_vmexit_handler()?
You mean right after the exit? Where would that come from? I'm
afraid I don't see the connection to your issue (or th
>>> On 08.08.18 at 18:18, wrote:
> On Wed, Aug 08, 2018 at 07:15:54AM -0600, Jan Beulich wrote:
>> >>> On 08.08.18 at 12:07, wrote:
>> > Several people have reported hardware issues (malfunctioning USB
>> > controllers) due to iommu page faults on Intel hardware. Those faults
>> > are caused by m
flight 125822 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125822/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
Regressions wh
>>> On 08.08.18 at 18:09, wrote:
> On Wed, Aug 08, 2018 at 06:32:00AM -0600, Jan Beulich wrote:
>> >>> On 08.08.18 at 12:07, wrote:
>> > Introduce a new dom0-iommu=inclusive generic option that supersedes
>> > iommu_inclusive_mapping. The previous behaviour is preserved and the
>> > option should
1 - 100 of 101 matches
Mail list logo
