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
>>> 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
>
>>> 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 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
>>> 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 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/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
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 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 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 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
>>> 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: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
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 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
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
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
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
101 - 118 of 118 matches
Mail list logo
