>>> On 16.08.18 at 08:32, wrote:
> On Wed, Aug 15, 2018 at 11:17 PM, Juergen Gross wrote:
>
>> In the Xen x86 community call we have been discussing whether anyone
>> really is depending on 32-bit PV guests. We'd like to evaluate whether
>> anyone would see problems with:
>>
>> - deprecating
In the Xen x86 community call we have been discussing whether anyone
really is depending on 32-bit PV guests. We'd like to evaluate whether
anyone would see problems with:
- deprecating 32-bit PV guest support in Xen, meaning that we'd
eventually switch to support 32-bit PV guests only via
On Wed, Aug 15, 2018 at 11:17 PM, Juergen Gross wrote:
> In the Xen x86 community call we have been discussing whether anyone
> really is depending on 32-bit PV guests. We'd like to evaluate whether
> anyone would see problems with:
>
> - deprecating 32-bit PV guest support in Xen, meaning that
>>> On 16.08.18 at 07:10, wrote:
> On a multiple pci segment system such as HPE Superdome-Flex, pci config space
> from nonzero segment is accessed with mmcfg during acpi parsing DMAR region.
First of all - can you please write a little more helpful (to reviewers)
patch description. I had to
>>> On 16.08.18 at 08:17, wrote:
> In the Xen x86 community call we have been discussing whether anyone
> really is depending on 32-bit PV guests. We'd like to evaluate whether
> anyone would see problems with:
>
> - deprecating 32-bit PV guest support in Xen, meaning that we'd
> eventually
Commit "tools: Rework xc_domain_create() to take a full
xen_domctl_createdomain" failed to replace one further instance of
xc_config in libxl__arch_domain_save_config().
Signed-off-by: Jan Beulich
---
I have no environment set up to do cross tool stack builds, so the patch
is solely based on
>>> On 16.08.18 at 07:10, wrote:
> No functional change.
>
> Signed-off-by: Zhenzhong Duan
Acked-by: Jan Beulich
Albeit I would have wished you would have taken the opportunity
to, at the very least, also move cfg's declaration into the for()
scope. There's obvious further trivial cleanup
flight 125941 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125941/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 6 xen-buildfail REGR. vs. 125923
Tests which
>>> On 10.08.18 at 16:48, wrote:
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -184,6 +184,25 @@ static int hvmemul_do_io(
> hvmtrace_io_assist();
> }
>
> +/*
> + * Make sure that we truncate rep MMIO at any GFN boundary. This is
> + *
On 16/08/18 08:51, Jan Beulich wrote:
On 16.08.18 at 08:32, wrote:
>> On Wed, Aug 15, 2018 at 11:17 PM, Juergen Gross wrote:
>>
>>> In the Xen x86 community call we have been discussing whether anyone
>>> really is depending on 32-bit PV guests. We'd like to evaluate whether
>>> anyone
>>> On 26.07.18 at 15:07, wrote:
> Don't chance having Spectre v1 (including BCBS) gadgets. In some of the
> cases the insertions are more of precautionary nature rather than there
> provably being a gadget, but I think we should err on the safe (secure)
> side here.
>
> Signed-off-by: Jan
>>> On 26.06.18 at 09:18, wrote:
> The STI instances were moved (or added in the INT80 case) to meet TLB
> flush requirements. When XPTI is disabled, they can be put back where
> they were (or omitted in the INT80 case).
>
> Signed-off-by: Jan Beulich
> Tested-by: Juergen Gross
> Reviewed-by:
>>> On 10.07.18 at 12:13, wrote:
> For both fs_base and gs_base_user, there are comments saying "This can
> only be non-zero if selector is NULL." While save_segments() ensures
> this, so far arch_set_info_guest() didn't. Make behavior consistent
> (attaching comments identical to those in
flight 125908 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125908/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-cubietruck 6 xen-installfail REGR. vs. 125698
Tests which
Hi Stefano,
On 08/15/2018 09:04 PM, Stefano Stabellini wrote:
On Mon, 13 Aug 2018, Julien Grall wrote:
+void __init create_domUs(void)
+{
+struct dt_device_node *node;
+struct dt_device_node *chosen = dt_find_node_by_name(dt_host,
"chosen");
+
+if ( chosen != NULL )
+{
+
flight 75073 distros-debian-wheezy real [real]
http://osstest.xensource.com/osstest/logs/75073/
Perfect :-)
All tests in this flight passed as required
baseline version:
flight 75056
jobs:
build-amd64 pass
build-armhf
flight 125907 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125907/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-debianhvm-amd64 16 guest-localmigrate/x10 fail REGR.
vs. 125700
>>> On 22.06.18 at 12:57, wrote:
> Other than FXRSTOR, XRSTOR allows for setting components to their
> initial state. Utilize this to clear register state immediately after
> having saved a vCPU's state (which we don't defer past
> __context_switch()), considering that
> - this supposedly reduces
On 16/08/2018 09:01, Jan Beulich wrote:
On 26.06.18 at 09:18, wrote:
>> The STI instances were moved (or added in the INT80 case) to meet TLB
>> flush requirements. When XPTI is disabled, they can be put back where
>> they were (or omitted in the INT80 case).
>>
>> Signed-off-by: Jan Beulich
flight 125943 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125943/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 6 xen-buildfail REGR. vs. 125923
Tests which
Hi Stefano,
On 08/14/2018 10:43 PM, Stefano Stabellini wrote:
On Mon, 16 Jul 2018, Julien Grall wrote:
GUEST_BUG_ON may be used in other files doing guest emulation.
Signed-off-by: Julien Grall
Given that GUEST_BUG_ON is not actually used in any other files in this
patch series, I assume
On 16/08/2018 07:49, Jan Beulich wrote:
> Commit "tools: Rework xc_domain_create() to take a full
> xen_domctl_createdomain" failed to replace one further instance of
> xc_config in libxl__arch_domain_save_config().
>
> Signed-off-by: Jan Beulich
> ---
> I have no environment set up to do cross
>>> On 01.08.18 at 17:36, wrote:
> Clearly we want to put a vCPU to sleep if it is _not_ already down.
>
> Signed-off-by: Jan Beulich
> ---
> TBD: Since the flaw apparently never mattered, I imply that the function
> is never called with any vCPU up. Hence an alternative might be to
>
Hi,
On 08/15/2018 08:13 PM, Stefano Stabellini wrote:
On Tue, 14 Aug 2018, Julien Grall wrote:
Hi Stefano,
On 08/14/2018 10:33 PM, Stefano Stabellini wrote:
On Mon, 16 Jul 2018, Julien Grall wrote:
Currently, lpae_is_{table, mapping} helpers will always return false on
entry with the valid
Hi Andrew,
On 08/15/2018 08:03 PM, Andrew Cooper wrote:
Actually, I remember now what the problem was. d->grant_table is an
opaque type, so .max_grant_frames can't be accessed.
One of my indented bits of cleanup here is to remove the
gnttab_dom0_frames() function, because it has no business
On Wed, Aug 15, 2018 at 10:54:11AM +0100, Andrew Cooper wrote:
> Signed-off-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 22/06/2018 11:57, Jan Beulich wrote:
> --- a/xen/arch/x86/spec_ctrl.c
> +++ b/xen/arch/x86/spec_ctrl.c
> @@ -616,7 +616,7 @@ void __init init_speculation_mitigations
>
> /* Check whether Eager FPU should be enabled by default. */
> if ( opt_eager_fpu == -1 )
> -opt_eager_fpu
Hi Stefano,
On 08/15/2018 09:26 PM, Stefano Stabellini wrote:
On Mon, 13 Aug 2018, Julien Grall wrote:
Hi,
On 01/08/18 00:27, Stefano Stabellini wrote:
allocate_memory only deals with directly mapped memory. Rename it to
allocate_memory_11.
Signed-off-by: Stefano Stabellini
---
Changes in
Hi Stefano,
On 08/16/2018 01:25 AM, Stefano Stabellini wrote:
On Mon, 13 Aug 2018, Julien Grall wrote:
+
+#ifndef CONFIG_ACPI
+static inline int prepare_acpi(struct domain *d, struct kernel_info *kinfo)
+{
+/* Only booting with ACPI will hit here */
+BUG();
+return -EINVAL;
+}
On 2018/8/16 17:13, Zhenzhong Duan wrote:
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1493,6 +1493,10 @@ void __init noreturn __start_xen(unsigned long
mbi_p)
generic_apic_probe();
+ pt_pci_init();
+
+ acpi_mmcfg_init();
+
acpi_boot_init();
With the
On Wed, Aug 15, 2018 at 06:57:38PM +0100, Andrew Cooper wrote:
> Newer versions of binutils are capable of emitting an exact number bytes worth
> of optimised nops, which are P6 nops. Use this in preference to .skip when
> available.
>
> Check at boot time whether the toolchain nops are the
On 16/08/2018 10:07, Andrew Cooper wrote:
> On 22/06/2018 11:57, Jan Beulich wrote:
>> --- a/xen/arch/x86/spec_ctrl.c
>> +++ b/xen/arch/x86/spec_ctrl.c
>> @@ -616,7 +616,7 @@ void __init init_speculation_mitigations
>>
>> /* Check whether Eager FPU should be enabled by default. */
>>
On 2018/8/16 15:10, Jan Beulich wrote:
On 16.08.18 at 07:10, wrote:
On a multiple pci segment system such as HPE Superdome-Flex, pci config space
from nonzero segment is accessed with mmcfg during acpi parsing DMAR region.
First of all - can you please write a little more helpful (to
On 10/08/18 16:59, Paul Durrant wrote:
>> -Original Message-
>> From: Andrew Cooper
>> Sent: 10 August 2018 16:57
>> To: Paul Durrant ; xen-devel@lists.xenproject.org
>> Cc: Jan Beulich
>> Subject: Re: [PATCH] x86/hvm/viridian: set shutdown_code in response to
>> CrashNotify
>>
>> On
On 10/07/18 11:13, Jan Beulich wrote:
> For both fs_base and gs_base_user, there are comments saying "This can
> only be non-zero if selector is NULL." While save_segments() ensures
> this, so far arch_set_info_guest() didn't. Make behavior consistent
> (attaching comments identical to those in
flight 125905 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125905/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 broken
build-arm64
>>> On 16.08.18 at 11:07, wrote:
> On 22/06/2018 11:57, Jan Beulich wrote:
>> --- a/xen/arch/x86/spec_ctrl.c
>> +++ b/xen/arch/x86/spec_ctrl.c
>> @@ -616,7 +616,7 @@ void __init init_speculation_mitigations
>>
>> /* Check whether Eager FPU should be enabled by default. */
>> if (
>>> On 16.08.18 at 11:55, wrote:
> On Wed, Aug 15, 2018 at 06:57:38PM +0100, Andrew Cooper wrote:
>> --- a/xen/arch/x86/Rules.mk
>> +++ b/xen/arch/x86/Rules.mk
>> @@ -29,6 +29,10 @@ $(call as-option-add,CFLAGS,CC,"invpcid
>> (%rax)$$(comma)%rax",-DHAVE_AS_INVPCID)
>> $(call
>>> On 13.08.18 at 08:50, wrote:
On 10.08.18 at 18:37, wrote:
> > On 10/08/18 17:30, George Dunlap wrote:
> >> Sorry, what exactly is the issue here? Linux has a function called
> >> load_unaligned_zeropad() which is reading into a ballooned region?
>
> Yes.
>
> >> Fundamentally, a
>>> On 16.08.18 at 11:13, wrote:
> On 2018/8/16 15:10, Jan Beulich wrote:
>> Have you investigated the alternative of deferring acpi_dmar_init()
>> to a later point, or at least the part of it that needs to do PCI
>> config space accesses? I'm not currently convinced the device scope
>> parsing
flight 125909 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125909/
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
>>> On 16.08.18 at 11:30, wrote:
> On 2018/8/16 17:13, Zhenzhong Duan wrote:
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1493,6 +1493,10 @@ void __init noreturn __start_xen(unsigned long
mbi_p)
generic_apic_probe();
+pt_pci_init();
+
On 16/08/18 10:55, Roger Pau Monné wrote:
> On Wed, Aug 15, 2018 at 06:57:38PM +0100, Andrew Cooper wrote:
>> Newer versions of binutils are capable of emitting an exact number bytes
>> worth
>> of optimised nops, which are P6 nops. Use this in preference to .skip when
>> available.
>>
>> Check
On 16/08/18 11:29, Jan Beulich wrote:
On 13.08.18 at 08:50, wrote:
> On 10.08.18 at 18:37, wrote:
>>> On 10/08/18 17:30, George Dunlap wrote:
Sorry, what exactly is the issue here? Linux has a function called
load_unaligned_zeropad() which is reading into a ballooned region?
On 13/08/18 07:50, Jan Beulich wrote:
On 10.08.18 at 18:37, wrote:
>> On 10/08/18 17:30, George Dunlap wrote:
>>> Sorry, what exactly is the issue here? Linux has a function called
>>> load_unaligned_zeropad() which is reading into a ballooned region?
> Yes.
>
>>> Fundamentally, a ballooned
flight 125950 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125950/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 6 xen-buildfail REGR. vs. 125923
Tests which
On 16/08/18 13:27, Jan Beulich wrote:
On 16.08.18 at 12:56, wrote:
>> On 16/08/18 11:29, Jan Beulich wrote:
>>> Following some further discussion with Andrew, he looks to be
>>> convinced that the issue is to be fixed in the balloon driver,
>>> which so far (intentionally afaict) does not
On 2018/8/12 21:26, Boris Ostrovsky wrote:
On 08/12/2018 04:55 AM, Juergen Gross wrote:
On 11/08/18 16:34, Boris Ostrovsky wrote:
On 08/11/2018 09:29 AM, Pu Wen wrote:
bool pmu_msr_read(unsigned int msr, uint64_t *val, int *err)
{
- if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) {
>>> On 16.08.18 at 14:59, wrote:
> On Thu, Aug 16, 2018 at 05:24:15AM -0600, Jan Beulich wrote:
>> >>> On 16.08.18 at 12:42, wrote:
>> > On Tue, Aug 07, 2018 at 05:24:15PM +0100, Wei Liu wrote:
>> > >
>> >> > All uses sit either in HVM-specific code or inside is_hvm_...()
>> >> > conditionals:
On 16/08/18 11:03, Jan Beulich wrote:
On 16.08.18 at 11:07, wrote:
>> On 22/06/2018 11:57, Jan Beulich wrote:
>>> --- a/xen/arch/x86/spec_ctrl.c
>>> +++ b/xen/arch/x86/spec_ctrl.c
>>> @@ -616,7 +616,7 @@ void __init init_speculation_mitigations
>>>
>>> /* Check whether Eager FPU
>>> On 16.08.18 at 12:56, wrote:
> On 16/08/18 11:29, Jan Beulich wrote:
>> Following some further discussion with Andrew, he looks to be
>> convinced that the issue is to be fixed in the balloon driver,
>> which so far (intentionally afaict) does not remove the direct
>> map entries for
>>> On 16.08.18 at 12:42, wrote:
> On 16/08/18 10:55, Roger Pau Monné wrote:
>> On Wed, Aug 15, 2018 at 06:57:38PM +0100, Andrew Cooper wrote:
>>> @@ -112,6 +125,11 @@ static void __init arch_init_ideal_nops(void)
>>> ideal_nops = k8_nops;
>>> break;
>>> }
>>> +
>>>
>>> On 16.08.18 at 13:27, wrote:
> On 16/08/18 11:03, Jan Beulich wrote:
> On 16.08.18 at 11:07, wrote:
>>> On 22/06/2018 11:57, Jan Beulich wrote:
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -616,7 +616,7 @@ void __init init_speculation_mitigations
This is a note to let you know that I've just added the patch titled
xen/pv: Call get_cpu_address_sizes to set x86_virt/phys_bits
to the 4.17-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch
On Thu, Aug 16, 2018 at 04:18:03AM -0600, Jan Beulich wrote:
> >>> On 16.08.18 at 11:55, wrote:
> > On Wed, Aug 15, 2018 at 06:57:38PM +0100, Andrew Cooper wrote:
> >> --- a/xen/arch/x86/Rules.mk
> >> +++ b/xen/arch/x86/Rules.mk
> >> @@ -29,6 +29,10 @@ $(call as-option-add,CFLAGS,CC,"invpcid
>
On Thu, Aug 16, 2018 at 11:42:56AM +0100, Andrew Cooper wrote:
> On 16/08/18 10:55, Roger Pau Monné wrote:
> > On Wed, Aug 15, 2018 at 06:57:38PM +0100, Andrew Cooper wrote:
> >> diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
> >> index ac585a3..c84ed20 100644
> >> ---
On Thu, Aug 16, 2018 at 05:24:15AM -0600, Jan Beulich wrote:
> >>> On 16.08.18 at 12:42, wrote:
> > On Tue, Aug 07, 2018 at 05:24:15PM +0100, Wei Liu wrote:
> > >
> >> > All uses sit either in HVM-specific code or inside is_hvm_...()
> >> > conditionals: Why do we need the inline stub? If the
On 16/08/18 12:34, Jan Beulich wrote:
On 16.08.18 at 12:42, wrote:
>> On 16/08/18 10:55, Roger Pau Monné wrote:
>>> On Wed, Aug 15, 2018 at 06:57:38PM +0100, Andrew Cooper wrote:
@@ -112,6 +125,11 @@ static void __init arch_init_ideal_nops(void)
ideal_nops = k8_nops;
On Thu, Aug 16, 2018 at 07:48:43AM -0600, Jan Beulich wrote:
> >>> On 16.08.18 at 14:59, wrote:
> > On Thu, Aug 16, 2018 at 05:24:15AM -0600, Jan Beulich wrote:
> >> >>> On 16.08.18 at 12:42, wrote:
> >> > On Tue, Aug 07, 2018 at 05:24:15PM +0100, Wei Liu wrote:
> >> > >
> >> >> > All uses sit
>>> On 16.08.18 at 12:42, wrote:
> On Tue, Aug 07, 2018 at 05:24:15PM +0100, Wei Liu wrote:
> >
>> > All uses sit either in HVM-specific code or inside is_hvm_...()
>> > conditionals: Why do we need the inline stub? If the declaration
>> > was visible independent of CONFIG_HVM, code would
>>> On 16.08.18 at 13:57, wrote:
> On Thu, Aug 16, 2018 at 04:18:03AM -0600, Jan Beulich wrote:
>> >>> On 16.08.18 at 11:55, wrote:
>> > On Wed, Aug 15, 2018 at 06:57:38PM +0100, Andrew Cooper wrote:
>> >> --- a/xen/arch/x86/Rules.mk
>> >> +++ b/xen/arch/x86/Rules.mk
>> >> @@ -29,6 +29,10 @@
>>> On 16.08.18 at 14:46, wrote:
> On 26/06/18 12:09, Andrew Cooper wrote:
>> Future changes will introduce a new SILO mode, which is intended to be useful
>> for cloud and enterprise setups where all domUs are unprivileged and have no
>> buisness communicating directly.
>>
>> This was discussed
flight 125967 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125967/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 12 guest-start fail REGR. vs. 125923
Tests which
On 26/06/18 12:09, Andrew Cooper wrote:
> Future changes will introduce a new SILO mode, which is intended to be useful
> for cloud and enterprise setups where all domUs are unprivileged and have no
> buisness communicating directly.
>
> This was discussed at XenSummit, but I'll leave further
On Thu, Aug 16, 2018 at 08:41:55AM +0100, Andrew Cooper wrote:
> On 16/08/2018 07:49, Jan Beulich wrote:
> > Commit "tools: Rework xc_domain_create() to take a full
> > xen_domctl_createdomain" failed to replace one further instance of
> > xc_config in libxl__arch_domain_save_config().
> >
> >
On 16/08/18 13:56, Jan Beulich wrote:
On 16.08.18 at 14:46, wrote:
>> On 26/06/18 12:09, Andrew Cooper wrote:
>>> Future changes will introduce a new SILO mode, which is intended to be
>>> useful
>>> for cloud and enterprise setups where all domUs are unprivileged and have no
>>> buisness
>>> On 16.08.18 at 15:18, wrote:
> On 16/08/18 13:56, Jan Beulich wrote:
> On 16.08.18 at 14:46, wrote:
>>> On 26/06/18 12:09, Andrew Cooper wrote:
Future changes will introduce a new SILO mode, which is intended to be
> useful
for cloud and enterprise setups where all domUs are
>>> On 16.08.18 at 13:48, wrote:
> On 16/08/18 12:34, Jan Beulich wrote:
> On 16.08.18 at 12:42, wrote:
>>> On 16/08/18 10:55, Roger Pau Monné wrote:
On Wed, Aug 15, 2018 at 06:57:38PM +0100, Andrew Cooper wrote:
> @@ -112,6 +125,11 @@ static void __init arch_init_ideal_nops(void)
On 16/08/18 15:31, Roger Pau Monné wrote:
> On Thu, Aug 16, 2018 at 11:42:56AM +0100, Andrew Cooper wrote:
>> On 16/08/18 10:55, Roger Pau Monné wrote:
>>> On Wed, Aug 15, 2018 at 06:57:38PM +0100, Andrew Cooper wrote:
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index
On Thu, 16 Aug 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 08/14/2018 10:43 PM, Stefano Stabellini wrote:
> > On Mon, 16 Jul 2018, Julien Grall wrote:
> > > GUEST_BUG_ON may be used in other files doing guest emulation.
> > >
> > > Signed-off-by: Julien Grall
> >
> > Given that GUEST_BUG_ON
On 02/08/18 07:02, Jan Beulich wrote:
On 01.08.18 at 18:08, wrote:
>> On 01/08/18 16:36, Jan Beulich wrote:
>>> Clearly we want to put a vCPU to sleep if it is _not_ already down.
>>>
>>> Signed-off-by: Jan Beulich
>>> ---
>>> TBD: Since the flaw apparently never mattered, I imply that the
On Thu, Aug 16, 2018 at 04:27:57PM +0100, Andrew Cooper wrote:
> A number of corner cases (most obviously, no-real-mode and no Multiboot memory
> map) can end up with e820_raw.nr_map being 0, at which point the L1TF
> calculation will underflow.
>
> Spotted by Coverity.
>
> Signed-off-by: Andrew
On Thu, Aug 16, 2018 at 08:17:13AM +0200, Juergen Gross wrote:
> In the Xen x86 community call we have been discussing whether anyone
> really is depending on 32-bit PV guests. We'd like to evaluate whether
> anyone would see problems with:
>
> - deprecating 32-bit PV guest support in Xen,
flight 125990 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125990/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 12 guest-start fail REGR. vs. 125923
Tests which
On Wed, Aug 15, 2018 at 07:34:34PM +0100, Andrew Cooper wrote:
> Remove an unecessary if().
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
On Wed, Aug 15, 2018 at 07:34:36PM +0100, Andrew Cooper wrote:
> Use bool when appropraite, remove extranious brackets and fix up comment
> style.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
Just one nit...
> -static inline u32
On Wed, Aug 15, 2018 at 07:34:37PM +0100, Andrew Cooper wrote:
> ... as the only user of sl1mfn would prefer it that way.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
___
Xen-devel mailing list
On Wed, Aug 15, 2018 at 07:34:35PM +0100, Andrew Cooper wrote:
> Drop the now-unused SH_L1E_MMIO_GFN_SHIFT definition.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
___
Xen-devel mailing list
On Wed, Aug 15, 2018 at 07:34:32PM +0100, Andrew Cooper wrote:
> Use l1e_get_mfn() in place of l1e_get_pfn() when applicable, and fix up style
> on affected lines.
>
> For sh_remove_shadow_via_pointer(), map_domain_page() is guaranteed to succeed
> so there is no need to ASSERT() its success.
On Wed, Aug 15, 2018 at 07:34:33PM +0100, Andrew Cooper wrote:
> Replace pfn_to_paddr(mfn_x(...)) with mfn_to_maddr(), and replace an opencoded
> gfn_to_gaddr().
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
On Fri, Aug 10, 2018 at 12:23:45AM -0700, Sarah Newman wrote:
> On 08/09/2018 05:41 AM, David Woodhouse wrote:
> > On Wed, 2018-08-08 at 10:35 -0700, Sarah Newman wrote:
> >> commit b3681dd548d06deb2e1573890829dff4b15abf46 upstream.
> >>
> >> This version applies to v4.9.
> >
> > I think you can
A number of corner cases (most obviously, no-real-mode and no Multiboot memory
map) can end up with e820_raw.nr_map being 0, at which point the L1TF
calculation will underflow.
Spotted by Coverity.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
On Thu, 16 Aug 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 08/16/2018 01:25 AM, Stefano Stabellini wrote:
> > On Mon, 13 Aug 2018, Julien Grall wrote:
> > > > +
> > > > +#ifndef CONFIG_ACPI
> > > > +static inline int prepare_acpi(struct domain *d, struct kernel_info
> > > > *kinfo)
> > > > +{
On Thu, Aug 16, 2018 at 8:19 AM, Greg KH wrote:
> On Fri, Aug 10, 2018 at 12:23:45AM -0700, Sarah Newman wrote:
>> On 08/09/2018 05:41 AM, David Woodhouse wrote:
>> > On Wed, 2018-08-08 at 10:35 -0700, Sarah Newman wrote:
>> >> commit b3681dd548d06deb2e1573890829dff4b15abf46 upstream.
>> >>
>> >>
On Thu, Aug 16, 2018 at 02:05:02AM -0600, Jan Beulich wrote:
> >>> On 01.08.18 at 17:36, wrote:
> > Clearly we want to put a vCPU to sleep if it is _not_ already down.
> >
> > Signed-off-by: Jan Beulich
> > ---
> > TBD: Since the flaw apparently never mattered, I imply that the function
> >
On Thu, 16 Aug 2018, Juergen Gross wrote:
> In the Xen x86 community call we have been discussing whether anyone
> really is depending on 32-bit PV guests. We'd like to evaluate whether
> anyone would see problems with:
>
> - deprecating 32-bit PV guest support in Xen, meaning that we'd
>
>>> On 16.08.18 at 17:27, wrote:
> A number of corner cases (most obviously, no-real-mode and no Multiboot memory
> map) can end up with e820_raw.nr_map being 0, at which point the L1TF
> calculation will underflow.
>
> Spotted by Coverity.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan
On Thu, Aug 16, 2018 at 04:56:04PM +0100, Andrew Cooper wrote:
> On 16/08/18 15:31, Roger Pau Monné wrote:
> > On Thu, Aug 16, 2018 at 11:42:56AM +0100, Andrew Cooper wrote:
> >> On 16/08/18 10:55, Roger Pau Monné wrote:
> >>> On Wed, Aug 15, 2018 at 06:57:38PM +0100, Andrew Cooper wrote:
>
On Wed, Aug 15, 2018 at 12:40 AM Jan Beulich wrote:
>
> >>> On 15.08.18 at 03:00, wrote:
> > On Wed, Aug 8, 2018 at 3:54 AM Jan Beulich wrote:
> >>
> >> >>> On 08.08.18 at 10:25, wrote:
> >> > On Tue, Aug 07, 2018 at 10:45:32AM -0600, Tamas K Lengyel wrote:
> >> >> On Tue, Aug 7, 2018 at 10:04
On Thu, Aug 16, 2018 at 04:27:57PM +0100, Andrew Cooper wrote:
> A number of corner cases (most obviously, no-real-mode and no Multiboot memory
> map) can end up with e820_raw.nr_map being 0, at which point the L1TF
> calculation will underflow.
>
> Spotted by Coverity.
>
> Signed-off-by: Andrew
4.17-stable review patch. If anyone has any objections, please let me know.
--
From: M. Vefa Bicakci
commit 405c018a25fe464dc68057bbc8014a58f2bd4422 upstream.
Commit d94a155c59c9 ("x86/cpu: Prevent cpuinfo_x86::x86_phys_bits
adjustment corruption") has moved the query and
On Wed, Aug 15, 2018 at 10:00:48AM -0600, Jan Beulich wrote:
> >>> On 09.08.18 at 21:42, wrote:
> > --- a/xen/arch/x86/cpu/amd.c
> > +++ b/xen/arch/x86/cpu/amd.c
> > @@ -611,14 +611,9 @@ static void init_amd(struct cpuinfo_x86 *c)
> > ssbd_amd_ls_cfg_mask = 1ull << bit;
> >
On Thu, 16 Aug 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 08/15/2018 09:26 PM, Stefano Stabellini wrote:
> > On Mon, 13 Aug 2018, Julien Grall wrote:
> > > Hi,
> > >
> > > On 01/08/18 00:27, Stefano Stabellini wrote:
> > > > allocate_memory only deals with directly mapped memory. Rename it
flight 126000 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126000/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 12 guest-start fail REGR. vs. 125923
Tests which
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: M. Vefa Bicakci
commit 405c018a25fe464dc68057bbc8014a58f2bd4422 upstream.
Commit d94a155c59c9 ("x86/cpu: Prevent cpuinfo_x86::x86_phys_bits
adjustment corruption") has moved the query and
branch xen-unstable
xenbranch xen-unstable
job build-i386-libvirt
testid libvirt-build
Tree: libvirt git://libvirt.org/libvirt.git
Tree: libvirt_gnulib https://git.savannah.gnu.org/git/gnulib.git/
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: qemu
At 19:34 +0100 on 15 Aug (1534361671), Andrew Cooper wrote:
> Minor cleanup which has accumulated while doing other work. No functional
> change anywhere.
>
> Andrew Cooper (6):
> x86/mm: Use mfn_eq()/mfn_add() rather than opencoded variations
> x86/shadow: Use more appropriate conversion
On Mon, 13 Aug 2018, Julien Grall wrote:
> Hi,
>
> On 01/08/18 00:28, Stefano Stabellini wrote:
> > To avoid mixing the output of different domains on the console, buffer
> > the output chars and print line by line. Unless the domain has input
> > from the serial, in which case we want to print
On Thu, 16 Aug 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 08/15/2018 09:04 PM, Stefano Stabellini wrote:
> > On Mon, 13 Aug 2018, Julien Grall wrote:
> > > > +void __init create_domUs(void)
> > > > +{
> > > > +struct dt_device_node *node;
> > > > +struct dt_device_node *chosen =
On Thu, Aug 16, 2018 at 12:55 AM, Juergen Gross wrote:
> On 16/08/18 08:51, Jan Beulich wrote:
> On 16.08.18 at 08:32, wrote:
> >> On Wed, Aug 15, 2018 at 11:17 PM, Juergen Gross
> wrote:
> >>
> >>> In the Xen x86 community call we have been discussing whether anyone
> >>> really is
1 - 100 of 118 matches
Mail list logo
