Hi Stefano,
How to test this, do I need this patch-set only or are there any more
dependencies.
Since this patch is for cavium thunderx, I had sent few months back series for
vgic errata [1].
Havent got any comment on that.
Could you please see if that can be merged with this ? or if any change
flight 126288 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126288/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install
fail never pass
test-amd64-i386-xl
This run is configured for baseline tests only.
flight 75100 qemu-mainline real [real]
http://osstest.xensource.com/osstest/logs/75100/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-raw 19 guest-start/debian.repeat
flight 126270 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126270/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-rumprun-i386 12 guest-start fail REGR. vs. 126042
test-amd64-i386-qemu
flight 126340 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126340/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf cc6939067008c4dcab990d5e8be65086ec393afa
baseline version:
ovmf 6cf6fed02408b5f3ba39d
pci_conf_read8() needs pci mmcfg mapping to work on multiple pci
segments system such as HPE Superdome-Flex.
Move acpi_mmcfg_init() call in acpi_boot_init() before calling
acpi_parse_dmar() so that when pci_conf_read8() is called in
acpi_parse_dev_scope(), we already have the mapping set up.
mmio
Commit 6c298ecc1f ("vtd: Reinstate ACPI DMAR on system shutdown or
S3/S4/S5") did everything for acpi_dmar_zap() call to be unnecessary,
except for invoking the function from acpi_parse_dmar(), which
123c779379 ("VTd/dmar: Tweak how the DMAR table is clobbered")
added several years later.
Some sta
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, August 21, 2018 8:32 PM
>
> >>> On 21.08.18 at 11:11, wrote:
> > @@ -490,10 +488,6 @@ int __init
> tboot_parse_dmar_table(acpi_table_handler dmar_handler)
> > rc = dmar_handler(dmar_table);
> > xfree(dmar_table);
> >
> > -
> From: Zhenzhong Duan [mailto:zhenzhong.d...@oracle.com]
> Sent: Monday, August 20, 2018 6:43 PM
>
> Release memory allocated for drhd iommu in error path.
>
> -v2: fixup wrong parameter hiden due to my removing -Werror
>
> Signed-off-by: Zhenzhong Duan
Acked-by: Kevin Tian
_
> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Tuesday, August 21, 2018 11:58 PM
> To: Jan Beulich; Zhang, Yu C
> Cc: davorin.mi...@aggios.com; mirela.simono...@aggios.com; Brian Woods;
> JanakarajanNatarajan; Julien Grall; Matt Spencer; robin.randh.
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: Friday, August 17, 2018 11:12 PM
>
> Signed-off-by: Wei Liu
Acked-by: Kevin Tian
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: Tuesday, August 21, 2018 3:50 PM
>
> Several people have reported hardware issues (malfunctioning USB
> controllers) due to iommu page faults on Intel hardware. Those faults
> are caused by missing RMRR (VTd) entries in the ACPI tables.
> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: Tuesday, August 21, 2018 3:50 PM
>
> To iommu_hwdom_strict and iommu_hwdom_passthrough which is more
> descriptive of their usage. Also change their type from bool_t to
> bool.
>
> No functional change.
>
> Signed-off-by: Roger Pau Mo
> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: Tuesday, August 21, 2018 3:50 PM
>
> Introduce a new dom0-iommu=map-inclusive generic option that
> supersedes iommu_inclusive_mapping. The previous behavior is preserved
> and the option should only be enabled by default on Intel hardw
flight 75099 distros-debian-snapshot real [real]
http://osstest.xensource.com/osstest/logs/75099/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-i386-daily-netboot-pvgrub 10 debian-di-install fail REGR. vs.
75067
Tests whic
> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: Tuesday, August 14, 2018 9:44 PM
>
> Introduce a new dom0-iommu=map-inclusive generic option that
> supersedes iommu_inclusive_mapping. The previous behavior is preserved
> and the option should only be enabled by default on Intel hardw
> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: Tuesday, August 14, 2018 9:43 PM
>
> To iommu_hwdom_strict and iommu_hwdom_passthrough which is more
> descriptive of their usage. Also change their type from bool_t to
> bool.
>
> No functional change.
>
> Signed-off-by: Roger Pau Mo
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, August 15, 2018 7:34 PM
>
> It took till the 4.5 backports of the L1TF prereqs that gcc 8.2 finally
> noticed that the vPMU callers, not checking the function's return value,
> may consume uninitialized data. Guard against this by s
On Thu, Aug 16, 2018 at 9:19 PM, Sarah Newman wrote:
> commit b3681dd548d06deb2e1573890829dff4b15abf46 upstream.
>
> This version applies to v4.9.
...
Looks okay to me.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject
flight 126277 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126277/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 123814
build-amd64-libvirt
This run is configured for baseline tests only.
flight 75098 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75098/
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 75094
test
flight 126266 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126266/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 126012
test-armhf-armhf-libvirt 14 save
flight 126259 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126259/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-rumprun-amd64 12 guest-startfail REGR. vs. 125183
test-amd64-amd64-libv
On Tue, Aug 21, 2018 at 11:59:26AM -0700, Stefano Stabellini wrote:
> On Tue, 21 Aug 2018, Julien Grall wrote:
> > On 08/21/2018 07:49 PM, Wei Liu wrote:
> > > On Tue, Aug 21, 2018 at 07:33:56PM +0100, Julien Grall wrote:
> > > > Hi Wei,
> > > >
> > > > On 08/21/2018 05:31 PM, Wei Liu wrote:
> > >
flight 126315 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126315/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 6cf6fed02408b5f3ba39de46cbc971b9dda3639b
baseline version:
ovmf 131818ba5a83d1e8f3f1b
On 08/21/2018 12:59 AM, Stefano Stabellini wrote:
Hi all,
Hi,
Please avoid using my linaro e-mail for Xen patches.
This patch series introduces one kconfig option for each remain
platform under platforms/. Each kconfig option enables the required
drivers in Xen.
Most of the platforms below
On Tue, 21 Aug 2018, Julien Grall wrote:
> On 08/21/2018 07:49 PM, Wei Liu wrote:
> > On Tue, Aug 21, 2018 at 07:33:56PM +0100, Julien Grall wrote:
> > > Hi Wei,
> > >
> > > On 08/21/2018 05:31 PM, Wei Liu wrote:
> > > > On Mon, Aug 20, 2018 at 05:51:28AM -0600, Jan Beulich wrote:
> > > > > > > >
On 08/21/2018 07:49 PM, Wei Liu wrote:
On Tue, Aug 21, 2018 at 07:33:56PM +0100, Julien Grall wrote:
Hi Wei,
On 08/21/2018 05:31 PM, Wei Liu wrote:
On Mon, Aug 20, 2018 at 05:51:28AM -0600, Jan Beulich wrote:
On 17.08.18 at 17:12, wrote:
Since it is defined in common header file, introduc
On Tue, Aug 21, 2018 at 07:33:56PM +0100, Julien Grall wrote:
> Hi Wei,
>
> On 08/21/2018 05:31 PM, Wei Liu wrote:
> > On Mon, Aug 20, 2018 at 05:51:28AM -0600, Jan Beulich wrote:
> > > > > > On 17.08.18 at 17:12, wrote:
> > > > Since it is defined in common header file, introduce CONFIG_HVM to
>
On 08/20/2018 10:46 AM, Omkar Bolla wrote:
Hi Julien,
Hello,
I tried today with your patch in xen-4.11
Can you please bisect Xen tree?
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject
Hi Wei,
On 08/21/2018 11:41 AM, Wei Liu wrote:
On Mon, Aug 20, 2018 at 01:59:57PM +0100, Andrew Cooper wrote:
On 17/08/2018 16:12, Wei Liu wrote:
Signed-off-by: Wei Liu
---
xen/common/domain.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/xen/common/domain.c b/
Hi Wei,
On 08/21/2018 05:31 PM, Wei Liu wrote:
On Mon, Aug 20, 2018 at 05:51:28AM -0600, Jan Beulich wrote:
On 17.08.18 at 17:12, wrote:
Since it is defined in common header file, introduce CONFIG_HVM to
Arm to avoid breakage.
Signed-off-by: Wei Liu
---
xen/arch/arm/Kconfig| 3 +++
x
flight 126333 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126333/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
On Tue, 21 Aug 2018, Andrii Anisov wrote:
> Hello Stefano,
>
>
> On 21.08.18 02:59, Stefano Stabellini wrote:
> > Add a kconfig option for TI OMAP5 platforms.
> >
> > Signed-off-by: Stefano Stabellini
> > CC: baoz...@gmail.com
> > --
>
> Reviewed-by: Andrii Anisov
> *Andrii Anisov*
Hi Andri
flight 126246 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126246/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow210 debian-di-installfail REGR. vs. 126069
test-amd64-amd64-rum
On Mon, Aug 20, 2018 at 05:51:28AM -0600, Jan Beulich wrote:
> >>> On 17.08.18 at 17:12, wrote:
> > Since it is defined in common header file, introduce CONFIG_HVM to
> > Arm to avoid breakage.
> >
> > Signed-off-by: Wei Liu
> > ---
> > xen/arch/arm/Kconfig| 3 +++
> > xen/include/xen/sched
>>> On 21.08.18 at 18:02, wrote:
> On Tue, Aug 21, 2018 at 09:40:07AM -0600, Jan Beulich wrote:
>> >>> On 21.08.18 at 15:43, wrote:
>> > On Tue, Aug 21, 2018 at 05:52:39AM -0600, Jan Beulich wrote:
>> >> >>> On 17.08.18 at 17:12, wrote:
>> >> > --- a/xen/arch/x86/sysctl.c
>> >> > +++ b/xen/arch/
On Tue, Aug 21, 2018 at 09:40:07AM -0600, Jan Beulich wrote:
> >>> On 21.08.18 at 15:43, wrote:
> > On Tue, Aug 21, 2018 at 05:52:39AM -0600, Jan Beulich wrote:
> >> >>> On 17.08.18 at 17:12, wrote:
> >> > --- a/xen/arch/x86/sysctl.c
> >> > +++ b/xen/arch/x86/sysctl.c
> >> > @@ -92,8 +92,10 @@ vo
On 21/08/2018 16:51, Jan Beulich wrote:
On 21.08.18 at 17:28, wrote:
>> Thanks Lars for the summary, and sorry for the late update.
>>
>> My question is about the cpuid policy for MAXPHYSADDR in Xen.
>>
>> It seems Xen is exposing the host MAXPHYSADDR value to HVM as the default
>> choice.
>>> On 21.08.18 at 17:37, wrote:
> Using only 32-bit writes for the pte will result in an intermediate
> L1TF vulnerable PTE. When running as a Xen PV guest this will at once
> switch the guest to shadow mode resulting in a loss of performance.
>
> Use arch_atomic64_xchg() instead which will perf
>>> On 21.08.18 at 15:59, wrote:
> On 21/08/18 14:40, Jan Beulich wrote:
> On 21.08.18 at 14:13, wrote:
>>> On 21/08/18 12:44, Jan Beulich wrote:
@@ -219,17 +216,13 @@ static int __init parse_spec_ctrl(const
}
custom_param("spec-ctrl", parse_spec_ctrl);
-int8_t __
>>> On 21.08.18 at 17:26, wrote:
> On Tue, Aug 21, 2018 at 06:53:05AM -0600, Jan Beulich wrote:
>> >>> On 21.08.18 at 09:49, wrote:
>> > Returns all the memory types applicable to a page.
>> >
>> > This function is unimplemented for ARM.
>> >
>> > Signed-off-by: Roger Pau Monné
>>
>> Reviewed
flight 126329 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126329/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
>>> On 21.08.18 at 17:28, wrote:
> Thanks Lars for the summary, and sorry for the late update.
>
> My question is about the cpuid policy for MAXPHYSADDR in Xen.
>
> It seems Xen is exposing the host MAXPHYSADDR value to HVM as the default
> choice. And I am wondering, what if a VM is created o
>>> On 21.08.18 at 17:22, wrote:
> On Tue, Aug 21, 2018 at 07:36:17AM -0600, Jan Beulich wrote:
>> >>> On 21.08.18 at 09:49, wrote:
>> > --- a/docs/misc/xen-command-line.markdown
>> > +++ b/docs/misc/xen-command-line.markdown
>> > @@ -704,6 +704,15 @@ This list of booleans controls the iommu usag
>>> On 21.08.18 at 15:43, wrote:
> On Tue, Aug 21, 2018 at 05:52:39AM -0600, Jan Beulich wrote:
>> >>> On 17.08.18 at 17:12, wrote:
>> > --- a/xen/arch/x86/sysctl.c
>> > +++ b/xen/arch/x86/sysctl.c
>> > @@ -92,8 +92,10 @@ void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
>> > min(
While the hypervisor emulates plain writes to PTEs happily, this is
much slower than issuing a hypercall for PTE modifcations. And writing
a PTE via two 32-bit write instructions (especially when clearing the
PTE) will result in an intermediate L1TF vulnerable PTE.
Writes to PAE PTEs should always
In some cases 32-bit PAE PV guests still write PTEs directly instead of
using hypercalls. This is especially bad when clearing a PTE as this is
done via 32-bit writes which will produce intermediate L1TF attackable
PTEs.
Change the code to use hypercalls instead.
Signed-off-by: Juergen Gross
Rev
Using only 32-bit writes for the pte will result in an intermediate
L1TF vulnerable PTE. When running as a Xen PV guest this will at once
switch the guest to shadow mode resulting in a loss of performance.
Use arch_atomic64_xchg() instead which will perform the requested
operation atomically with
Dario Faggioli writes ("Re: [Xen-devel] [PATCH] tools: libxl/xl: run NUMA
placement even when an hard-affinity is set"):
> Do I leave it under this special "manually enable for development and
> testing" kind of thing?
Yes, I think #ifdef DEBUG or whatever is fine. libxl_event.c has that
style a
Thanks Lars for the summary, and sorry for the late update.
My question is about the cpuid policy for MAXPHYSADDR in Xen.
It seems Xen is exposing the host MAXPHYSADDR value to HVM as the default
choice. And I am wondering, what if a VM is created on a hardware platform with
address width A, a
On Tue, Aug 21, 2018 at 06:53:05AM -0600, Jan Beulich wrote:
> >>> On 21.08.18 at 09:49, wrote:
> > Returns all the memory types applicable to a page.
> >
> > This function is unimplemented for ARM.
> >
> > Signed-off-by: Roger Pau Monné
>
> Reviewed-by: Jan Beulich
>
> But this should only
On Tue, Aug 21, 2018 at 07:36:17AM -0600, Jan Beulich wrote:
> >>> On 21.08.18 at 09:49, wrote:
> > --- a/docs/misc/xen-command-line.markdown
> > +++ b/docs/misc/xen-command-line.markdown
> > @@ -704,6 +704,15 @@ This list of booleans controls the iommu usage by Dom0:
> >option is only applica
On Tue, 2018-08-21 at 11:25 +0100, Ian Jackson wrote:
> Dario Faggioli writes ("Re: [Xen-devel] [PATCH] tools: libxl/xl: run
> NUMA placement even when an hard-affinity is set"):
> > On Mon, 2018-08-20 at 11:14 +0100, Wei Liu wrote:
> > > You can use NDEBUG instead.
> >
> > But I don't have a too
On 08/15/2018 01:07 PM, Andrew Cooper wrote:
> OSVW data is technically per-cpu, but it is the firmwares reponsibility to
> make it equivelent on each cpu. A guests OSVW data is sources from global
> data in Xen, clearly making it per-domain data rather than per-vcpu data.
>
> Move the data from s
Anthony PERARD writes ("Re: [Xen-devel] [PATCH v4 22/32] libxl_qmp: Handle
messages from QEMU"):
> I've already tried to have qmp specific error number, I've been asked to
> invent libxl error number instead:
> https://lists.xenproject.org/archives/html/xen-devel/2018-07/msg01151.html
I stand by
On Tue, Aug 21, 2018 at 01:58:51AM -0600, Jan Beulich wrote:
> >>> On 17.08.18 at 17:12, wrote:
> > Move it to x86 generic code. While at it, use proper boolean type.
> >
> > Signed-off-by: Wei Liu
>
> Acked-by: Jan Beulich
> with a couple of cosmetic adjustments beyond the bool
> conversion y
On 21/08/18 14:40, Jan Beulich wrote:
On 21.08.18 at 14:13, wrote:
>> On 21/08/18 12:44, Jan Beulich wrote:
>>> @@ -219,17 +216,13 @@ static int __init parse_spec_ctrl(const
>>> }
>>> custom_param("spec-ctrl", parse_spec_ctrl);
>>>
>>> -int8_t __read_mostly opt_pv_l1tf = -1;
>>> +uint8_t
On Tue, Aug 21, 2018 at 05:52:39AM -0600, Jan Beulich wrote:
> >>> On 17.08.18 at 17:12, wrote:
> > --- a/xen/arch/x86/sysctl.c
> > +++ b/xen/arch/x86/sysctl.c
> > @@ -92,8 +92,10 @@ void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
> > min(sizeof(pi->hw_cap), sizeof(boot_cpu_data.
>>> On 21.08.18 at 09:49, wrote:
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -704,6 +704,15 @@ This list of booleans controls the iommu usage by Dom0:
>option is only applicable to a PV Dom0 and is enabled by default on Intel
>hardware.
>
flight 126324 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126324/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
>>> On 21.08.18 at 09:49, wrote:
> This avoids repeated calls to page_is_ram_type which improves
> performance and makes the code easier to read.
>
> No functional change.
>
> Signed-off-by: Roger Pau Monné
I can't seem to be able to fully convince myself of the "No functional
change" part, bu
On Tue, Aug 21, 2018 at 10:08:49AM +0100, Wei Liu wrote:
> On Tue, Aug 07, 2018 at 03:40:17PM +0100, Anthony PERARD wrote:
> > On Tue, Aug 07, 2018 at 04:18:21PM +0200, Roger Pau Monné wrote:
> > > On Mon, Aug 06, 2018 at 06:20:50PM +0100, Anthony PERARD wrote:
> > > > On Thu, Aug 02, 2018 at 05:50
>>> On 21.08.18 at 14:49, wrote:
> On 21/08/2018 12:48, Jan Beulich wrote:
> On 17.08.18 at 17:12, wrote:
>>> --- a/xen/arch/x86/Kconfig
>>> +++ b/xen/arch/x86/Kconfig
>>> @@ -60,6 +60,12 @@ config PV_LINEAR_PT
>>>
>>> config HVM
>>> def_bool y
>>> + prompt "HVM / PVH support"
>>> +
>>> On 21.08.18 at 09:49, wrote:
> Returns all the memory types applicable to a page.
>
> This function is unimplemented for ARM.
>
> Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
But this should only go in together with the consumer of the new function
seeing that you didn't fold
On Tue, Aug 21, 2018 at 09:58:57AM +0100, Wei Liu wrote:
> On Fri, Aug 03, 2018 at 06:25:00PM +0100, Anthony PERARD wrote:
> > > > diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> > > > index 4a385801ba..e104fea941 100644
> > > > --- a/tools/libxl/libxl_types.idl
> > > > +++
On 21/08/2018 12:48, Jan Beulich wrote:
On 17.08.18 at 17:12, wrote:
>> --- a/xen/arch/x86/Kconfig
>> +++ b/xen/arch/x86/Kconfig
>> @@ -60,6 +60,12 @@ config PV_LINEAR_PT
>>
>> config HVM
>> def_bool y
>> +prompt "HVM / PVH support"
>> + ---help---
>> + Interfaces to
>>> On 21.08.18 at 09:49, wrote:
> To select the iommu configuration used by Dom0. This option supersedes
> iommu=dom0-strict|dom0-passthrough.
>
> Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.x
>>> On 21.08.18 at 14:13, wrote:
> On 21/08/18 12:44, Jan Beulich wrote:
>> @@ -219,17 +216,13 @@ static int __init parse_spec_ctrl(const
>> }
>> custom_param("spec-ctrl", parse_spec_ctrl);
>>
>> -int8_t __read_mostly opt_pv_l1tf = -1;
>> +uint8_t __read_mostly opt_pv_l1tf = OPT_PV_L1TF_DOMU_D
>>> On 21.08.18 at 11:11, wrote:
> @@ -490,10 +488,6 @@ int __init tboot_parse_dmar_table(acpi_table_handler
> dmar_handler)
> rc = dmar_handler(dmar_table);
> xfree(dmar_table);
>
> -/* acpi_parse_dmar() zaps APCI DMAR signature in TXT heap table */
> -/* but dom0 will read r
On 21/08/18 14:04, Juergen Gross wrote:
> On 21/08/18 12:44, Jan Beulich wrote:
>> While commit 2a3b34ec47 ("x86/spec-ctrl: Yet more fixes for xpti=
>> parsing") indeed fixed "xpti=dom0", it broke "xpti=no-dom0", in that
>> this then became equivalent to "xpti=no". In particular, the presence
>> of
On 21/08/18 12:44, Jan Beulich wrote:
> While commit 2a3b34ec47 ("x86/spec-ctrl: Yet more fixes for xpti=
> parsing") indeed fixed "xpti=dom0", it broke "xpti=no-dom0", in that
> this then became equivalent to "xpti=no". In particular, the presence
> of "xpti=" alone on the command line means nothi
On 21/08/18 12:44, Jan Beulich wrote:
> While commit 2a3b34ec47 ("x86/spec-ctrl: Yet more fixes for xpti=
> parsing") indeed fixed "xpti=dom0", it broke "xpti=no-dom0", in that
> this then became equivalent to "xpti=no". In particular, the presence
> of "xpti=" alone on the command line means nothi
>>> On 21.08.18 at 13:44, wrote:
> On Tue, Aug 21, 2018 at 05:14:54AM -0600, Jan Beulich wrote:
>> The apparently same issue is blocking 4.7, and I think it is only
>> because of some earlier force-push and/or "fail pass in" that 4.8
>> and 4.6 aren't blocked by this. The failures look to always b
>>> On 17.08.18 at 17:12, wrote:
> --- a/xen/arch/x86/sysctl.c
> +++ b/xen/arch/x86/sysctl.c
> @@ -92,8 +92,10 @@ void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
> min(sizeof(pi->hw_cap), sizeof(boot_cpu_data.x86_capability)));
> if ( hvm_enabled )
> pi->capabilitie
>>> On 17.08.18 at 17:12, wrote:
> --- a/xen/arch/x86/Kconfig
> +++ b/xen/arch/x86/Kconfig
> @@ -60,6 +60,12 @@ config PV_LINEAR_PT
>
> config HVM
> def_bool y
> + prompt "HVM / PVH support"
> + ---help---
> + Interfaces to support HVM and PVH guests.
> +
> + If
>>> On 17.08.18 at 17:12, wrote:
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -318,8 +318,14 @@ struct domain *domain_create(domid_t domid,
> if ( !is_idle_domain(d) )
> {
> if ( config->flags & XEN_DOMCTL_CDF_hvm_guest )
> +{
> +#if CONFIG_HVM
>
On Tue, Aug 21, 2018 at 05:14:54AM -0600, Jan Beulich wrote:
> >>> On 21.08.18 at 03:11, wrote:
> > flight 126201 xen-4.9-testing real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/126201/
> >
> > Regressions :-(
> >
> > Tests which did not succeed and are blocking,
> > including
>>> On 17.08.18 at 17:12, wrote:
> Move the common parts to emul-i8254.c. This requires moving some of
> the macros to vpt.h. Some of the code in common code is put under
> is_hvm_* checks so that DCE can kick in. Factor out HVM only
> pit_load_count_channel0 to reduce amount of code in x86 common
>>> On 17.08.18 at 17:12, wrote:
> Nested HVM is not enabled when !CONFIG_HVM.
All callers of the function sit under hvm/, so once again I don't see
why the function needs to remain available with an empty body.
Jan
___
Xen-devel mailing list
Xen-de
>>> On 17.08.18 at 17:12, wrote:
> They reference hvm_inject_event which is HVM code (not compiled). They
> aren't used by code outside HVM code anyway.
Again looks to be a case of DCE doing its job (if arranged for properly)
instead of adding #ifdef-s to functions which ought to be entirely
unav
>>> On 17.08.18 at 17:12, wrote:
> --- /dev/null
> +++ b/xen/arch/x86/mm/shadow/hvm.c
> @@ -0,0 +1,590 @@
> +
> +/**
> + * arch/x86/mm/shadow/hvm.c
> + *
> + * Shadow code that does not need to be multiply compiled and is
flight 75096 distros-debian-sid real [real]
http://osstest.xensource.com/osstest/logs/75096/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-i386-sid-netboot-pygrub 10 debian-di-install fail like 75064
test-amd64-i386-i386-sid-netboot-pvgrub
>>> On 21.08.18 at 12:10, wrote:
> On Thu, Aug 16, 2018 at 10:07:00AM +0100, Andrew Cooper wrote:
>> Irrespective of what we do here, I'd really like Wei to rebase his work
>> to remove the lazy fpu logic from the nested virt paths, because its a
>> no-brainer (perf wise) and comes with a massive
>>> On 21.08.18 at 03:11, wrote:
> flight 126201 xen-4.9-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/126201/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-amd64-libvirt-pair 22 guest-migra
On 8/21/18 1:45 PM, Wei Liu wrote:
> On Sun, Aug 19, 2018 at 07:41:11PM +0300, Razvan Cojocaru wrote:
>> On 8/17/18 6:12 PM, Wei Liu wrote:
>>> Ideally the HVM specific part of VM event should be moved into hvm/ at
>>> some point, but this will do for now.
>>>
>>> Signed-off-by: Wei Liu
>>> ---
On Tue, Aug 21, 2018 at 10:00:14AM +0100, Wei Liu wrote:
> On Fri, Jul 27, 2018 at 03:06:05PM +0100, Anthony PERARD wrote:
> > Signed-off-by: Anthony PERARD
> > ---
> > tools/libxl/libxl_qmp.c | 36 ++--
> > 1 file changed, 30 insertions(+), 6 deletions(-)
> >
> >
flight 126244 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126244/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 125959
test-amd64-i386-xl-qemuu-win7-amd64
On Sun, Aug 19, 2018 at 07:41:11PM +0300, Razvan Cojocaru wrote:
> On 8/17/18 6:12 PM, Wei Liu wrote:
> > Ideally the HVM specific part of VM event should be moved into hvm/ at
> > some point, but this will do for now.
> >
> > Signed-off-by: Wei Liu
> > ---
> > xen/arch/x86/vm_event.c | 2 ++
> >
While commit 2a3b34ec47 ("x86/spec-ctrl: Yet more fixes for xpti=
parsing") indeed fixed "xpti=dom0", it broke "xpti=no-dom0", in that
this then became equivalent to "xpti=no". In particular, the presence
of "xpti=" alone on the command line means nothing as to which
default is to be overridden; "x
Let's perform all checking + offlining + removing under
device_hotplug_lock, so nobody can mess with these devices via
sysfs concurrently.
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: Rashmica Gupta
Cc: Balbir Singh
Cc: Michael Neuling
Signed-off-by: David Hildenbra
remove_memory() is exported right now but requires the
device_hotplug_lock, which is not exported. So let's provide a variant
that takes the lock and only export that one.
The lock is already held in
arch/powerpc/platforms/pseries/hotplug-memory.c
drivers/acpi/acpi_memhotplug.c
So,
There seem to be some problems as result of 30467e0b3be ("mm, hotplug:
fix concurrent memory hot-add deadlock"), which tried to fix a possible
lock inversion reported and discussed in [1] due to the two locks
a) device_lock()
b) mem_hotplug_lock
While add_memory() first takes b), f
device_online() should be called with device_hotplug_lock() held.
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: Rashmica Gupta
Cc: Balbir Singh
Cc: Michael Neuling
Signed-off-by: David Hildenbrand
---
arch/powerpc/platforms/powernv/memtrace.c | 2 ++
1 file changed
Let's document the magic a bit, especially why device_hotplug_lock is
required when adding/removing memory and how it all play together with
requests to online/offline memory from user space.
Cc: Jonathan Corbet
Cc: Michal Hocko
Cc: Andrew Morton
Signed-off-by: David Hildenbrand
---
Documenta
This is the same approach as in the first RFC, but this time without
exporting device_hotplug_lock (requested by Greg) and with some more
details and documentation regarding locking. Tested only on x86 so far.
--
Reading thro
add_memory() currently does not take the device_hotplug_lock, however
is aleady called under the lock from
arch/powerpc/platforms/pseries/hotplug-memory.c
drivers/acpi/acpi_memhotplug.c
to synchronize against CPU hot-remove and similar.
In general, we should hold the device_hotplug
On Tue, Aug 21, 2018 at 12:40:22PM +0200, Roger Pau Monné wrote:
> On Tue, Aug 21, 2018 at 11:25:58AM +0100, Wei Liu wrote:
> > On Tue, Aug 21, 2018 at 10:32:18AM +0200, Roger Pau Monné wrote:
> > > On Fri, Aug 17, 2018 at 04:12:52PM +0100, Wei Liu wrote:
> > > > hvm_directio is set when iommu is e
On Mon, Aug 20, 2018 at 01:59:57PM +0100, Andrew Cooper wrote:
> On 17/08/2018 16:12, Wei Liu wrote:
> > Signed-off-by: Wei Liu
> > ---
> > xen/common/domain.c | 8 +++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/xen/common/domain.c b/xen/common/domain.c
> > index
On Tue, Aug 21, 2018 at 11:25:58AM +0100, Wei Liu wrote:
> On Tue, Aug 21, 2018 at 10:32:18AM +0200, Roger Pau Monné wrote:
> > On Fri, Aug 17, 2018 at 04:12:52PM +0100, Wei Liu wrote:
> > > hvm_directio is set when iommu is enabled, but in fact iommu is not
> > > tied to HVM. In order to not break
1 - 100 of 152 matches
Mail list logo
