On 27/03/2019 17:52, Juergen Gross wrote:
> On 27/03/2019 17:38, Jan Beulich wrote:
> On 27.03.19 at 17:18, wrote:
>>> On 27/03/2019 16:55, Andrew Cooper wrote:
On 18/03/2019 13:11, Juergen Gross wrote:
> Instead of freeing percpu areas during suspend and allocating them
> again w
>>> On 18.03.19 at 14:11, wrote:
> Instead of freeing percpu areas during suspend and allocating them
> again when resuming keep them. Only free an area in case a cpu didn't
> come up again when resuming.
There's another aspect here which needs at least mentioning:
Right now, CPUs coming back up
On 28/03/2019 08:46, Jan Beulich wrote:
On 18.03.19 at 14:11, wrote:
>> Instead of freeing percpu areas during suspend and allocating them
>> again when resuming keep them. Only free an area in case a cpu didn't
>> come up again when resuming.
>
> There's another aspect here which needs at l
>>> On 28.03.19 at 07:59, wrote:
> On 27/03/2019 17:52, Juergen Gross wrote:
>> On 27/03/2019 17:38, Jan Beulich wrote:
>> On 27.03.19 at 17:18, wrote:
On 27/03/2019 16:55, Andrew Cooper wrote:
> On 18/03/2019 13:11, Juergen Gross wrote:
>> Instead of freeing percpu areas during
>>> On 28.03.19 at 08:53, wrote:
> On 28/03/2019 08:46, Jan Beulich wrote:
> On 18.03.19 at 14:11, wrote:
>>> Instead of freeing percpu areas during suspend and allocating them
>>> again when resuming keep them. Only free an area in case a cpu didn't
>>> come up again when resuming.
>>
>> Th
>>> On 27.03.19 at 18:28, wrote:
> This also lacks some of the features of mwait-idle has and duplicates
> the limited functionality.
Would you mind clarifying the lack-of-features aspect? The
only difference to your patches that I can spot is that you set
.target_residency in the static tables.
On 28/03/2019 09:03, Jan Beulich wrote:
On 28.03.19 at 07:59, wrote:
>> On 27/03/2019 17:52, Juergen Gross wrote:
>>> On 27/03/2019 17:38, Jan Beulich wrote:
>>> On 27.03.19 at 17:18, wrote:
> On 27/03/2019 16:55, Andrew Cooper wrote:
>> On 18/03/2019 13:11, Juergen Gross wrote:
On 28/03/2019 09:04, Jan Beulich wrote:
On 28.03.19 at 08:53, wrote:
>> On 28/03/2019 08:46, Jan Beulich wrote:
>> On 18.03.19 at 14:11, wrote:
Instead of freeing percpu areas during suspend and allocating them
again when resuming keep them. Only free an area in case a cpu didn
flight 134123 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134123/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd 4871e6f10ee5265bebc03fd9395874187de091b0
baseline version:
freebsd 17b9e44c40f
>>> On 27.03.19 at 18:07, wrote:
> On 3/27/19 11:12 AM, Jan Beulich wrote:
>> -
>> -static void __init xen_filter_cpu_maps(void)
>> +static void __init _get_smp_config(unsigned int early)
>> {
>> int i, rc;
>> unsigned int subtract = 0;
>>
>> -if (!xen_initial_domain())
>> +if
flight 134146 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134146/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-xs
Extend smbios type 2 struct to match specification, add support to
write it when customized string provided and no smbios passed in.
Signed-off-by: Xin Li
---
CC: Jan Beulich
CC: Igor Druzhinin
CC: Sergey Dyasli
CC: Andrew Cooper
v2
1: write the struct if any of the strings is provided
2: a
On 27.03.2019 18:07, Jan Beulich wrote:
On 27.03.19 at 16:21, wrote:
>> @@ -621,7 +623,7 @@ bool_t ept_handle_misconfig(uint64_t gpa)
>>
>> p2m_unlock(p2m);
>>
>> -return spurious ? (rc >= 0) : (rc > 0);
>> +return spurious && !rc;
>> }
>
> I think you've gone too far
>>> On 28.03.19 at 09:35, wrote:
> On 28/03/2019 09:03, Jan Beulich wrote:
> On 28.03.19 at 07:59, wrote:
>>> On 27/03/2019 17:52, Juergen Gross wrote:
On 27/03/2019 17:38, Jan Beulich wrote:
On 27.03.19 at 17:18, wrote:
>> On 27/03/2019 16:55, Andrew Cooper wrote:
>>>
On 27.03.2019 18:07, Jan Beulich wrote:
On 27.03.19 at 16:21, wrote:
>> @@ -621,7 +623,7 @@ bool_t ept_handle_misconfig(uint64_t gpa)
>>
>> p2m_unlock(p2m);
>>
>> -return spurious ? (rc >= 0) : (rc > 0);
>> +return spurious && !rc;
>> }
>
> I think you've gone too far
>>> On 27.03.19 at 20:53, wrote:
> This has been problematic since its introduction in Xen 4.3
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman
>>> On 27.03.19 at 19:45, wrote:
> Clang uses "-target" option for cross-compilation.
And all possible targets are always available? I'd like to point out
that CROSS_COMPILE can be used for other than actual cross
compilation, e.g. building with just an alternative tool chain
built for the same t
On 28/03/2019 09:55, Jan Beulich wrote:
On 27.03.19 at 19:45, wrote:
>> Clang uses "-target" option for cross-compilation.
> And all possible targets are always available? I'd like to point out
> that CROSS_COMPILE can be used for other than actual cross
> compilation, e.g. building with just
>>> On 28.03.19 at 11:14, wrote:
> On 28/03/2019 09:55, Jan Beulich wrote:
> On 27.03.19 at 19:45, wrote:
>>> Clang uses "-target" option for cross-compilation.
>> And all possible targets are always available? I'd like to point out
>> that CROSS_COMPILE can be used for other than actual cros
On 28/03/2019 10:28, Jan Beulich wrote:
On 28.03.19 at 11:14, wrote:
>> On 28/03/2019 09:55, Jan Beulich wrote:
>> On 27.03.19 at 19:45, wrote:
Clang uses "-target" option for cross-compilation.
>>> And all possible targets are always available? I'd like to point out
>>> that CROSS_
>>> On 28.03.19 at 10:05, wrote:
> --- a/tools/firmware/hvmloader/smbios.c
> +++ b/tools/firmware/hvmloader/smbios.c
> @@ -497,9 +497,11 @@ static void *
> smbios_type_2_init(void *start)
> {
> struct smbios_type_2 *p = (struct smbios_type_2 *)start;
> +const char *s;
> uint8_t *pt
>>> On 28.03.19 at 11:43, wrote:
> On 28/03/2019 10:28, Jan Beulich wrote:
> On 28.03.19 at 11:14, wrote:
>>> Using -target is from the Clang instructions on cross compilation, which
>>> say to do it this way. https://clang.llvm.org/docs/CrossCompilation.html
>>>
>>> The targets supported w
flight 134124 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134124/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-pvops
Hi Julien,
On Wed, 2019-03-27 at 18:45 +, Julien Grall wrote:
> Hi all,
>
> This series adds support to build Xen Arm with clang. This series was tested
> with clang 8.0.
>
> Note that I only did build for arm64. I still need to look at the arm32
> build.
>
I wonder if you have time to try
On Wed, Mar 27, 2019 at 08:32:28PM +, Paul Durrant wrote:
> > -Original Message-
> > From: Andrew Cooper
> > Sent: 27 March 2019 18:20
> > To: Paul Durrant ; xen-devel@lists.xenproject.org;
> > qemu-bl...@nongnu.org;
> > qemu-de...@nongnu.org
> > Cc: Kevin Wolf ; Stefano Stabellini
>
On 28/03/2019 11:40, Anthony PERARD wrote:
> On Wed, Mar 27, 2019 at 08:32:28PM +, Paul Durrant wrote:
>>> -Original Message-
>>> From: Andrew Cooper
>>> Sent: 27 March 2019 18:20
>>> To: Paul Durrant ; xen-devel@lists.xenproject.org;
>>> qemu-bl...@nongnu.org;
>>> qemu-de...@nongnu.or
Am 28.03.2019 um 12:46 hat Andrew Cooper geschrieben:
> On 28/03/2019 11:40, Anthony PERARD wrote:
> > On Wed, Mar 27, 2019 at 08:32:28PM +, Paul Durrant wrote:
> >>> -Original Message-
> >>> From: Andrew Cooper
> >>> Sent: 27 March 2019 18:20
> >>> To: Paul Durrant ;
> >>> xen-devel@l
cpu_disable_scheduler() is being called from __cpu_disable() today.
There is no need to execute it on the cpu just being disabled, so use
the CPU_DEAD case of the cpu notifier chain. Moving the call out of
stop_machine() context is fine, as we just need to hold the domain RCU
lock and need the sche
Today there is special handling in cpu_disable_scheduler() for suspend
by forcing all vcpus to the boot cpu. In fact there is no need for that
as during resume the vcpus are put on the correct cpus again.
So we can just omit the call of cpu_disable_scheduler() when offlining
a cpu due to suspend a
Instead of removing cpus temporarily from cpupools during
suspend/resume only remove cpus finally which didn't come up when
resuming.
Signed-off-by: Juergen Gross
Reviewed-by: George Dunlap
Reviewed-by: Dario Faggioli
---
V2:
- add comment (George Dunlap)
---
xen/common/cpupool.c | 131 +
Add a helper cpu_notifier_call_chain() to call notifier_call_chain()
for a cpu with a specified action, returning an errno value.
This avoids coding the same pattern multiple times.
While at it avoid side effects from using BUG_ON() by not using
cpu_online(cpu) as a parameter.
Signed-off-by: Jue
Instead of freeing percpu areas during suspend and allocating them
again when resuming keep them. Only free an area in case a cpu didn't
come up again when resuming.
It should be noted that there is a potential change in behaviour as
the percpu areas are no longer zeroed out during suspend/resume.
Especially in the scheduler area (schedule.c, cpupool.c) there is a
rather complex handling involved when doing suspend and resume.
This can be simplified a lot by not performing a complete cpu down and
up cycle for the non-boot cpus, but keeping the pure software related
state and freeing it only
Add a new cpu notifier action CPU_RESUME_FAILED which is called for all
cpus which failed to come up at resume. The calls will be done after
all other cpus are already up in order to know which resources are
available then.
Signed-off-by: Juergen Gross
Reviewed-by: Dario Faggioli
Reviewed-by: Ge
On Thu, 2019-02-07 at 16:44 +, Wei Liu wrote:
> This series switches xen page tables from xenheap page to domheap
> page.
>
> This is required so that when we implement xenheap on top of vmap
> there won't
> be a loop.
>
> It is done in roughly three steps:
>
> 1. Introduce a new set of APIs
flight 134134 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134134/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken
build-arm64
Hello Juergen,
On Thu, 28 Mar 2019 at 14:09, Juergen Gross wrote:
>
> Especially in the scheduler area (schedule.c, cpupool.c) there is a
> rather complex handling involved when doing suspend and resume.
>
> This can be simplified a lot by not performing a complete cpu down and
> up cycle for the
flight 134154 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134154/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-xs
On 28/03/2019 14:01, Volodymyr Babchuk wrote:
> Hello Juergen,
>
> On Thu, 28 Mar 2019 at 14:09, Juergen Gross wrote:
>>
>> Especially in the scheduler area (schedule.c, cpupool.c) there is a
>> rather complex handling involved when doing suspend and resume.
>>
>> This can be simplified a lot by
On 3/22/19 10:22 AM, Hans Verkuil wrote:
On 3/22/19 8:37 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
This is the ABI for the two halves of a para-virtualized
camera driver which extends Xen's reach multimedia capabilities even
farther enabling it for video conferencing, In
On 3/28/19 1:21 PM, Juergen Gross wrote:
On 28/03/2019 14:01, Volodymyr Babchuk wrote:
Hello Juergen,
On Thu, 28 Mar 2019 at 14:09, Juergen Gross wrote:
Especially in the scheduler area (schedule.c, cpupool.c) there is a
rather complex handling involved when doing suspend and resume.
This
Hi,
On 3/28/19 1:01 PM, Volodymyr Babchuk wrote:
Hello Juergen,
On Thu, 28 Mar 2019 at 14:09, Juergen Gross wrote:
Especially in the scheduler area (schedule.c, cpupool.c) there is a
rather complex handling involved when doing suspend and resume.
This can be simplified a lot by not performi
Hi,
On Thu, 28 Mar 2019 at 15:21, Juergen Gross wrote:
>
> On 28/03/2019 14:01, Volodymyr Babchuk wrote:
> > Hello Juergen,
> >
> > On Thu, 28 Mar 2019 at 14:09, Juergen Gross wrote:
> >>
> >> Especially in the scheduler area (schedule.c, cpupool.c) there is a
> >> rather complex handling involv
On 28/03/2019 14:33, Julien Grall wrote:
> Hi,
>
> On 3/28/19 1:01 PM, Volodymyr Babchuk wrote:
>> Hello Juergen,
>>
>> On Thu, 28 Mar 2019 at 14:09, Juergen Gross wrote:
>>>
>>> Especially in the scheduler area (schedule.c, cpupool.c) there is a
>>> rather complex handling involved when doing su
>>> On 28.03.19 at 13:06, wrote:
> Instead of freeing percpu areas during suspend and allocating them
> again when resuming keep them. Only free an area in case a cpu didn't
> come up again when resuming.
>
> It should be noted that there is a potential change in behaviour as
> the percpu areas a
On 28/03/2019 13:37, Juergen Gross wrote:
> On 28/03/2019 14:33, Julien Grall wrote:
>> Hi,
>>
>> On 3/28/19 1:01 PM, Volodymyr Babchuk wrote:
>>> Hello Juergen,
>>>
>>> On Thu, 28 Mar 2019 at 14:09, Juergen Gross wrote:
Especially in the scheduler area (schedule.c, cpupool.c) there is
Hello Julien,
On Thu, 28 Mar 2019 at 15:33, Julien Grall wrote:
>
> Hi,
>
> On 3/28/19 1:01 PM, Volodymyr Babchuk wrote:
> > Hello Juergen,
> >
> > On Thu, 28 Mar 2019 at 14:09, Juergen Gross wrote:
> >>
> >> Especially in the scheduler area (schedule.c, cpupool.c) there is a
> >> rather complex
Extend smbios type 2 struct to match specification, add support to
write it when customized string provided and no smbios passed in.
Signed-off-by: Xin Li
---
CC: Jan Beulich
CC: Igor Druzhinin
CC: Sergey Dyasli
CC: Andrew Cooper
v2
1: write the struct if any of the strings is provided
2: a
> -Original Messages-
> From: "Markus Armbruster"
> Sent Time: 2019-03-20 02:34:45 (Wednesday)
> To: qemu-de...@nongnu.org
> Cc: "Edgar E. Iglesias" , "Hervé Poussineau"
> , "Aleksandar Markovic" ,
> "Aleksandar Rikalo" , "Alexander Graf" ,
> "Andrey Smirnov" , "Andrzej Zaborowski"
> ,
flight 83836 distros-debian-wheezy real [real]
http://osstest.xensource.com/osstest/logs/83836/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvopsbroken
build-i386
>>> On 28.03.19 at 14:56, wrote:
> Extend smbios type 2 struct to match specification, add support to
> write it when customized string provided and no smbios passed in.
>
> Signed-off-by: Xin Li
Reviewed-by: Jan Beulich
with one minor remaining remark:
> @@ -518,8 +520,71 @@ smbios_type_2_i
This is a first preparatory step for enabling x2APIC support also
for AMD (plus some misc cleanup).
1: entry: drop unused header inclusions
2: APIC: suppress redundant "Switched to ..." messages
3: ACPI: also parse AMD IOMMU tables early
4: IOMMU: introduce init-ops structure
5: IOMMU: abstract In
Hi,
On 3/28/19 1:56 PM, Volodymyr Babchuk wrote:
On Thu, 28 Mar 2019 at 15:33, Julien Grall wrote:
On 3/28/19 1:01 PM, Volodymyr Babchuk wrote:
On Thu, 28 Mar 2019 at 14:09, Juergen Gross wrote:
(XEN)
(XEN) Panic on CPU 0:
(XEN) PSCI cpu off failed
I'm in particular after getting rid of asm/apicdef.h, but there are more
no longer (or perhaps never having been) used ones.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/svm/entry.S
+++ b/xen/arch/x86/hvm/svm/entry.S
@@ -19,13 +19,8 @@
.file "svm/entry.S"
-#include
-#include
On 3/27/19 2:38 PM, Andrew Cooper wrote:
> On 26/03/2019 13:39, Jan Beulich wrote:
> On 26.03.19 at 13:43, wrote:
>>> On 26/03/2019 09:08, Jan Beulich wrote:
>>> Leave the warning which identifies the problematic devices, but drop the
>>> remaining logic. This leaves the system in bet
There's no need to log anything when what we "switch to" is what is in
use already.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/apic.c
+++ b/xen/arch/x86/apic.c
@@ -884,6 +884,7 @@ void x2apic_ap_setup(void)
void __init x2apic_bsp_setup(void)
{
struct IO_APIC_route_entry **ioapic_entrie
In order to be able to initialize x2APIC mode we need to parse
respective ACPI tables early. Split amd_iov_detect() into two parts for
this purpose, and call the initial part earlier on.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/acpi/boot.c
+++ b/xen/arch/x86/acpi/boot.c
@@ -733,7 +733,7 @@
Do away with the CPU vendor dependency, and set the init ops pointer
based on what ACPI tables have been found.
Also take the opportunity and add __read_mostly to iommu_ops.
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
+++ b/xen/drivers/passthrough/amd/pci_amd_io
Introduce a respective element in struct iommu_init_ops.
Take the liberty and also switch intel_iommu_supports_eim() to bool/
true/false, to fully match the hook's type.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/apic.c
+++ b/xen/arch/x86/apic.c
@@ -899,14 +899,14 @@ void __init x2apic_bsp_s
Introduce respective elements in struct iommu_init_ops as well as a
pointer to the main ops structure.
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/vtd/extern.h
+++ b/xen/drivers/passthrough/vtd/extern.h
@@ -35,6 +35,8 @@ void print_vtd_entries(struct iommu *iom
keyhandler_fn_t vtd_
On Thu, 2019-03-28 at 15:56 +0200, Volodymyr Babchuk wrote:
> On Thu, 28 Mar 2019 at 15:33, Julien Grall
> wrote:
> >
> Are the logs below actually a mistaken paste?
> No, this is what I'm seeing in my serial console.
>
Err, sorry, I'm a bit confused now...
So, if you use the ARM suspend/resume
Move this into iommu_hardware_setup() and make that function non-
inline. Move its declaration into common code.
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
@@ -31,7 +31,6 @@
static bool_t __read_mostly init_done
Hello Dario,
On Thu, 28 Mar 2019 at 16:54, Dario Faggioli wrote:
>
> On Thu, 2019-03-28 at 15:56 +0200, Volodymyr Babchuk wrote:
> > On Thu, 28 Mar 2019 at 15:33, Julien Grall
> > wrote:
> > >
> > Are the logs below actually a mistaken paste?
> > No, this is what I'm seeing in my serial console.
On 3/28/19 3:26 AM, Jan Beulich wrote:
On 27.03.19 at 18:28, wrote:
>> This also lacks some of the features of mwait-idle has and duplicates
>> the limited functionality.
>
> Would you mind clarifying the lack-of-features aspect? The
> only difference to your patches that I can spot is that
This patch series add support and enablement for mwait on AMD Naples
and Rome processors. Newer AMD processors support mwait, but only for
c1, and for c2 halt is used. The mwait-idle driver is modified to be
able to use both mwait and halt for idling.
Brian Woods (3):
mwait-idle: add support f
From: Brian Woods
Newer AMD processors (F17h) have mwait support which is compatible with
Intel. Add some checks to make sure vendor specific code is run
correctly and some infrastructure to facilitate adding AMD processors.
This is done so that Xen will not be reliant on dom0 passing the parse
From: Brian Woods
Some AMD processors can use a mixture of mwait and halt for accessing
various c-states. In preparation for adding support for AMD processors,
update the mwait-idle driver to optionally use halt.
Signed-off-by: Brian Woods
---
xen/arch/x86/acpi/cpu_idle.c | 2 +-
xen/arch/x
From: Brian Woods
Add the needed data structures for enabling Naples (F17h M01h). Since
Rome (F17h M31h) has the same c-state latencies and entry methods, the
c-state information can be used for Rome as well. For both Naples and
Rome, mwait is used for c1 (cc1) and halt is functionally the same
On 3/26/19 1:39 PM, Jan Beulich wrote:
>> This is a regression in 4.12 and needs resolving. The choice is between
>> reverting dcf41790 or removing this code, and reverting dcf41790 is
>> obviously not a valid thing to do.
>
> As explained before, there was an earlier regression, which - if it
>
Credit2's smt_idle_mask_set() and smt_idle_mask_clear() are used to
identify idle cores where vcpus can be moved to. A core is thought to
be idle when all siblings are known to have the idle vcpu running on
them.
Unfortunately the information of a vcpu running on a cpu is per
runqueue. So in case
>>> On 28.03.19 at 16:02, wrote:
> On 3/28/19 3:26 AM, Jan Beulich wrote:
> On 27.03.19 at 18:28, wrote:
>>> This also lacks some of the features of mwait-idle has and duplicates
>>> the limited functionality.
>>
>> Would you mind clarifying the lack-of-features aspect? The
>> only differenc
>>> On 28.03.19 at 16:06, wrote:
> On 3/26/19 1:39 PM, Jan Beulich wrote:
>>> This is a regression in 4.12 and needs resolving. The choice is between
>>> reverting dcf41790 or removing this code, and reverting dcf41790 is
>>> obviously not a valid thing to do.
>>
>> As explained before, there wa
On 28/03/2019 14:48, Jan Beulich wrote:
> I'm in particular after getting rid of asm/apicdef.h, but there are more
> no longer (or perhaps never having been) used ones.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing li
On 3/28/19 10:50 AM, Jan Beulich wrote:
On 28.03.19 at 16:02, wrote:
>> On 3/28/19 3:26 AM, Jan Beulich wrote:
>> On 27.03.19 at 18:28, wrote:
This also lacks some of the features of mwait-idle has and duplicates
the limited functionality.
>>>
>>> Would you mind clarifying the
flight 134142 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134142/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64
On 28/03/2019 14:49, Jan Beulich wrote:
> There's no need to log anything when what we "switch to" is what is in
> use already.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https:/
On 3/28/19 5:03 AM, Jan Beulich wrote:
On 27.03.19 at 18:07, wrote:
>> On 3/27/19 11:12 AM, Jan Beulich wrote:
>>> -
>>> -static void __init xen_filter_cpu_maps(void)
>>> +static void __init _get_smp_config(unsigned int early)
>>> {
>>> int i, rc;
>>> unsigned int subtract = 0;
>>>
On 28/03/2019 14:49, Jan Beulich wrote:
> In order to be able to initialize x2APIC mode we need to parse
> respective ACPI tables early. Split amd_iov_detect() into two parts for
> this purpose, and call the initial part earlier on.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
> --
Reported-by: George Dunlap
Signed-off-by: Jan Beulich
---
This is surely a stable tree candidate, unless it could still make it
into 4.12 before the release.
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -3511,7 +3511,7 @@ x86_emulate(
}
On 28/03/2019 14:51, Jan Beulich wrote:
> Do away with the CPU vendor dependency, and set the init ops pointer
> based on what ACPI tables have been found.
"based on which APCI tables..."
>
> Also take the opportunity and add __read_mostly to iommu_ops.
>
> Signed-off-by: Jan Beulich
Reviewed-b
On 28/03/2019 14:52, Jan Beulich wrote:
> Introduce a respective element in struct iommu_init_ops.
>
> Take the liberty and also switch intel_iommu_supports_eim() to bool/
> true/false, to fully match the hook's type.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
flight 134143 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134143/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8028f03032182f2c72e7699e1d14322bb5586581
baseline version:
ovmf c455bc8c8d78ad51c2442
On 28/03/2019 14:53, Jan Beulich wrote:
> @@ -35,6 +35,8 @@ void print_vtd_entries(struct iommu *iom
> keyhandler_fn_t vtd_dump_iommu_info;
>
> bool intel_iommu_supports_eim(void);
> +int intel_iommu_enable_x2apic_IR(void);
> +void intel_iommu_disable_x2apic_IR(void);
Is there any particular r
Hi,
I've been working on adding PVH support to OVMF and boot Linux with it.
The last issue I had was a guest crash without any error messages.
Tests done with Linux 4.20.12-arch1-1-ARCH.
In this mail, I'll discuss about two issues:
- Linux oops/panic but don't print anything in the console.
- Lin
On 3/28/19 5:03 PM, Jan Beulich wrote:
> Reported-by: George Dunlap
> Signed-off-by: Jan Beulich
That seems to fix all the ones related to the crashes I was seeing:
Tested-by: George Dunlap
> ---
> This is surely a stable tree candidate, unless it could still make it
> into 4.12 before the re
On 28/03/2019 14:54, Jan Beulich wrote:
> --- a/xen/drivers/passthrough/x86/iommu.c
> +++ b/xen/drivers/passthrough/x86/iommu.c
> @@ -26,6 +26,19 @@
> const struct iommu_init_ops *__initdata iommu_init_ops;
> struct iommu_ops __read_mostly iommu_ops;
>
> +int __init iommu_hardware_setup(void)
>
On 28/03/2019 17:44, George Dunlap wrote:
> On 3/28/19 5:03 PM, Jan Beulich wrote:
>> Reported-by: George Dunlap
>> Signed-off-by: Jan Beulich
> That seems to fix all the ones related to the crashes I was seeing:
>
> Tested-by: George Dunlap
>
>> ---
>> This is surely a stable tree candidate, un
flight 134139 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134139/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken
build-arm64-xsm
Hello everyone,
I'm Spencer Michaels, creator of Xendbg, a recently-released full-featured
debugger for both HVM and PV Xen guests. I developed Xendbg under the
auspices
of my company, NCC Group, and released it via a post on their blog about two
months ago. Andrew Cooper kindly pointed out to me
flight 134160 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134160/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-xs
This run is configured for baseline tests only.
flight 83838 ovmf real [real]
http://osstest.xensource.com/osstest/logs/83838/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm
flight 134149 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134149/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken
build-arm64
On Wed, Mar 27, 2019 at 08:40:20AM +0200, Oleksandr Andrushchenko wrote:
> On 3/25/19 7:30 PM, Anchal Agarwal wrote:
> >On Fri, Mar 22, 2019 at 10:44:33AM +, Oleksandr Andrushchenko wrote:
> >>On 3/20/19 5:50 AM, Munehisa Kamata wrote:
> >>>On 3/18/2019 3:02 AM, Oleksandr Andrushchenko wrote:
>
flight 134048 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134048/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken
build-arm64
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-freebsd10-amd64
testid guest-saverestore
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git:/
flight 134169 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134169/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-xs
flight 134156 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134156/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64
Extend smbios type 2 struct to match specification, add support to
write it when customized string provided and no smbios passed in.
Signed-off-by: Xin Li
Reviewed-by: Jan Beulich
---
CC: Jan Beulich
CC: Igor Druzhinin
CC: Sergey Dyasli
CC: Andrew Cooper
v2
1: write the struct if any of th
flight 134158 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134158/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64
flight 134162 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134162/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-pvops
100 matches
Mail list logo
