On Thu, 2018-10-25 at 11:29 -0600, Tamas K Lengyel wrote:
> On Thu, Oct 25, 2018 at 11:23 AM Dario Faggioli
> wrote:
> >
> > Having _everyone_ wanting to do actual stuff on the CPUs is, IMO,
> > one
> > of the worst workloads for hyperthreading, and it is in fact a
> > workload
> > where I've alw
On Thu, Oct 25, 2018 at 11:56:02AM -0700, Joe Jin wrote:
> I just discussed this patch with Boris in private, his opinions(Boris,
> please correct me if any misunderstood) are:
>
> 1. With/without the check, both are incorrect, he thought we need to
>prevented unalloc'd free at here.
> 2. On
On Thu, 2018-10-25 at 12:35 -0600, Tamas K Lengyel wrote:
> On Thu, Oct 25, 2018 at 12:13 PM Andrew Cooper
> wrote:
> >
> > TBH, I'd perhaps start with an admin control which lets them switch
> > between the two modes, and some instructions on how/why they might
> > want
> > to try switching.
> >
On 25/10/2018 16:38, Andrew Cooper wrote:
> diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
> index 9390705..d1c8a41 100644
> --- a/xen/arch/x86/hvm/vmx/vvmx.c
> +++ b/xen/arch/x86/hvm/vmx/vvmx.c
> @@ -2348,6 +2348,7 @@ int nvmx_n2_vmexit_handler(struct cpu_user_regs *regs,
flight 128994 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128994/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 979b7d802c316722da3f3dee90799728c7aab38f
baseline version:
ovmf 0019375fbc89e4d7cfebe
Hi Joe,
On 10/26/2018 03:48 PM, Christoph Helwig wrote:
> On Thu, Oct 25, 2018 at 11:56:02AM -0700, Joe Jin wrote:
>> I just discussed this patch with Boris in private, his opinions(Boris,
>> please correct me if any misunderstood) are:
>>
>> 1. With/without the check, both are incorrect, he thoug
>>> On 25.10.18 at 20:32, wrote:
> On 18/09/18 12:53, Jan Beulich wrote:
>> @@ -1187,6 +1188,11 @@ static int _get_fpu(
>> return X86EMUL_UNHANDLEABLE;
>> break;
>>
>> +case X86EMUL_FPU_opmask:
>> +if ( !(xcr0 & X86_XCR0_SSE) || !(xcr0 & X86_XCR0_OPMASK) )
>> +
>>> On 25.10.18 at 20:36, wrote:
> On 18/09/18 12:53, Jan Beulich wrote:
>> This is needed before enabling any AVX512 insns in the emulator. Change
>> the way alignment is enforced at the same time.
>>
>> Add a check that the buffer won't actually overflow, and while at it
>> also convert the chec
On 25/10/2018 16:39, Andrew Cooper wrote:
> This is very dangerous from a security point of view, because a missing entry
> will cause L2's action to be interpreted as L1's action.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Sergey Dyasli
> CC: Jan Beulich
> CC: Wei Liu
> CC: Jun Nakajima
On 25/10/2018 16:36, Andrew Cooper wrote:
> This is a stopgap solution until the toolstack side of initialisation can be
> sorted out, but it does result in the nvmx_vcpu_in_vmx() predicate working
> correctly even when nested virt hasn't been enabled for the domain.
>
> Update nvmx_handle_vmx_ins
On 25/10/2018 16:38, Andrew Cooper wrote:
> Now that nvmx_handle_vmx_insn() performs all VT-x instruction checks, there is
> no need for redundant checking in vmx_inst_check_privilege(). Remove it, and
> take out the vmxon_check boolean which was plumbed through decode_vmx_inst().
>
> Signed-off-
On 26/10/2018 10:05, Sergey Dyasli wrote:
>
> On 25/10/2018 16:39, Andrew Cooper wrote:
>> This is very dangerous from a security point of view, because a missing entry
>> will cause L2's action to be interpreted as L1's action.
>>
>> Signed-off-by: Andrew Cooper
>> ---
>> CC: Sergey Dyasli
>> CC
This patch adds a couple of regs to the vm_event that are used by
the introspection. The base, limit and ar
bits are compressed into a uint64_t union so as not to enlarge the
vm_event.
Signed-off-by: Alexandru Isaila
---
Changes since V3:
- Remove union from x86_selector_reg
- Sp
On 26/10/2018 10:10, Andrew Cooper wrote:
> On 26/10/2018 10:05, Sergey Dyasli wrote:
>>
>> On 25/10/2018 16:39, Andrew Cooper wrote:
>>> This is very dangerous from a security point of view, because a missing
>>> entry
>>> will cause L2's action to be interpreted as L1's action.
>>>
>>> Signed-of
>>> On 25.10.18 at 18:29, wrote:
> A split xenheap model means that data pertaining to other guests isn't
> mapped in the context of this vcpu, so cannot be brought into the cache.
It was not clear to me from Wei's original mail that talk here is
about "split" in a sense of "per-domain"; I was as
On Fri, Oct 26, 2018 at 03:16:15AM -0600, Jan Beulich wrote:
> >>> On 25.10.18 at 18:29, wrote:
> > A split xenheap model means that data pertaining to other guests isn't
> > mapped in the context of this vcpu, so cannot be brought into the cache.
>
> It was not clear to me from Wei's original ma
Am Thu, 25 Oct 2018 14:08:08 +0200
schrieb Olaf Hering :
> qemu-2.9-20170907T112512.4cd42653f5/include/hw/xen/xen_common.h:61:16:
> warning: implicit declaration of function 'xc_map_foreign_bulk'
> qemu is built with the various compat flags like
> :-DXC_WANT_COMPAT_MAP_FOREIGN_API=1. I think th
flight 129000 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129000/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-freebsd broken
build-amd64-freebs
>>> On 26.10.18 at 11:28, wrote:
> On Fri, Oct 26, 2018 at 03:16:15AM -0600, Jan Beulich wrote:
>> >>> On 25.10.18 at 18:29, wrote:
>> > A split xenheap model means that data pertaining to other guests isn't
>> > mapped in the context of this vcpu, so cannot be brought into the cache.
>>
>> It w
A given Qemu version can not predict what version of Xen it will run on.
There are some checks in configure to decide what Xen libraries and
functions are available. How exactly these functions must be accessed
has to be decided by configure and the user who is compiling Qemu.
In no way some random
On 10/25/2018 07:13 PM, Andrew Cooper wrote:
> On 25/10/18 18:58, Tamas K Lengyel wrote:
>> On Thu, Oct 25, 2018 at 11:43 AM Andrew Cooper
>> wrote:
>>> On 25/10/18 18:35, Tamas K Lengyel wrote:
On Thu, Oct 25, 2018 at 11:02 AM George Dunlap
wrote:
> On 10/25/2018 05:55 PM, Andrew
In order to have a link to the release notes in the feature list
generated from SUPPORT.md add that link in the "Release Support"
section of that file.
Signed-off-by: Juergen Gross
---
SUPPORT.md | 1 +
1 file changed, 1 insertion(+)
diff --git a/SUPPORT.md b/SUPPORT.md
index ff09e5ab6b..98ab52
In order to have a link to the release notes in the feature list
generated from SUPPORT.md add that link in the "Release Support"
section of that file.
Signed-off-by: Juergen Gross
---
SUPPORT.md | 1 +
1 file changed, 1 insertion(+)
diff --git a/SUPPORT.md b/SUPPORT.md
index ff09e5ab6b..98ab52
In order to have a link to the release notes in the feature list
generated from SUPPORT.md add that link in the "Release Support"
section of that file.
The real link needs to be adapted when the version is being released.
Signed-off-by: Juergen Gross
---
SUPPORT.md | 1 +
1 file changed, 1 inse
On Fri, Oct 26, 2018 at 12:22:21PM +0200, Juergen Gross wrote:
> In order to have a link to the release notes in the feature list
> generated from SUPPORT.md add that link in the "Release Support"
> section of that file.
>
> The real link needs to be adapted when the version is being released.
>
docs/ChangeLog has been updated for Xen 3.3 last time. It seems to be
interesting for archaeologists only today.
Remove it.
Signed-off-by: Juergen Gross
---
docs/ChangeLog | 135 -
1 file changed, 135 deletions(-)
delete mode 100644 docs/
On Fri, Oct 26, 2018 at 12:22:19PM +0200, Juergen Gross wrote:
> In order to have a link to the release notes in the feature list
> generated from SUPPORT.md add that link in the "Release Support"
> section of that file.
>
> Signed-off-by: Juergen Gross
Acked-by: Wei Liu
__
On Fri, Oct 26, 2018 at 12:22:20PM +0200, Juergen Gross wrote:
> In order to have a link to the release notes in the feature list
> generated from SUPPORT.md add that link in the "Release Support"
> section of that file.
>
> Signed-off-by: Juergen Gross
Acked-by: Wei Liu
__
>>> On 26.10.18 at 12:22, wrote:
> --- a/SUPPORT.md
> +++ b/SUPPORT.md
> @@ -13,6 +13,7 @@ for the definitions of the support status levels etc.
> Initial-Release: n/a
> Supported-Until: TBD
> Security-Support-Until: Unreleased - not yet security-supported
> +Release-Notes: hre
On 26/10/2018 12:39, Jan Beulich wrote:
On 26.10.18 at 12:22, wrote:
>> --- a/SUPPORT.md
>> +++ b/SUPPORT.md
>> @@ -13,6 +13,7 @@ for the definitions of the support status levels etc.
>> Initial-Release: n/a
>> Supported-Until: TBD
>> Security-Support-Until: Unreleased - not ye
On 10/26/2018 10:56 AM, Jan Beulich wrote:
On 26.10.18 at 11:28, wrote:
>> On Fri, Oct 26, 2018 at 03:16:15AM -0600, Jan Beulich wrote:
>> On 25.10.18 at 18:29, wrote:
A split xenheap model means that data pertaining to other guests isn't
mapped in the context of this vcpu, so
Juergen Gross writes ("Re: [PATCH] Release: add release note link to
SUPPORT.md"):
> Ian, do you want this to be part of release-technician-checklist.txt:
>
> * change SUPPORT.md heading version number; -unstable or -rc tag
> + and put version number in release note link
I'm happy to have it i
>>> On 10.09.18 at 12:13, wrote:
On 07.09.18 at 19:08, wrote:
> > On 01/08/18 15:31, Jan Beulich wrote:
> >> In order to be able to wake parked CPUs from default_dead_idle(), the
> >> function must not itself loop. Move the loop into play_dead(), and use
> >> play_dead() as well on the AP bo
>>> On 01.08.18 at 16:32, wrote:
> When the mwait-idle driver isn't used, C-state information becomes
> available only in the course of Dom0 starting up. Use the provided data
> to allow parked CPUs to sleep in a more energy efficient way, by waking
> them briefly (via NMI) once the data has been
>>> On 13.09.18 at 18:44, wrote:
> On Mon, Sep 10, 2018 at 07:59:16AM -0600, Jan Beulich wrote:
>> For one it is quite pointless to iterate over all pIRQ-s the domain has
>> when just one is being adjusted. Introduce hvm_migrate_pirq().
>>
>> Additionally it is bogus to migrate the pIRQ to a vCPU
>>> On 25.09.18 at 13:02, wrote:
> Move p2m_{get/set}_suppress_ve() to p2m.c, replace incorrect
> ASSERT() in p2m-pt.c (since a guest can run in shadow mode even on
> a system with virt exceptions, which would trigger the ASSERT()),
> move the VMX-isms (cpu_has_vmx_virt_exceptions checks) to
> p2m
>>> On 01.10.18 at 18:03, wrote:
> Patch 2 is no longer RFC, now that I have a device where MSI actually
> works (suggesting that it was really the other device's fault that things
> didn't work).
>
> 1: console: adjust IRQ initialization
> 2: ns16550: enable use of PCI MSI
>
> Jan
>
>
>
> __
>>> On 01.10.18 at 17:57, wrote:
> Selecting between single/multiple BAR mode should happen after checking
> whether to skip the present device, or else multi-BAR devices won't be
> skipped correctly, due to port_idx getting set to zero in that case.
>
> Signed-off-by: Jan Beulich
>
> --- a/xen
In order to have a link to the release notes in the feature list
generated from SUPPORT.md add that link in the "Release Support"
section of that file.
The real link needs to be adapted when the version is being released.
Signed-off-by: Juergen Gross
---
SUPPORT.md
On 26/10/18 10:13, Sergey Dyasli wrote:
> On 26/10/2018 10:10, Andrew Cooper wrote:
>> On 26/10/2018 10:05, Sergey Dyasli wrote:
>>> On 25/10/2018 16:39, Andrew Cooper wrote:
This is very dangerous from a security point of view, because a missing
entry
will cause L2's action to be i
On 25/10/2018 16.08, Jan Beulich wrote:
On 25.10.18 at 16:00, wrote:
>> For shipped binaries to customers, exactly when it was built is
>> irrelevant, whereas peoples ability to independently verify the
>> integrity of the binary is important.
>
> Correct, which is why I appreciate the _opti
>>> On 05.10.18 at 14:03, wrote:
On 05.10.18 at 13:58, wrote:
>> On 05/10/18 12:29, Jan Beulich wrote:
>>> This is not used (and probably was never meant to be) by the tool stack.
>>> Limiting it to the current domain in particular allows to eliminate a
>>> bogus use of vCPU 0 in pagetable_d
On 26/10/18 12:12, Jan Beulich wrote:
On 05.10.18 at 14:03, wrote:
> On 05.10.18 at 13:58, wrote:
>>> On 05/10/18 12:29, Jan Beulich wrote:
This is not used (and probably was never meant to be) by the tool stack.
Limiting it to the current domain in particular allows to elimina
>>> On 11.10.18 at 13:40, wrote:
On 11.10.18 at 10:05, wrote:
>> Found while looking at some OSSTest logs.
>>
>> Oct 9 14:03:09.579037 (XEN) avc: denied { setup } for domid=0
>> scontext=system_u:system_r:dom0_t tcontext=system_u:system_r:xen_t
>> tclass=resource
>> Oct 9 14:03:09.590
On 10/26/18 2:02 PM, Jan Beulich wrote:
On 25.09.18 at 13:02, wrote:
>> Move p2m_{get/set}_suppress_ve() to p2m.c, replace incorrect
>> ASSERT() in p2m-pt.c (since a guest can run in shadow mode even on
>> a system with virt exceptions, which would trigger the ASSERT()),
>> move the VMX-isms
>>> On 26.10.18 at 12:51, wrote:
> On 10/26/2018 10:56 AM, Jan Beulich wrote:
> On 26.10.18 at 11:28, wrote:
>>> On Fri, Oct 26, 2018 at 03:16:15AM -0600, Jan Beulich wrote:
>>> On 25.10.18 at 18:29, wrote:
> A split xenheap model means that data pertaining to other guests isn't
On 10/26/2018 12:20 PM, Jan Beulich wrote:
On 26.10.18 at 12:51, wrote:
>> On 10/26/2018 10:56 AM, Jan Beulich wrote:
>> On 26.10.18 at 11:28, wrote:
On Fri, Oct 26, 2018 at 03:16:15AM -0600, Jan Beulich wrote:
On 25.10.18 at 18:29, wrote:
>> A split xenheap model mean
On 26/10/18 10:04, Jan Beulich wrote:
On 25.10.18 at 20:36, wrote:
>> On 18/09/18 12:53, Jan Beulich wrote:
>>> This is needed before enabling any AVX512 insns in the emulator. Change
>>> the way alignment is enforced at the same time.
>>>
>>> Add a check that the buffer won't actually overfl
On 26/10/18 10:03, Jan Beulich wrote:
On 25.10.18 at 20:32, wrote:
>> On 18/09/18 12:53, Jan Beulich wrote:
>>> @@ -1187,6 +1188,11 @@ static int _get_fpu(
>>> return X86EMUL_UNHANDLEABLE;
>>> break;
>>>
>>> +case X86EMUL_FPU_opmask:
>>> +if ( !(xcr0 & X86_
flight 128998 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128998/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf e5001ab7a9c17fe1cf9155392c943a9c985c8a96
baseline version:
ovmf 979b7d802c316722da3f3
On 26/10/2018 12:09, Andrew Cooper wrote:
> Ok - that patch is now as follows:
>
> x86/vvmx: Let L1 handle all the unconditional vmexit instructions
>
> Signed-off-by: Andrew Cooper
> ...
> diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
> index aa202e0..7051eb3 100644
> -
On 25/09/18 14:36, Jan Beulich wrote:
> In preparation for sensible to-boolean conversion on AVX512, wrap
> another abstraction function around the present to_bool( == ), to
> get rid of the open-coded == (which will get in the way of using
> built-in functions instead). For the future AVX512 use s
>>> On 26.10.18 at 13:24, wrote:
> On 10/26/2018 12:20 PM, Jan Beulich wrote:
> On 26.10.18 at 12:51, wrote:
>>> The basic solution involves having a xenheap virtual address mapping
>>> area not tied to the physical layout of the memory. domheap and xenheap
>>> memory would have to come from
On 10/26/2018 12:33 PM, Jan Beulich wrote:
On 26.10.18 at 13:24, wrote:
>> On 10/26/2018 12:20 PM, Jan Beulich wrote:
>> On 26.10.18 at 12:51, wrote:
The basic solution involves having a xenheap virtual address mapping
area not tied to the physical layout of the memory. domhea
>>> On 26.10.18 at 13:43, wrote:
> On 10/26/2018 12:33 PM, Jan Beulich wrote:
> On 26.10.18 at 13:24, wrote:
>>> On 10/26/2018 12:20 PM, Jan Beulich wrote:
>>> On 26.10.18 at 12:51, wrote:
> The basic solution involves having a xenheap virtual address mapping
> area not tied to t
>>> On 26.10.18 at 13:29, wrote:
> On 26/10/18 10:03, Jan Beulich wrote:
> On 25.10.18 at 20:32, wrote:
>>> On 18/09/18 12:53, Jan Beulich wrote:
@@ -1187,6 +1188,11 @@ static int _get_fpu(
return X86EMUL_UNHANDLEABLE;
break;
+case X86EMUL_
On Fri, Oct 26, 2018, 1:49 AM Dario Faggioli wrote:
> On Thu, 2018-10-25 at 12:35 -0600, Tamas K Lengyel wrote:
> > On Thu, Oct 25, 2018 at 12:13 PM Andrew Cooper
> > wrote:
> > >
> > > TBH, I'd perhaps start with an admin control which lets them switch
> > > between the two modes, and some inst
>>> On 26.10.18 at 13:07, wrote:
> --- a/SUPPORT.md
> +++ b/SUPPORT.md
> @@ -13,6 +13,7 @@ for the definitions of the support status levels etc.
> Initial-Release: n/a
> Supported-Until: TBD
> Security-Support-Until: Unreleased - not yet security-supported
> +Release-Notes: n/a
Hi Christophe,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on xen-tip/linux-next]
[also build test ERROR on v4.19 next-20181019]
[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/l
On 26/10/18 12:59, Jan Beulich wrote:
On 26.10.18 at 13:29, wrote:
>> On 26/10/18 10:03, Jan Beulich wrote:
>> On 25.10.18 at 20:32, wrote:
On 18/09/18 12:53, Jan Beulich wrote:
> @@ -1187,6 +1188,11 @@ static int _get_fpu(
> return X86EMUL_UNHANDLEABLE;
>
>>> On 26.10.18 at 14:19, wrote:
> On 26/10/18 12:59, Jan Beulich wrote:
> On 26.10.18 at 13:29, wrote:
>>> On 26/10/18 10:03, Jan Beulich wrote:
>>> On 25.10.18 at 20:32, wrote:
> On 18/09/18 12:53, Jan Beulich wrote:
>> @@ -1187,6 +1188,11 @@ static int _get_fpu(
>>
Ping? It's been nearly 3 weeks with only minor review for this series.
-George
On 10/05/2018 05:56 PM, George Dunlap wrote:
> docs/qemu-deprivilege.txt had some basic instructions for using
> dm_restrict, but it was incomplete, misleading, and stale.
>
> Update the docs in a number of ways.
>
flight 128970 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128970/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR. vs.
125898
test-amd64-
Hello Julien
On 25.10.18 17:11, Andrii Anisov wrote:
> I guess I should make a dedicated patch applicable to mainline to reveal
> the issue. I hope I'll do this nearest days.
Please find below the diff applicable to the current xenbits/smoke which
exposes the issue.
With that diff I see (on my
>>> On 12.10.18 at 18:37, wrote:
> Furthermore, I believe even #MC is blocked by the MOVSS shadow, because
> the purpose of the shadow is to indicate "my stack is not safe to take
> an exception".
I've just looked at the precise SDM text again, which I see has changed
compared to the prior revisi
On 26/10/2018 14:11, Jan Beulich wrote:
On 26.10.18 at 13:07, wrote:
>> --- a/SUPPORT.md
>> +++ b/SUPPORT.md
>> @@ -13,6 +13,7 @@ for the definitions of the support status levels etc.
>> Initial-Release: n/a
>> Supported-Until: TBD
>> Security-Support-Until: Unreleased - not ye
In order to have a link to the release notes in the feature list
generated from SUPPORT.md add that link in the "Release Support"
section of that file.
The real link needs to be adapted when the version is being released.
Signed-off-by: Juergen Gross
---
SUPPORT.md
>>> On 15.10.18 at 12:36, wrote:
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -323,6 +323,18 @@ void free_vcpu_struct(struct vcpu *v)
> free_xenheap_page(v);
> }
>
> +/* Initialise various registers to their architectural INIT/RESET state. */
> +void arch_vcpu_regs_init
George Dunlap writes ("[PATCH 1/5] docs/qemu-deprivilege: Revise and update
with status and future plans"):
> docs/qemu-deprivilege.txt had some basic instructions for using
> dm_restrict, but it was incomplete, misleading, and stale.
Thanks for the updates to the unshare stuff.
> +### Device Mo
flight 128972 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128972/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xen-xsm-freebsd broken
build-amd64-xen-freebsd
George Dunlap writes ("[PATCH 2/5] tools/dm_restrict: Ask QEMU to chroot"):
> When dm_restrict is enabled, ask QEMU to chroot into an empty directory.
>
> * Create /var/run/qemu/root-domid (deleting the old one if it's there)
> * Pass the -chroot option to QEMU
>
> Rather than running `rm -rf` on
Thanks, just tiny comments on this.
George Dunlap writes ("[PATCH 3/5] tools/dm_restrict: Unshare mount and IPC
namespaces on Linux"):
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index 385643b52c..702ea75149 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
George Dunlap writes ("[PATCH 4/5] tools/dm_depriv: Add first cut RLIMITs"):
> Limit the ability of a potentially compromised QEMU to consume system
> resources. Key limits:
> - RLIMIT_FSIZE (file size): 256KiB
> - RLIMIT_NPROC (after uid changes to a unique uid)
Thanks.
> +static struct {
> +
George Dunlap writes ("[PATCH 5/5] RFC: test/depriv: Add a tool to check
process-level depriv"):
> Add a tool to check whether the various process-level deprivileging
> operations have actually taken place on the process.
...
> NB that a number of other requested changes (such as using `set -e`,
>
This run is configured for baseline tests only.
flight 75507 xen-4.11-testing real [real]
http://osstest.xensource.com/osstest/logs/75507/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64
On Fri, 2018-10-26 at 06:01 -0600, Tamas K Lengyel wrote:
> On Fri, Oct 26, 2018, 1:49 AM Dario Faggioli
> wrote:
> >
> > I haven't done this kind of benchmark yet, but I'd say that, if
> > every
> > vCPU of every domain is doing 100% CPU intensive work, core-
> > scheduling
> > isn't going to ma
On 26/10/2018 14:31, Jan Beulich wrote:
On 15.10.18 at 12:36, wrote:
>> --- a/xen/arch/x86/domain.c
>> +++ b/xen/arch/x86/domain.c
>> @@ -323,6 +323,18 @@ void free_vcpu_struct(struct vcpu *v)
>> free_xenheap_page(v);
>> }
>>
>> +/* Initialise various registers to their architectural
On 10/26/2018 03:06 PM, Ian Jackson wrote:
> George Dunlap writes ("[PATCH 5/5] RFC: test/depriv: Add a tool to check
> process-level depriv"):
>> Add a tool to check whether the various process-level deprivileging
>> operations have actually taken place on the process.
> ...
>> NB that a number o
George Dunlap writes ("Re: [PATCH 5/5] RFC: test/depriv: Add a tool to check
process-level depriv"):
> FYI I do agree with all of those suggestions (both `set -e` and having
> functions to handle failure in a consistent way); but I didn't want to
> fix everything up in bash only to have to write i
>>> On 23.10.18 at 04:03, wrote:
> @@ -391,31 +394,79 @@ static void dump_console_ring_key(unsigned char key)
> free_xenheap_pages(buf, order);
> }
>
> -/* CTRL- switches input direction between Xen and DOM0. */
> +/*
> + * CTRL- changes input direction, rotating among Xen, Dom0,
> + * and
On 25/09/2018 14:27, Jan Beulich wrote:
> 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
"Despite what SDM ..." would be a more normal way of ph
>>> On 26.10.18 at 16:22, wrote:
> On 26/10/2018 14:31, Jan Beulich wrote:
> On 15.10.18 at 12:36, wrote:
>>> --- a/xen/arch/x86/domain.c
>>> +++ b/xen/arch/x86/domain.c
>>> @@ -323,6 +323,18 @@ void free_vcpu_struct(struct vcpu *v)
>>> free_xenheap_page(v);
>>> }
>>>
>>> +/* Initiali
Hi Christoph,
On 10/26/18 12:48 AM, Christoph Helwig wrote:
> On Thu, Oct 25, 2018 at 11:56:02AM -0700, Joe Jin wrote:
>> I just discussed this patch with Boris in private, his opinions(Boris,
>> please correct me if any misunderstood) are:
>>
>> 1. With/without the check, both are incorrect, he t
>>> On 23.10.18 at 15:19, wrote:
> xen/arch/x86/mm/p2m-ept.c | 8 +
> xen/arch/x86/mm/p2m.c | 83
> +++
> 2 files changed, 78 insertions(+), 13 deletions(-)
What about p2m-pt.c?
> @@ -287,24 +286,47 @@ int p2m_is_logdirty_range(struct p2m_do
On 10/26/18 1:54 AM, Dongli Zhang wrote:
> If dom0 (or any domain) is happy, although it could try to exchange all its
> continuous dma pages back to xen hypervisor. From the perspective of each
> domain, they always would like to keep as much continuous dma page as
> possible.
>
> I am thinking
On 26/10/2018 15:37, Jan Beulich wrote:
On 26.10.18 at 16:22, wrote:
>> On 26/10/2018 14:31, Jan Beulich wrote:
>> On 15.10.18 at 12:36, wrote:
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -323,6 +323,18 @@ void free_vcpu_struct(struct vcpu *v)
free
flight 129004 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129004/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b28d406b5a3b1506ce75fa71c74b489b68a2c11a
baseline version:
ovmf e5001ab7a9c17fe1cf915
>>> On 23.10.18 at 15:19, wrote:
> --- a/xen/arch/x86/mm/p2m-ept.c
> +++ b/xen/arch/x86/mm/p2m-ept.c
> @@ -1348,6 +1348,8 @@ int ept_p2m_init(struct p2m_domain *p2m)
> void ept_p2m_uninit(struct p2m_domain *p2m)
> {
> struct ept_data *ept = &p2m->ept;
> +
> +p2m_free_logdirty(p2m);
Thi
On 10/26/18 5:47 PM, Jan Beulich wrote:
On 23.10.18 at 15:19, wrote:
>> xen/arch/x86/mm/p2m-ept.c | 8 +
>> xen/arch/x86/mm/p2m.c | 83
>> +++
>> 2 files changed, 78 insertions(+), 13 deletions(-)
>
> What about p2m-pt.c?
Thank you for
>>> On 26.10.18 at 16:51, wrote:
> On 26/10/2018 15:37, Jan Beulich wrote:
> On 26.10.18 at 16:22, wrote:
>>> On 26/10/2018 14:31, Jan Beulich wrote:
>>> On 15.10.18 at 12:36, wrote:
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -323,6 +323,18 @@ void free_
On 10/26/18 5:54 PM, Jan Beulich wrote:
On 23.10.18 at 15:19, wrote:
>> --- a/xen/arch/x86/mm/p2m-ept.c
>> +++ b/xen/arch/x86/mm/p2m-ept.c
>> @@ -1348,6 +1348,8 @@ int ept_p2m_init(struct p2m_domain *p2m)
>> void ept_p2m_uninit(struct p2m_domain *p2m)
>> {
>> struct ept_data *ept = &p2
>>> On 26.10.18 at 17:00, wrote:
> On 10/26/18 5:47 PM, Jan Beulich wrote:
> On 23.10.18 at 15:19, wrote:
>>> xen/arch/x86/mm/p2m-ept.c | 8 +
>>> xen/arch/x86/mm/p2m.c | 83
> +++
>>> 2 files changed, 78 insertions(+), 13 deletions(-)
>>
>>> On 15.10.18 at 12:36, wrote:
> @@ -970,9 +972,13 @@ int arch_set_info_guest(
> v->arch.pv.ctrlreg[4] = cr4 ? pv_guest_cr4_fixup(v, cr4) :
> real_cr4_to_pv_guest_cr4(mmu_cr4_features);
>
> -memset(v->arch.debugreg, 0, sizeof(v->arch.debugreg));
> -for ( i = 0; i < 8; i++
>>> On 22.10.18 at 14:58, wrote:
> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -487,6 +487,7 @@ static EFI_FILE_HANDLE __init
> get_parent_handle(EFI_LOADED_IMAGE *loaded_image,
> CHAR16 **leaf)
> {
> static EFI_GUID __init
>>> On 18.10.18 at 12:34, wrote:
> NX support in the host is required for the shadow pagetable code to handle
> SMAP correctly for guests.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Wei Liu
> CC: Roger Pau Monné
> CC: George Dunlap
> CC: Tim Deegan
>
> RFC because this
On 10/08/2018 05:28 PM, Anthony PERARD wrote:
> On Fri, Oct 05, 2018 at 05:57:01PM +0100, George Dunlap wrote:
>> +# TEST: Process / group id
>> +#
>> +# Read /proc//status, checking Uid and Gid lines
>> +#
>> +# Uid should be xen-qemuuser-range-base+$domid
>> +# Gid should be 65534 ("nobody")
>
>
From: yuchenlin
Signed-off-by: yuchenlin
Reviewed-by: Philippe Mathieu-Daudé
Message-Id: <20181022080053.9379-1-yuchen...@synology.com>
Signed-off-by: Laurent Vivier
---
hw/display/vga_int.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/hw/display/vga_int.h b/hw/display/vga_int.h
index 6
From: Cleber Rosa
Point to the right and obvious location for lm32 tests.
Signed-off-by: Cleber Rosa
Reviewed-by: Thomas Huth
Acked-by: Alex Bennée
Message-Id: <20181004161852.11673-3-cr...@redhat.com>
Signed-off-by: Laurent Vivier
---
tests/tcg/README | 2 +-
1 file changed, 1 insertion(+)
From: Li Qiang
Found by reading the code.
Signed-off-by: Li Qiang
Message-Id: <1536150548-2797-1-git-send-email-liq...@gmail.com>
Signed-off-by: Laurent Vivier
---
include/qom/cpu.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/qom/cpu.h b/include/qom/cpu.h
index
From: Cleber Rosa
Commit 990dc39c made all tests executable at the time, but 218 came in
later, and missing those permissions.
Signed-off-by: Cleber Rosa
Message-Id: <20181004161852.11673-4-cr...@redhat.com>
Signed-off-by: Laurent Vivier
---
tests/qemu-iotests/218 | 0
1 file changed, 0 inser
1 - 100 of 156 matches
Mail list logo
