>>> On 27.04.17 at 04:38, wrote:
> On 17-04-26 04:04:15, Jan Beulich wrote:
>> >>> On 20.04.17 at 07:38, wrote:
>> > @@ -221,12 +210,17 @@ static void free_socket_resources(unsigned int
>> > socket)
>> > */
>> > for ( i = 0; i < PSR_SOCKET_MAX_FEAT; i++ )
>> > {
>> > -if
* Boris Ostrovsky wrote:
> > xen_mc_issue() does:
> >
> > if ((paravirt_get_lazy_mode() & mode) == 0)
> > xen_mc_flush();
> >
> > I assume the load_cr3() is intended to deal with the case where we're
> > in lazy mode, but we'll still be in lazy mode, right? Or does it
When running as Xen pv guest X86_BUG_SYSRET_SS_ATTRS must not be set
on AMD cpus.
This bug/feature bit is kind of special as it will be used very early
when switching threads. Setting the bit and clearing it a little bit
later leaves a critical window where things can go wrong. This time
window ha
flight 107736 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107736/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm5 xen-buildfail REGR. vs. 107636
build-arm64-xsm
flight 107750 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107750/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 5 xen-buildfail REGR. vs. 106986
build-amd64
On 27/04/17 00:04, Borislav Petkov wrote:
> On Wed, Apr 26, 2017 at 08:24:12PM +0200, Juergen Gross wrote:
>> I'm not feeling strong about it. So if you want to test for
>> X86_FEATURE_XENPV to avoid setting X86_BUG_SYSRET_SS_ATTRS I'm fine
>> with it.
>>
>> Will send V2 with that change.
>
> And
flight 107710 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107710/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-xsm 11 guest-start fail REGR. vs. 59254
test-armhf-armhf-xl
flight 107746 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107746/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 5 xen-buildfail REGR. vs. 106986
build-amd64
On 17-04-26 04:04:15, Jan Beulich wrote:
> >>> On 20.04.17 at 07:38, wrote:
> > --- a/xen/arch/x86/psr.c
> > +++ b/xen/arch/x86/psr.c
> > @@ -125,6 +125,8 @@ struct feat_node {
> > uint32_t cos_reg_val[MAX_COS_REG_CNT];
> > };
> >
> > +#define PSR_DOM_IDS_NUM ((DOMID_IDLE + 1) / sizeof(uin
BTW, I tried to clean up the vtpm code and stored it in the Git repo:
https://github.com/virt2x/vtpm2vtpmmgr
I hope that others will continue to clean up code and verify it (I don't have
tpm1.2/ tpm2.0 machine to verified it)..
Quan
On April 27, 2017 10:28 AM, Quan Xu wrote:
>From 291938c64c
flight 107743 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107743/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 5 xen-buildfail REGR. vs. 106986
build-amd64
>From 291938c64ccf3a6d580dad7d3ca3311a49a4572e Mon Sep 17 00:00:00 2001
From: Quan Xu
Date: Fri, 28 Apr 2017 02:14:29 +0800
Subject: [PATCH] vTPM: update email address and file path in MAINTAINERS file
Signed-off-by: Quan Xu
---
MAINTAINERS | 4 ++--
1 file changed, 2 insertions(+), 2 deletions
flight 107738 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107738/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 5 xen-buildfail REGR. vs. 106986
build-amd64
On Wed, Apr 26, 2017 at 5:55 PM, Boris Ostrovsky
wrote:
>
>
> On 04/26/2017 06:49 PM, Andy Lutomirski wrote:
>>
>> On Wed, Apr 26, 2017 at 3:45 PM, Boris Ostrovsky
>> wrote:
>>>
>>> On 04/26/2017 04:52 PM, Andy Lutomirski wrote:
I was trying to understand xen_drop_mm_ref() to update it
On 04/26/2017 06:49 PM, Andy Lutomirski wrote:
On Wed, Apr 26, 2017 at 3:45 PM, Boris Ostrovsky
wrote:
On 04/26/2017 04:52 PM, Andy Lutomirski wrote:
I was trying to understand xen_drop_mm_ref() to update it for some
changes I'm working on, and I'm wondering whether we need
xen_exit_mmap() a
flight 107734 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107734/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 5 xen-buildfail REGR. vs. 106986
build-amd64
flight 107686 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107686/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-multivcpu 3 host-install(3) broken REGR. vs. 107636
test-amd64-amd64-
On Wed, Apr 26, 2017 at 3:45 PM, Boris Ostrovsky
wrote:
> On 04/26/2017 04:52 PM, Andy Lutomirski wrote:
>> I was trying to understand xen_drop_mm_ref() to update it for some
>> changes I'm working on, and I'm wondering whether we need
>> xen_exit_mmap() at all.
>>
>> AFAICS the intent is to force
On 04/26/2017 04:52 PM, Andy Lutomirski wrote:
> I was trying to understand xen_drop_mm_ref() to update it for some
> changes I'm working on, and I'm wondering whether we need
> xen_exit_mmap() at all.
>
> AFAICS the intent is to force all CPUs to drop their lazy uses of the
> mm being destroyed so
flight 107730 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107730/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 5 xen-buildfail REGR. vs. 106986
build-amd64
branch xen-unstable
xenbranch xen-unstable
job build-i386-xsm
testid xen-build
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: seabios git://git.seabios.org/seabios.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced
On Wed, Apr 26, 2017 at 08:24:12PM +0200, Juergen Gross wrote:
> I'm not feeling strong about it. So if you want to test for
> X86_FEATURE_XENPV to avoid setting X86_BUG_SYSRET_SS_ATTRS I'm fine
> with it.
>
> Will send V2 with that change.
And remove the corresponding
clear_cpu_bug(c, X
Hi Julien,
On 25 April 2017 at 14:43, Julien Grall wrote:
>> We will also need another type of application: one which is
>> periodically called by XEN itself, not actually servicing any domain
>> request. This is needed for a
>> coprocessor sharing framework scheduler implementati
I was trying to understand xen_drop_mm_ref() to update it for some
changes I'm working on, and I'm wondering whether we need
xen_exit_mmap() at all.
AFAICS the intent is to force all CPUs to drop their lazy uses of the
mm being destroyed so it can be unpinned before tearing down the page
tables, t
This run is configured for baseline tests only.
flight 71235 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71235/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 227fe49d5d4fe6513fc09766f1c9f3ff330ea845
baseline v
flight 107696 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107696/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-libvirt 5 libvirt-buildfail REGR. vs. 107640
build-i386-libvirt
flight 107676 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107676/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 107642
test-amd64-i386-xl-qemuu-win7-amd64
flight 107724 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107724/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf 7e7c4526bc137999335b6e8e4b3db233ae2cf4b9
baseline version:
xtf 1846c75ecc946a877b455d
flight 107725 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107725/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 5 xen-buildfail REGR. vs. 106986
build-amd64
On 04/26/2017 02:19 PM, Andrew Cooper wrote:
On 26/04/17 19:11, Mohit Gambhir wrote:
Setting Pin Control (PC) bit (19) in MSR_P6_EVNTSEL results in a General
Protection Fault and thus results in a hypervisor crash. This patch fixes the
crash by masking PC bit and returning an error in case any
When running as Xen pv guest X86_BUG_SYSRET_SS_ATTRS must not be set
on AMD cpus.
This bug/feature bit is kind of special as it will be used very early
when switching threads. Setting the bit and clearing it a little bit
later leaves a critical window where things can go wrong. This time
window ha
On 26/04/17 08:35, Borislav Petkov wrote:
> On Wed, Apr 26, 2017 at 06:45:42AM +0200, Juergen Gross wrote:
>> The really clean solution would be to add this test to set_cpu_bug()
>
> No, the really clean solution is to set it once and not play toggle
> games.
>
>> This would work. OTOH I'd prefer
flight 107718 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107718/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 5 xen-buildfail REGR. vs. 106986
build-amd64
On 26/04/17 19:11, Mohit Gambhir wrote:
> Setting Pin Control (PC) bit (19) in MSR_P6_EVNTSEL results in a General
> Protection Fault and thus results in a hypervisor crash. This patch fixes the
> crash by masking PC bit and returning an error in case any guest tries to
> write
> to it.
>
> Signed
Setting Pin Control (PC) bit (19) in MSR_P6_EVNTSEL results in a General
Protection Fault and thus results in a hypervisor crash. This patch fixes the
crash by masking PC bit and returning an error in case any guest tries to write
to it.
Signed-off-by: Mohit Gambhir
---
v2 of this patch takes a d
flight 107716 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107716/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 227fe49d5d4fe6513fc09766f1c9f3ff330ea845
baseline version:
ovmf 6bbd4a8f5f2a538e50170
flight 107720 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107720/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
test-amd64-amd64-libvirt 12 mig
On Wed, 26 Apr 2017, Catalin Marinas wrote:
> On Wed, Apr 26, 2017 at 10:00:30AM -0700, Stefano Stabellini wrote:
> > On Wed, 26 Apr 2017, Catalin Marinas wrote:
> > > On Tue, Apr 25, 2017 at 10:22:00AM -0700, Stefano Stabellini wrote:
> > > > On Tue, 25 Apr 2017, Julien Grall wrote:
> > > > > On 2
On Wed, Apr 26, 2017 at 10:00:30AM -0700, Stefano Stabellini wrote:
> On Wed, 26 Apr 2017, Catalin Marinas wrote:
> > On Tue, Apr 25, 2017 at 10:22:00AM -0700, Stefano Stabellini wrote:
> > > On Tue, 25 Apr 2017, Julien Grall wrote:
> > > > On 24/04/17 20:16, Stefano Stabellini wrote:
> > > > > Giv
On 18/04/17 07:24, Tian, Kevin wrote:
>> From: Gao, Chao
>> Sent: Monday, April 17, 2017 4:14 AM
>>
>> On Tue, Apr 11, 2017 at 02:21:07AM -0600, Jan Beulich wrote:
>> On 11.04.17 at 02:59, wrote:
As you know, with VT-d PI enabled, hardware can directly deliver external
interrupts to
On Wed, 26 Apr 2017, Bhupinder Thakur wrote:
> Hi Julien,
>
>
> >> tools/console/client/main.c | 6 +
> >> tools/console/daemon/io.c| 532
> >> +++
> >> tools/libxc/include/xc_dom.h | 3 +
> >> tools/libxc/xc_dom_arm.c | 7 +-
> >
On Wed, 26 Apr 2017, Julien Grall wrote:
> Hi Bhupinder,
>
> On 26/04/2017 08:49, Bhupinder Thakur wrote:
> > > > > Regarding the optimization you introduced in this patch, delaying
> > > > > write
> > > > > notifications until we receive a notification from xenconsoled, how
> > > > > many
> > > >
On Wed, 26 Apr 2017, Catalin Marinas wrote:
> On Tue, Apr 25, 2017 at 10:22:00AM -0700, Stefano Stabellini wrote:
> > On Tue, 25 Apr 2017, Julien Grall wrote:
> > > On 24/04/17 20:16, Stefano Stabellini wrote:
> > > > Given the outstanding regression we need to fix as soon as possible,
> > > > I'll
On 26/04/17 01:52, Chao Gao wrote:
> VT-d PI introduces a per-pCPU blocking list to track the blocked vCPU
> running on the pCPU. Theoretically, there are 32K domain on single
> host, 128 vCPUs per domain. If all vCPUs are blocked on the same pCPU,
> 4M vCPUs are in the same list. Travelling this i
Move updating type_info after clearing the page. Add spaces.
Signed-off-by: Wei Liu
---
xen/arch/x86/pv/domain.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c
index 8f6c6c5dec..a01e3516ca 100644
--- a/xen/arch/x86/pv
There is only one function arch_set_info_hvm_guest is moved. The
check_segment function is also moved since arch_set_info_hvm_guest is
the only user.
No functional change.
Signed-off-by: Wei Liu
Acked-by: Jan Beulich
Reviewed-by: Andrew Cooper
---
xen/arch/x86/domain.c | 291 -
Remove the redundant is_pv_domain check. Rearrange setup_compat calls.
Signed-off-by: Wei Liu
---
xen/arch/x86/pv/domain.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c
index a01e3516ca..f55d41587a 100644
--- a/
flight 107662 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107662/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 6 xen-boot fail REGR. vs. 107358
Tests which are faili
On 26/04/17 16:43, Olaf Hering wrote:
> On Thu, Apr 20, Jan Beulich wrote:
>
> On 20.04.17 at 18:04, wrote:
>>> On Thu, Apr 20, Andrew Cooper wrote:
>>>
As it currently stands, the sending side iterates from 0 to p2m_size,
and sends every frame on the first pass. This means we get P
Move PV specific vcpu initialisation code to said function, but leave
the only line needed by idle domain in vcpu_initialise.
Use pv_vcpu_destroy in error path to simplify code. It is safe to do so
because the destruction function accepts partially initialised vcpu
struct.
Signed-off-by: Wei Liu
Lump everything PV related in arch_domain_create into
pv_domain_initialise.
Though domcr_flags and config are not necessary, the new function is
given those to match hvm counterpart.
Since it cleans up after itself there is no need to clean up in
arch_domain_create in case of failure. Remove the
Push the check in caller down to that function so that it becomes
idempotent.
No functional change.
Signed-off-by: Wei Liu
Reviewed-by: Andrew Cooper
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/domain.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/xen
Signed-off-by: Wei Liu
Reviewed-by: Andrew Cooper
---
Cc: Tim Deegan
Cc: George Dunlap
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/mm.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index bd68e56dc7..cdef5c49c4 100644
The function is made idempotent on purpose. Note that free_compact_l4,
release_compact_l4 and pv_destroy_gdt_ldt_l1tab are idempotent already.
No functional change.
Signed-off-by: Wei Liu
Reviewed-by: Andrew Cooper
---
v3: update commit message
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch
This patch encapsulates the perdomain creation and destruction into
helper functions and use them where appropriate.
Since destroy_perdomain_mapping is idempotent, it is safe to call the
destruction function multiple times.
Signed-off-by: Wei Liu
---
v2: new
v3: use 1U and eliminate d as parame
Move all the PV specific code along with the supporting code to
pv/domain.c.
This in turn requires exporting a few functions in header files. Create
pv/domain.h for that. Move paravirt_ctxt_switch_{from,to} declarations
to domain.h.
No functional change.
Signed-off-by: Wei Liu
---
v3:
1. move p
We want to have a single entry point to initialise hvm guest. To do
this, the setting of hap_enabled and creation of the per domain mappings
is deferred, but that's not a problem.
No functional change.
Signed-off-by: Wei Liu
Reviewed-by: Andrew Cooper
---
v3: update commit message
v2:
1. reor
Now this function also frees the perdomain mapping. It is safe to do so
because destroy_perdomain_mapping is idempotent.
Move free_perdomain_mappings after pv_domain_destroy. It is safe to do
so because both destroy_perdomain_mapping and free_perdomain_mappings
are idempotent.
Signed-off-by: Wei
Can be found at
https://xenbits.xen.org/git-http/people/liuw/xen.git wip.x86-domain-v3
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Tim Deegan
Cc: George Dunlap
Wei Liu (12):
x86/mm: make free_perdomain_mappings idempotent
x86/domain: provide pv_{create,destroy}_gdt_ldt_l1tab and use them
x
On Tue, Apr 25, 2017 at 03:52:06PM +0100, Andrew Cooper wrote:
> > +if ( is_pv_32bit_domain(d) )
> > +{
> > +if ( (rc = setup_compat_arg_xlat(v)) )
> > +goto done;
> > +
> > +if ( (rc = setup_compat_l4(v)) )
> > +goto done;
> > +}
>
> Now the cod
On Thu, Apr 20, Jan Beulich wrote:
> >>> On 20.04.17 at 18:04, wrote:
> > On Thu, Apr 20, Andrew Cooper wrote:
> >
> >> As it currently stands, the sending side iterates from 0 to p2m_size,
> >> and sends every frame on the first pass. This means we get PAGE_DATA
> >> records linearly, in batch
Hi Julien,
>> tools/console/client/main.c | 6 +
>> tools/console/daemon/io.c| 532
>> +++
>> tools/libxc/include/xc_dom.h | 3 +
>> tools/libxc/xc_dom_arm.c | 7 +-
>> tools/libxc/xc_dom_boot.c| 3 +
>> tools/libxc/xc_
flight 107715 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107715/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 8829d12ac0f9e3f7b01f276cd966c5a39497da92
baseline version:
xen 07ab
>> This breaks on old compilers:
>>
>> FC-64
>> > ulator>
>> gcc --version
>> gcc (GCC) 4.4.4 20100503 (Red Hat 4.4.4-2)
> I did try with 4.3.x, fwiw (but I'm afraid I've lost that machine just
> now, and will hardly set it up again using an old distro). Also I can't
> immediately see what the com
At 08:07 -0600 on 26 Apr (1493194043), Jan Beulich wrote:
> >>> On 25.04.17 at 12:59, wrote:
> > Hi,
> >
> > At 02:59 -0600 on 25 Apr (1493089158), Jan Beulich wrote:
> >> Jann's explanation of the problem:
> >>
> >> "start situation:
> >> - domain A and domain B are PV domains
> >> - domain A
>>> On 26.04.17 at 16:08, wrote:
> Wei Liu writes ("[PATCH for-4.9] seabios: run olddefconfig"):
>> We provided a base config file in 970f8de3e. To generate a full config
>> file, running olddefconfig is required.
>>
>> Signed-off-by: Wei Liu
>> ---
>> Cc: Ian Jackson
>> Cc: Jan Beulich
>
> R
>>> On 26.04.17 at 16:01, wrote:
> On 04/25/2017 05:04 AM, Jan Beulich wrote:
>> Stub invocations need to have the space the stub occupies as an input,
>> to prevent the compiler from re-ordering (or omitting) writes to it.
>>
>> Signed-off-by: Jan Beulich
>>
>> --- a/xen/arch/x86/x86_emulate/x86
flight 107709 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107709/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
test-amd64-amd64-libvirt 12 mig
>>> On 26.04.17 at 15:32, wrote:
> On Wed, Apr 26, 2017 at 07:26:29AM -0600, Jan Beulich wrote:
>> >>> On 26.04.17 at 14:46, wrote:
>> > On 26/04/17 13:39, Jan Beulich wrote:
>> > On 25.04.17 at 16:52, wrote:
>> >>> On 25/04/17 14:52, Wei Liu wrote:
>> - fail:
>> -pv_domain_des
Wei Liu writes ("[PATCH for-4.9] seabios: run olddefconfig"):
> We provided a base config file in 970f8de3e. To generate a full config
> file, running olddefconfig is required.
>
> Signed-off-by: Wei Liu
> ---
> Cc: Ian Jackson
> Cc: Jan Beulich
Release-acked-by: Ian Jackson
Not sure if this
>>> On 25.04.17 at 12:59, wrote:
> Hi,
>
> At 02:59 -0600 on 25 Apr (1493089158), Jan Beulich wrote:
>> Jann's explanation of the problem:
>>
>> "start situation:
>> - domain A and domain B are PV domains
>> - domain A and B both have currently scheduled vCPUs, and the vCPUs
>>are not sche
flight 107713 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107713/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 5 xen-buildfail REGR. vs. 106986
build-amd64
On 04/25/2017 05:04 AM, Jan Beulich wrote:
> Stub invocations need to have the space the stub occupies as an input,
> to prevent the compiler from re-ordering (or omitting) writes to it.
>
> Signed-off-by: Jan Beulich
>
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulat
On 04/25/2017 02:47 AM, Juergen Gross wrote:
> Commit 690b7f10b4f9f ("x86/xen: use capabilities instead of fake cpuid
> values for xsave") introduced a regression as it tried to make use of
> the fixup feature before it being available.
>
> Fall back to the old variant testing via cpuid().
>
> Sign
Recent code rework that split handling ov PV, HVM and PVH guests into
separate files missed calling xen_smp_intr_init_pv() on CPU0.
Add this call.
Signed-off-by: Boris Ostrovsky
Reported-by: Sander Eikelenboom
---
arch/x86/xen/smp_pv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
dif
On Wed, Apr 26, 2017 at 07:29:34AM -0600, Jan Beulich wrote:
> >>> On 26.04.17 at 14:56, wrote:
> > On Wed, Apr 26, 2017 at 06:32:46AM -0600, Jan Beulich wrote:
> >> >>> On 25.04.17 at 15:52, wrote:
> >> > --- a/xen/arch/x86/domain.c
> >> > +++ b/xen/arch/x86/domain.c
> >> > @@ -536,6 +536,16 @@
On Wed, Apr 26, 2017 at 07:27:23AM -0600, Jan Beulich wrote:
> >>> On 26.04.17 at 14:53, wrote:
> > On Wed, Apr 26, 2017 at 06:25:32AM -0600, Jan Beulich wrote:
> >> > if ( is_hvm_domain(d) )
> >> > -{
> >> > rc = hvm_vcpu_initialise(v);
> >> > -goto done;
> >> > -}
>
On Wed, Apr 26, 2017 at 07:26:29AM -0600, Jan Beulich wrote:
> >>> On 26.04.17 at 14:46, wrote:
> > On 26/04/17 13:39, Jan Beulich wrote:
> > On 25.04.17 at 16:52, wrote:
> >>> On 25/04/17 14:52, Wei Liu wrote:
> - fail:
> -pv_domain_destroy(d);
> -
> -return rc;
>
>>> On 26.04.17 at 14:56, wrote:
> On Wed, Apr 26, 2017 at 06:32:46AM -0600, Jan Beulich wrote:
>> >>> On 25.04.17 at 15:52, wrote:
>> > --- a/xen/arch/x86/domain.c
>> > +++ b/xen/arch/x86/domain.c
>> > @@ -536,6 +536,16 @@ static bool emulation_flags_ok(const struct domain
>> > *d,
> uint32_t
>>> On 26.04.17 at 14:53, wrote:
> On Wed, Apr 26, 2017 at 06:25:32AM -0600, Jan Beulich wrote:
>> > if ( is_hvm_domain(d) )
>> > -{
>> > rc = hvm_vcpu_initialise(v);
>> > -goto done;
>> > -}
>> > -
>> > -
>> > -spin_lock_init(&v->arch.pv_vcpu.shadow_ldt_lock);
>>
>>> On 26.04.17 at 14:46, wrote:
> On 26/04/17 13:39, Jan Beulich wrote:
> On 25.04.17 at 16:52, wrote:
>>> On 25/04/17 14:52, Wei Liu wrote:
- fail:
-pv_domain_destroy(d);
-
-return rc;
-}
-
+void paravirt_ctxt_switch_from(struct vcpu *v);
+voi
On Wed, Apr 26, 2017 at 01:46:53PM +0100, Andrew Cooper wrote:
> On 26/04/17 13:39, Jan Beulich wrote:
> On 25.04.17 at 16:52, wrote:
> >> On 25/04/17 14:52, Wei Liu wrote:
> >>> - fail:
> >>> -pv_domain_destroy(d);
> >>> -
> >>> -return rc;
> >>> -}
> >>> -
> >>> +void paravirt_ctxt_
On Wed, Apr 26, 2017 at 06:32:46AM -0600, Jan Beulich wrote:
> >>> On 25.04.17 at 15:52, wrote:
> > --- a/xen/arch/x86/domain.c
> > +++ b/xen/arch/x86/domain.c
> > @@ -536,6 +536,16 @@ static bool emulation_flags_ok(const struct domain *d,
> > uint32_t emflags)
> > return true;
> > }
> >
On Wed, Apr 26, 2017 at 06:25:32AM -0600, Jan Beulich wrote:
> > if ( is_hvm_domain(d) )
> > -{
> > rc = hvm_vcpu_initialise(v);
> > -goto done;
> > -}
> > -
> > -
> > -spin_lock_init(&v->arch.pv_vcpu.shadow_ldt_lock);
> > -
> > -if ( !is_idle_domain(d) )
> > -
On 26/04/17 13:39, Jan Beulich wrote:
On 25.04.17 at 16:52, wrote:
>> On 25/04/17 14:52, Wei Liu wrote:
>>> - fail:
>>> -pv_domain_destroy(d);
>>> -
>>> -return rc;
>>> -}
>>> -
>>> +void paravirt_ctxt_switch_from(struct vcpu *v);
>>> +void paravirt_ctxt_switch_to(struct vcpu *v);
>>>
>>> On 25.04.17 at 16:52, wrote:
> On 25/04/17 14:52, Wei Liu wrote:
>> - fail:
>> -pv_domain_destroy(d);
>> -
>> -return rc;
>> -}
>> -
>> +void paravirt_ctxt_switch_from(struct vcpu *v);
>> +void paravirt_ctxt_switch_to(struct vcpu *v);
>> int arch_domain_create(struct domain *d, unsign
On 26/04/17 07:04, Jan Beulich wrote:
On 25.04.17 at 16:52, wrote:
>> On 25/04/17 14:52, Wei Liu wrote:
>>> +
>>> +for_each_vcpu( d, v )
>>> +{
>>> +rc = setup_compat_arg_xlat(v);
>>> +if ( !rc )
>>> +rc = setup_compat_l4(v);
>>> +
>>> +if ( rc )
>>
>>> On 25.04.17 at 15:52, wrote:
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -536,6 +536,16 @@ static bool emulation_flags_ok(const struct domain *d,
> uint32_t emflags)
> return true;
> }
>
> +static void pv_domain_destroy(struct domain *d)
> +{
> +destroy_perdom
>>> On 25.04.17 at 15:52, wrote:
> +static int pv_vcpu_initialise(struct vcpu *v)
> +{
> +struct domain *d = v->domain;
> +int rc;
> +
> +ASSERT(!is_idle_domain(d));
> +
> +spin_lock_init(&v->arch.pv_vcpu.shadow_ldt_lock);
> +
> +rc = pv_create_gdt_ldt_l1tab(d, v);
> +if (
>>> On 25.04.17 at 15:52, wrote:
> The function is made idempotent on purpose.
It may be worth mentioning that free_compat_arg_xlat() already is,
as that's neither obvious nor the result of any earlier patch in this
series.
Jan
___
Xen-devel mailing
On Tue, Apr 25, 2017 at 10:22:00AM -0700, Stefano Stabellini wrote:
> On Tue, 25 Apr 2017, Julien Grall wrote:
> > On 24/04/17 20:16, Stefano Stabellini wrote:
> > > Given the outstanding regression we need to fix as soon as possible,
> > > I'll queue these patches on the xentip tree for 4.12.
> >
We provided a base config file in 970f8de3e. To generate a full config
file, running olddefconfig is required.
Signed-off-by: Wei Liu
---
Cc: Ian Jackson
Cc: Jan Beulich
Should fix
http://logs.test-lab.xenproject.org/osstest/logs/107685/build-amd64-xsm/5.ts-xen-build.log
---
tools/firmware/Ma
This run is configured for baseline tests only.
flight 71234 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71234/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm5 xen-build
>>> On 26.04.17 at 05:30, wrote:
> On Wed, Apr 26, 2017 at 02:19:22AM -0600, Jan Beulich wrote:
> On 26.04.17 at 02:52, wrote:
>>> Patch 2/4 randomly distritbutes entries (vCPUs) among all oneline
>>> pCPUs, which can theoretically decrease the maximum of #entry
>>> in the list by N times. N
Hello,
On 26/04/2017 07:00, 유정우 wrote:
Is Xen supports banana PI?
Cause It’s A-20 but there’s no document for support banana-pi
Xen should support most of processor with virtualization extension.
The A20 SoC is also in use in the cubietruck that we already support.
I would try to follow and a
On 25 April 2017 at 19:34, Stefano Stabellini wrote:
> Added a fix for the clang build, see
> alpine.DEB.2.10.1704251014320.2875@sstabellini-ThinkPad-X260
>
>
> The following changes since commit 55a19ad8b2d0797e3a8fe90ab99a9bb713824059:
>
> Update version for v2.9.0-rc1 release (2017-03-21 17:1
On Wed, Apr 26, 2017 at 02:19:22AM -0600, Jan Beulich wrote:
On 26.04.17 at 02:52, wrote:
>> Patch 2/4 randomly distritbutes entries (vCPUs) among all oneline
>> pCPUs, which can theoretically decrease the maximum of #entry
>> in the list by N times. N is #pCPU.
>
>Why randomly? Shouldn't cur
>>> On 19.04.17 at 20:57, wrote:
> Changed since v4:
> * Changes from [PATCH v4] code review
I'm sorry, but this is not enough.
> @@ -77,6 +94,30 @@ static struct ns16550 {
> #endif
> } ns16550_com[2] = { { 0 } };
>
> +struct serial_param_var {
> +const char name[12];
Pointless const.
Jan Beulich writes ("Re: [Xen-devel] [seabios bisection] complete
build-amd64-xsm"):
> On 26.04.17 at 04:27, wrote:
> > Bug is in tree: xen git://xenbits.xen.org/xen.git
> > Bug introduced: 99704f26360ee8d4f85081c6c50ce64f47961f6d
> > Bug not present: 6f9b62ca57322197e26d3b22ff11b62969714
On Fri, Apr 14, 2017 at 1:12 PM, Oleksandr Grytsov wrote:
> On Thu, Apr 13, 2017 at 3:54 PM, Ian Jackson
> wrote:
>> Oleksandr Grytsov writes ("Re: [Xen-devel] [PATCH v1 0/2] libxl: add PV
>> display device driver interface"):
>>> After internal discussion we think that putting positions and
>>
1 - 100 of 122 matches
Mail list logo
