flight 139084 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139084/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd 6418500c9f9c91a698564bbc264c513461611472
baseline version:
freebsd
flight 139075 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139075/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 18 guest-start/debianhvm.repeat fail
REGR. vs. 138977
On 17.07.19 19:22, Joe Perches wrote:
On Wed, 2019-07-17 at 08:49 +0200, Juergen Gross wrote:
On 17.07.19 08:46, Joe Perches wrote:
On Tue, 2019-07-16 at 12:26 +0800, Zhenzhong Duan wrote:
.. as "nopv" support needs it to be changeable at boot up stage.
Checkpatch reports warning, so move
flight 139076 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139076/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-qcow2 15 guest-start/debian.repeat fail REGR. vs.
139037
Tests which did
flight 139069 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139069/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install
fail REGR. vs.
On Wed, Jul 17, 2019 at 12:21:58PM +0200, Roger Pau Monné wrote:
> On Wed, Jul 17, 2019 at 03:00:44AM +0200, Marek Marczykowski-Górecki wrote:
> > Add libxc wrapper for PHYSDEVOP_msi_control introduced in previous
> > commit.
> >
> > Signed-off-by: Marek Marczykowski-Górecki
>
> LGTM, albeit I
On Wed, Jul 17, 2019 at 12:18:43PM +0200, Roger Pau Monné wrote:
> On Wed, Jul 17, 2019 at 03:00:43AM +0200, Marek Marczykowski-Górecki wrote:
> > Allow device model running in stubdomain to enable/disable MSI(-X),
> > bypassing pciback. While pciback is still used to access config space
> > from
flight 139068 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139068/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR.
vs. 133580
flight 139072 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139072/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 35e242b698cdc6205e99a6d6a188bf27fecf9fb4
baseline version:
ovmf
Hi,
>
> Well, Xen has been supported the omap5 for quite a while. So there are
> two possibilities regarding the current SMP code:
> 1) It is totally broken and therefore never worked on any omap5
> platform.
> 2) It works but with maybe modification in U-boot.
>
> Looking at the mailing
Calling _put_page_type while also holding the page_lock
for that page can cause a deadlock.
The comment being dropped is incorrect since it's now out-of-date.
Signed-off-by: Tamas K Lengyel
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Wei Liu
Cc: Roger Pau Monne
---
v6: rebase
No functional change
Signed-off-by: Tamas K Lengyel
---
xen/arch/x86/mm/mem_sharing.c | 265 ++
1 file changed, 138 insertions(+), 127 deletions(-)
diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index a5fe89e339..aaf8c2f2c8 100644
---
Disable it by default as it is only an experimental subsystem.
Signed-off-by: Tamas K Lengyel
Acked-by: Daniel De Graaf
Acked-by: Razvan Cojocaru
Acked-by: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: Roger Pau Monne
Cc: George Dunlap
Cc: Ian Jackson
Cc: Julien Grall
Cc: Konrad
This is an assorted series of fixes to the memory sharing subsystem.
Patch 1-2: fix general brokeness of the system
Patch 3-5: nice-to-haves & cleanups, could be applied independently from the
rest of the patches in the series
Tamas K Lengyel (5):
x86/mem_sharing: reorder when pages
Improves performance for release builds.
Signed-off-by: Tamas K Lengyel
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: Roger Pau Monne
---
v6: patch ping
---
xen/include/asm-x86/mem_sharing.h | 4
1 file changed, 4 insertions(+)
diff --git a/xen/include/asm-x86/mem_sharing.h
Patch cf4b30dca0a "Add debug code to detect illegal page_lock and put_page_type
ordering" added extra sanity checking to page_lock/page_unlock for debug builds
with the assumption that no hypervisor path ever locks two pages at once.
This assumption doesn't hold during memory sharing so we copy a
> -Original Message-
[snip]
> >>> +}
> >>> +
> >>> +if ( !vm_event_check(ved) )
> >>> +return -EINVAL;
> >>> +
> >>> +if ( frame != 0 || nr_frames != to_channels(ved)->nr_frames )
> >>> +return -EINVAL;
> >>
> >> Is there a particular reason for this
On 17/07/2019 14:02, Jan Beulich wrote:
> On 17.07.2019 13:26, Andrew Cooper wrote:
>> On 17/07/2019 08:09, Jan Beulich wrote:
>>> On 17.07.2019 01:51, Andrew Cooper wrote:
On 15/07/2019 19:57, Foerster, Leonard wrote:
> * dom0less: bootstrap domains without the involvement of dom0
On Wed, 2019-07-17 at 17:04 +0100, George Dunlap wrote:
> On 8/25/18 1:21 AM, Dario Faggioli wrote:
> > If a pCPU has been/is being offlined, we don't want it to be
> > neither
> > assigned to any pCPU, nor in the wait list.
> >
> > Therefore, when we detect that a vcpu is going offline, remove
On Wed, 2019-07-17 at 08:49 +0200, Juergen Gross wrote:
> On 17.07.19 08:46, Joe Perches wrote:
> > On Tue, 2019-07-16 at 12:26 +0800, Zhenzhong Duan wrote:
> > > .. as "nopv" support needs it to be changeable at boot up stage.
> > >
> > > Checkpatch reports warning, so move variable declarations
On 17/07/2019 14:07, Jan Beulich wrote:
> On 17.07.2019 13:42, Andrew Cooper wrote:
>> On 17/07/2019 07:42, Jan Beulich wrote:
>>> This is to accompany commit ("x86/svm: Drop support for AMD's
>> 91f86f8634
> Hmm, odd - I'm sure I had checked, resulting in the impression that
> this didn't get
On 17/07/2019 15:08, Roger Pau Monné wrote:
> Hello,
>
> As part of some PCI related cleanup I'm doing, which includes
> expanding the usage of pci_sbdf_t, I'm also planning to add a custom
> printf formatter for pci_sbdf_t [0], so that a SBDF can be printed
> without having to specify four
On Mon, Jul 15, 2019 at 02:27:27PM +0100, George Dunlap wrote:
> Or use Android's build system?
I never worked with AOSP's sources, but after reading
https://elinux.org/Android_Build_System
the build system seems quite helpful.
If we can do the following to build libxl, I think we could live
Hi Denis,
On 17/07/2019 17:32, Denis Obrezkov wrote:
I am trying to understand how this ever worked. omap5_smp_init is called
by two sets of platforms (based on compatible):
- ti,dra7: there were some hacks in U-boot to avoid the SMC. If I am
right, then I would not bother to support
On 17/07/2019 13:37, Jan Beulich wrote:
> On 17.07.2019 12:33, George Dunlap wrote:
>>> On Jul 16, 2019, at 11:03 PM, Andrew Cooper
>>>
>>> We could trivially throw the fixes into the branch, tag it, sign it and
>>> throw it out into the open, but doing that on the embargo date itself
>>> would
flight 139090 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139090/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
On 17.07.2019 16:41, Petre Ovidiu PIRCALABU wrote:
> On Wed, 2019-07-17 at 10:06 +, Jan Beulich wrote:
>> On 16.07.2019 19:06, Petre Pircalabu wrote:
>>> +static void vm_event_channels_free_buffer(struct
>>> vm_event_channels_domain *impl)
>>>{
>>> -
Hi Julien,
>
> I am trying to understand how this ever worked. omap5_smp_init is called
> by two sets of platforms (based on compatible):
> - ti,dra7: there were some hacks in U-boot to avoid the SMC. If I am
> right, then I would not bother to support hacked U-boot.
> - ti,omap5: [1]
flight 139062 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139062/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 129313
build-armhf-pvops
On Wed, 17 Jul 2019 09:28:17 -0300
Mauro Carvalho Chehab wrote:
> Some files over there won't parse well by Sphinx.
>
> Fix them.
>
> Signed-off-by: Mauro Carvalho Chehab
Hi Mauro,
Does feel like this one should perhaps have been broken up a touch!
For the IIO ones I've eyeballed it rather
Array indexes used in the MSR read/write emulation functions as well as
the direct VMX / APIC-V hook are derived from guest controlled values.
Restrict their ranges to limit the side effects of speculative
execution.
Along these lines also constrain the vlapic_lvt_mask[] access.
Remove the
On 8/25/18 1:21 AM, Dario Faggioli wrote:
> If a pCPU has been/is being offlined, we don't want it to be neither
> assigned to any pCPU, nor in the wait list.
>
> Therefore, when we detect that a vcpu is going offline, remove it from
> both places.
Hmm, this commit message wasn't very
On Wed, Jul 17, 2019 at 11:54:35AM +0200, Roger Pau Monné wrote:
> On Wed, Jul 17, 2019 at 03:00:42AM +0200, Marek Marczykowski-Górecki wrote:
> > Stubdomains need to be given sufficient privilege over the guest which it
> > provides emulation for in order for PCI passthrough to work correctly.
>
On Wed, 2019-07-17 at 16:42 +0300, Alexandru Stefan ISAILA wrote:
> > +
> > +out:
> > +rc2 = xc_domain_unpause(xch, domain_id);
> > +if ( rc1 || rc2 )
> > +{
> > +if ( rc2 )
> > +PERROR("Unable to pause domain\n");
> > +
> > +if ( rc1 == 0 )
> > +
On Wed, 2019-07-17 at 10:06 +, Jan Beulich wrote:
> On 16.07.2019 19:06, Petre Pircalabu wrote:
> > +static void vm_event_channels_free_buffer(struct
> > vm_event_channels_domain *impl)
> > {
> > -vm_event_ring_resume(to_ring(v->domain->vm_event_monitor));
> > +int i;
> > +
> > +
On Wed, Jul 17, 2019 at 12:49:49PM +, Jan Beulich wrote:
> On 17.07.2019 12:26, Roger Pau Monné wrote:
> > On Wed, Jul 17, 2019 at 09:04:55AM +, Jan Beulich wrote:
> >> On 16.07.2019 16:26, Roger Pau Monné wrote:
> >>> On Wed, Jul 03, 2019 at 01:01:48PM +, Jan Beulich wrote:
>
Hello,
As part of some PCI related cleanup I'm doing, which includes
expanding the usage of pci_sbdf_t, I'm also planning to add a custom
printf formatter for pci_sbdf_t [0], so that a SBDF can be printed
without having to specify four formatters (and pass four parameters)
each time
flight 139056 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139056/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-prev 6 xen-buildfail REGR. vs. 138376
> Disable it by default as it is only an experimental subsystem.
>
> Signed-off-by: Tamas K Lengyel
This will now need re-basing, as the other change (adding further
CONFIG_HAS_MEM_SHARING) has just gone in. I'm sorry for the extra
round trip needed.
Jan
> +
> +out:
> +rc2 = xc_domain_unpause(xch, domain_id);
> +if ( rc1 || rc2 )
> +{
> +if ( rc2 )
> +PERROR("Unable to pause domain\n");
> +
> +if ( rc1 == 0 )
> +rc1 = rc2;
You can use !rc1 here.
> +}
> +
> +return rc1;
> +}
> +
> +int
On 17.07.2019 14:38, Tamas K Lengyel wrote:
>> I've omitted all style comments (formatting, plain vs unsigned int
>> etc) - I'd like to leave that to the VM event maintainers.
>
> Do we have an automated way to check for style issues, like astyle?
We don't; there is some work underway towards
On 17.07.2019 13:42, Andrew Cooper wrote:
> On 17/07/2019 07:42, Jan Beulich wrote:
>> This is to accompany commit ("x86/svm: Drop support for AMD's
>
> 91f86f8634
Hmm, odd - I'm sure I had checked, resulting in the impression that
this didn't get committed yet.
>> Lightweight Profiling").
>>
On 17.07.2019 13:26, Andrew Cooper wrote:
> On 17/07/2019 08:09, Jan Beulich wrote:
>> On 17.07.2019 01:51, Andrew Cooper wrote:
>>> On 15/07/2019 19:57, Foerster, Leonard wrote:
* dom0less: bootstrap domains without the involvement of dom0
-> this might come in handy to at
On 17.07.2019 12:26, Roger Pau Monné wrote:
> On Wed, Jul 17, 2019 at 09:04:55AM +, Jan Beulich wrote:
>> On 16.07.2019 16:26, Roger Pau Monné wrote:
>>> On Wed, Jul 03, 2019 at 01:01:48PM +, Jan Beulich wrote:
--- a/xen/arch/x86/acpi/cpu_idle.c
+++
> I've omitted all style comments (formatting, plain vs unsigned int
> etc) - I'd like to leave that to the VM event maintainers.
Do we have an automated way to check for style issues, like astyle? In
my projects I integrate that into my Travis checks so I don't have to
do that manually (see
On 17.07.2019 12:33, George Dunlap wrote:
>
>> On Jul 16, 2019, at 11:03 PM, Andrew Cooper
>>
>> We could trivially throw the fixes into the branch, tag it, sign it and
>> throw it out into the open, but doing that on the embargo date itself
>> would result in an official release of Xen which has
Several entries at the stable ABI files won't parse if we pass
them directly to the ReST output.
Adjust them, in order to allow adding their contents as-is at
the stable ABI book.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/ABI/stable/firewire-cdev| 4 +
On Wed, 2019-07-17 at 09:31 +, Jan Beulich wrote:
> On 16.07.2019 19:06, Petre Pircalabu wrote:
> > The vm_event_domain members are not accessed outside vm_event.c so
> > it's
> > better to hide de implementation details.
> >
> > Signed-off-by: Petre Pircalabu
> > Acked-by: Andrew Cooper
>
On Tue, 2019-07-16 at 15:13 -0600, Tamas K Lengyel wrote:
> On Tue, Jul 16, 2019 at 11:06 AM Petre Pircalabu
> wrote:
> >
> > In high throughput introspection scenarios where lots of monitor
> > vm_events are generated, the ring buffer can fill up before the
> > monitor
> > application gets a
On 17/07/2019 07:42, Jan Beulich wrote:
> This is to accompany commit ("x86/svm: Drop support for AMD's
91f86f8634
> Lightweight Profiling").
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
> ---
> With AMD apparently having abandoned XOP encoded insns, another option
> would seem to
On 17/07/2019 07:33, Jan Beulich wrote:
> Plus the only other AVX512_BITALG one.
>
> As in a few cases before, since the insns here and in particular their
> memory access patterns follow the usual scheme, I didn't think it was
> necessary to add a contrived test specifically for them, beyond the
On 17/07/2019 07:59, Jan Beulich wrote:
On 04.06.19 at 14:41, wrote:
>> Rather than checking that a page table is _not_ "owned" by the fake COW
>> domain, check that it's owned by the domain actually wanting to install
>> it.
>>
>> Switch away from BUG_ON() at the same time.
>>
>>
On 17/07/2019 08:09, Jan Beulich wrote:
> On 17.07.2019 01:51, Andrew Cooper wrote:
>> On 15/07/2019 19:57, Foerster, Leonard wrote:
>>> * dom0less: bootstrap domains without the involvement of dom0
>>> -> this might come in handy to at least setup and continue dom0
>>> on target
On 16.07.2019 20:06, Petre Pircalabu wrote:
> Cleanup xen-access code in accordance with the XEN style guide.
>
> Signed-off-by: Petre Pircalabu
Reviewed-by: Alexandru Isaila
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
On 16.07.2019 20:06, Petre Pircalabu wrote:
> This simplifies the command line parsing logic and makes it easier to
> add new test parameters.
>
> Signed-off-by: Petre Pircalabu
Reviewed-by: Alexandru Isaila
___
Xen-devel mailing list
On 16.07.2019 20:06, Petre Pircalabu wrote:
> Remove the domain reference from calls to vm_event interface function
> and use the backpointer from vm_event_domain.
>
> Affected functions:
> - __vm_event_claim_slot / vm_event_claim_slot / vm_event_claim_slot_nosleep
> - vm_event_cancel_slot
> -
Several entries at the stable ABI files won't parse if we pass
them directly to the ReST output.
Adjust them, in order to allow adding their contents as-is at
the stable ABI book.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/ABI/stable/firewire-cdev| 4 +
> On Jul 16, 2019, at 11:03 PM, Andrew Cooper
>
> We could trivially throw the fixes into the branch, tag it, sign it and
> throw it out into the open, but doing that on the embargo date itself
> would result in an official release of Xen which has had 0 testing in
> the incumbent test system.
On Wed, Jul 17, 2019 at 09:04:55AM +, Jan Beulich wrote:
> On 16.07.2019 16:26, Roger Pau Monné wrote:
> > On Wed, Jul 03, 2019 at 01:01:48PM +, Jan Beulich wrote:
> >> --- a/xen/arch/x86/acpi/cpu_idle.c
> >> +++ b/xen/arch/x86/acpi/cpu_idle.c
> >> @@ -110,6 +110,8 @@
On Wed, Jul 17, 2019 at 03:00:44AM +0200, Marek Marczykowski-Górecki wrote:
> Add libxc wrapper for PHYSDEVOP_msi_control introduced in previous
> commit.
>
> Signed-off-by: Marek Marczykowski-Górecki
LGTM, albeit I find the usage of int instead of unsigned int for the
SBDF kind of weird, but
On Wed, Jul 17, 2019 at 03:00:43AM +0200, Marek Marczykowski-Górecki wrote:
> Allow device model running in stubdomain to enable/disable MSI(-X),
> bypassing pciback. While pciback is still used to access config space
> from within stubdomain, it refuse to write to
>
On 16.07.2019 19:28, Andrew Cooper wrote:
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -1407,7 +1407,8 @@ static int alloc_l1_table(struct page_info *page)
> return 0;
>
>fail:
> -gdprintk(XENLOG_WARNING, "Failure in alloc_l1_table: slot %#x\n", i);
> +
On 16.07.2019 19:06, Petre Pircalabu wrote:
> +static void vm_event_channels_free_buffer(struct vm_event_channels_domain
> *impl)
> {
> -vm_event_ring_resume(to_ring(v->domain->vm_event_monitor));
> +int i;
> +
> +vunmap(impl->slots);
> +impl->slots = NULL;
> +
> +for ( i =
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-xsm
testid xen-boot
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu
On Wed, 2019-07-17 at 11:49 +0300, Alexandru Stefan ISAILA wrote:
>
> On 16.07.2019 20:06, Petre Pircalabu wrote:
> > @@ -1004,7 +942,7 @@ struct xen_domctl_psr_cmt_op {
> >* Enable/disable monitoring various VM events.
> >* This domctl configures what events will be reported to helper
>
On Wed, Jul 17, 2019 at 03:00:42AM +0200, Marek Marczykowski-Górecki wrote:
> Stubdomains need to be given sufficient privilege over the guest which it
> provides emulation for in order for PCI passthrough to work correctly.
> When a HVM domain try to enable MSI, QEMU in stubdomain calls
>
flight 139083 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139083/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 08b084ab48738040e34032ffb42387d88619bf1b
baseline version:
xen
Hi,
On 7/15/19 4:42 PM, George Dunlap wrote:
> On 7/15/19 3:23 PM, Jan Beulich wrote:
>> On 15.07.2019 16:11, George Dunlap wrote:
>>> There was a long discussion about security patches, with the general
>>> proposal being that we should cut a point release for every security issue.
>>
>>
On 16.07.2019 19:06, Petre Pircalabu wrote:
> The vm_event_domain members are not accessed outside vm_event.c so it's
> better to hide de implementation details.
>
> Signed-off-by: Petre Pircalabu
> Acked-by: Andrew Cooper
> Acked-by: Tamas K Lengyel
> ---
> xen/common/vm_event.c | 26
On 16.07.2019 19:06, Petre Pircalabu wrote:
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -279,6 +279,8 @@ struct vcpu
> /* VM event */
> struct vm_event_domain
> {
> +/* Domain reference */
> +struct domain *d;
> spinlock_t lock;
> /* The ring has
On Tue, 2019-07-16 at 14:45 -0600, Tamas K Lengyel wrote:
> On Tue, Jul 16, 2019 at 11:06 AM Petre Pircalabu
> wrote:
> >
> > This patchset adds a new mechanism of sending synchronous vm_event
> > requests and handling vm_event responses without using a ring.
> > As each synchronous request
On 16.07.2019 17:06, Roger Pau Monné wrote:
> On Wed, Jul 03, 2019 at 01:04:13PM +, Jan Beulich wrote:
>> --- a/tools/misc/xenpm.c
>> +++ b/tools/misc/xenpm.c
>> @@ -64,7 +64,9 @@ void show_help(void)
>>" set-sched-smt enable|disable enable/disable
>> scheduler smt
On 16.07.2019 20:06, Petre Pircalabu wrote:
> Decouple implementation from interface to allow vm_event_check to be
> used regardless of the vm_event underlying implementation.
>
> Signed-off-by: Petre Pircalabu
> Acked-by: Andrew Cooper
> Acked-by: Tamas K Lengyel
Reviewed-by: Alexandru
On 16.07.2019 16:48, Roger Pau Monné wrote:
> On Wed, Jul 03, 2019 at 01:03:02PM +, Jan Beulich wrote:
>> @@ -592,7 +608,13 @@ static void acpi_processor_idle(void)
>>
>>do {
>>cx = >states[next_state];
>> -} while ( cx->type > max_state && --next_state
On 16.07.2019 16:26, Roger Pau Monné wrote:
> On Wed, Jul 03, 2019 at 01:01:48PM +, Jan Beulich wrote:
>> --- a/xen/arch/x86/acpi/cpu_idle.c
>> +++ b/xen/arch/x86/acpi/cpu_idle.c
>> @@ -110,6 +110,8 @@ boolean_param("lapic_timer_c2_ok", local
>>
>>struct acpi_processor_power
flight 139047 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139047/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemut-win7-amd64 13 guest-saverestore fail in 138919 pass
in 139047
On 16.07.2019 20:06, Petre Pircalabu wrote:
> @@ -1004,7 +942,7 @@ struct xen_domctl_psr_cmt_op {
>* Enable/disable monitoring various VM events.
>* This domctl configures what events will be reported to helper apps
>* via the ring buffer "MONITOR". The ring has to be first enabled
>
On Tue, 2019-07-16 at 14:59 -0600, Tamas K Lengyel wrote:
> > diff --git a/xen/include/public/vm_event.h
> > b/xen/include/public/vm_event.h
> > index 959083d..c48bc21 100644
> > --- a/xen/include/public/vm_event.h
> > +++ b/xen/include/public/vm_event.h
> > @@ -36,6 +36,37 @@
> > #include
On 17.07.2019 01:51, Andrew Cooper wrote:
> On 15/07/2019 19:57, Foerster, Leonard wrote:
>> * dom0less: bootstrap domains without the involvement of dom0
>> -> this might come in handy to at least setup and continue dom0
>> on target xen
>> -> If we have this this
>>> On 04.06.19 at 14:41, wrote:
> Rather than checking that a page table is _not_ "owned" by the fake COW
> domain, check that it's owned by the domain actually wanting to install
> it.
>
> Switch away from BUG_ON() at the same time.
>
> Signed-off-by: Jan Beulich
I've got Roger's R-b - any
On Tue, 2019-07-16 at 12:26 +0800, Zhenzhong Duan wrote:
> .. as "nopv" support needs it to be changeable at boot up stage.
>
> Checkpatch reports warning, so move variable declarations from
> hypervisor.c to hypervisor.h
[]
> diff --git a/arch/x86/xen/enlighten_hvm.c
On 17.07.19 08:46, Joe Perches wrote:
On Tue, 2019-07-16 at 12:26 +0800, Zhenzhong Duan wrote:
.. as "nopv" support needs it to be changeable at boot up stage.
Checkpatch reports warning, so move variable declarations from
hypervisor.c to hypervisor.h
[]
diff --git
With non-empty CONFIG_DOM0_MEM clang5 produces
dom0_build.c:344:24: error: use of logical '&&' with constant operand
[-Werror,-Wconstant-logical-operand]
if ( !dom0_mem_set && CONFIG_DOM0_MEM[0] )
^ ~~
dom0_build.c:344:24: note: use '&' for a bitwise
This is to accompany commit ("x86/svm: Drop support for AMD's
Lightweight Profiling").
Signed-off-by: Jan Beulich
---
With AMD apparently having abandoned XOP encoded insns, another option
would seem to be to simply wire all unrecognized ones into #UD (rather
then returning
Also use this for AVX512_VBMI2 VPSH{L,R}D{,V}{D,Q,W} testing (only the
quad word right shifts get actually used; the assumption is that their
"left" counterparts as well as the double word and word forms then work
as well).
Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
---
v8: New.
---
Also use this for AVX512VL VPRO{L,R}{,V}D as well as some further shifts
testing.
Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
---
v8: New.
--- a/tools/tests/x86_emulator/Makefile
+++ b/tools/tests/x86_emulator/Makefile
@@ -20,8 +20,9 @@ SIMD := 3dnow sse sse2 sse4 avx avx2 xop
FMA :=
Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
---
v8: New.
--- a/tools/tests/x86_emulator/Makefile
+++ b/tools/tests/x86_emulator/Makefile
@@ -19,8 +19,9 @@ CFLAGS += $(CFLAGS_xeninclude)
SIMD := 3dnow sse sse2 sse4 avx avx2 xop avx512f avx512bw avx512dq avx512er
avx512vbmi
FMA :=
As to the feature dependency adjustment, just like for VPCLMULQDQ while
strictly speaking AVX is a sufficient prereq (to have YMM registers),
256-bit vectors of integers have got fully introduced with AVX2 only.
A new test case (also covering AESNI) will be added to the harness by a
subsequent
Incremental additions and/or mistakes have lead to some code blocks
sitting in "unexpected" places. Re-sort the case blocks (opcode space;
major opcode; 66/F3/F2 prefix; legacy/VEX/EVEX encoding).
As an exception the opcode space 0x0f EVEX-encoded VPEXTRW is left at
its current place, to keep it
As to the feature dependency adjustment, while strictly speaking SSE is
a sufficient prereq (to have XMM registers), vectors of bytes and qwords
have got introduced only with SSE2. gcc, for example, uses a similar
connection in its respective intrinsics header.
Signed-off-by: Jan Beulich
As to the feature dependency adjustment, while strictly speaking AVX is
a sufficient prereq (to have YMM registers), 256-bit vectors of integers
have got fully introduced with AVX2 only. Sadly gcc can't be used as a
reference here: They don't provide any AVX512-independent built-in at
all.
Along
Along the lines of the 4FMAPS case, convert the 4VNNIW-based table
entries to a decoder adjustment. Because of the current sharing of table
entries between different (implied) opcode prefixes and with the same
major opcodes being used for vp4dpwssd{,s}, which have a different
memory operand size
Once again take the liberty and also correct the (public interface) name
of the AVX512_IFMA feature flag to match the SDM, on the assumption that
no external consumer has actually been using that flag so far.
As in a few cases before, since the insns here and in particular their
memory access
As in a few cases before, since the insns here and in particular their
memory access patterns follow the AVX512_4FMAPS scheme, I didn't think
it was necessary to add contrived tests specifically for them, beyond
the Disp8 scaling ones.
Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
---
v9:
A decoder adjustment is needed here because of the current sharing of
table entries between different (implied) opcode prefixes: The same
major opcodes are used for vfmsub{132,213}{p,s}{s,d}, which have a
different memory operand size and different Disp8 scaling.
Signed-off-by: Jan Beulich
As in a few cases before, since the insns here and in particular their
memory access patterns follow the usual scheme, I didn't think it was
necessary to add a contrived test specifically for them, beyond the
Disp8 scaling one.
Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
---
v7: Re-base
Plus the only other AVX512_BITALG one.
As in a few cases before, since the insns here and in particular their
memory access patterns follow the usual scheme, I didn't think it was
necessary to add a contrived test specifically for them, beyond the
Disp8 scaling one.
Signed-off-by: Jan Beulich
01: support of AVX512* population count insns
02: support of AVX512_IFMA insns
03: support remaining AVX512_VBMI2 insns
04: support AVX512_4FMAPS insns
05: support AVX512_4VNNIW insns
06: support AVX512_VNNI insns
07: support VPCLMULQDQ insns
08: support VAES insns
09: support GFNI insns
10:
On 16.07.2019 18:35, Jan Beulich wrote:
> --- a/xen/drivers/passthrough/amd/iommu_detect.c
> +++ b/xen/drivers/passthrough/amd/iommu_detect.c
> @@ -60,49 +60,77 @@ static int __init get_iommu_capabilities
>
>void __init get_iommu_features(struct amd_iommu *iommu)
>{
> -u32 low,
99 matches
Mail list logo
