>>> On 25.04.17 at 22:03, wrote:
> On 24/04/17 09:19, Jan Beulich wrote:
> On 21.04.17 at 18:10, wrote:
>>> On 21/04/17 16:45, Jan Beulich wrote:
>>> On 21.04.17 at 16:05, wrote:
> +#define COPY_FROM_GUEST_BUF(dst, args, buf_idx) \
> +_raw_copy_from_guest_buf(&dst, args, buf_
>>> On 21.04.17 at 16:05, wrote:
> @@ -314,7 +323,7 @@ static int dm_op(const struct dmop_args *op_args)
> if ( rc )
> goto out;
>
> -if ( !copy_buf_from_guest(&op_args->buf[0], op_args->nr_bufs, &op, 0,
> sizeof(op)) )
> +if ( !COPY_FROM_GUEST_BUF(op, op_args, 0) );
Btw,
Hi Stefano,
>> > Regarding the optimization you introduced in this patch, delaying write
>> > notifications until we receive a notification from xenconsoled, how many
>> > notifications from xen to xenconsoled does it actually save? xenconsoled
>> > is going to send a notification for every read:
This patch intruduces a 'refcnt' field in vmx_pi_blocking to track
the reference count of 'pi_desc' of the vCPU. And change this field
every time we re-program one IRTE.
Signed-off-by: Chao Gao
---
xen/arch/x86/hvm/vmx/vmx.c | 29
xen/drivers/passthrough/io.c
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 issue consumes too
much time. We have discus
Currently, blocked vCPUs are added to PI blocking list if its
domain has assign devices. Actually, some blocked vCPUs will not
be woken up by wakeup interrupt generated by VT-d hardware. They
may be woken up by IPIs or other interrupts from emulated devices.
For these vCPUs we don't add them to PI
Currently, a blocked vCPU is put in its pCPU's pi blocking list. If
too many vCPUs are blocked on one pCPU, it will incur that the list
grows too long. After a simple analysis, we can have 32k domains and
128 vcpu per domain, thus about 4M vCPUs may be blocked in one pCPU's
PI blocking list. When a
This patch adds TRC_HVM_VT_D_PI_BLOCK to track adding one entry to
the per-pcpu blocking list. Also introduce a 'counter' to track
the number of entries in the list.
Signed-off-by: Chao Gao
---
tools/xentrace/formats | 1 +
xen/arch/x86/hvm/vmx/vmx.c | 10 +-
xen/include/a
On 26/04/2017 07:07, Jan Beulich wrote:
On 25.04.17 at 17:24, wrote:
>> On 24/04/17 18:54, Mohit Gambhir wrote:
>>> This patch adds Intel PMU MSR addresses as macros for VPMU testing
>>>
>>> Signed-off-by: Mohit Gambhir
>>> ---
>>> arch/x86/include/arch/msr-index.h | 11 +++
>>> 1 f
flight 107660 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107660/
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
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
notifications from xen to xenconsoled does it actually save? xenconsoled
is going to send a
>>> 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 current list length determine which CPU(s)
to prefer?
Jan
_
flight 107702 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107702/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 6bbd4a8f5f2a538e5017045ab75674ec106f7b54
baseline version:
ovmf 9e981317be20ab85bb68a
On Tue, Apr 25, 2017 at 03:32:50AM -0600, Jan Beulich wrote:
> >>> On 25.04.17 at 11:25, wrote:
> > On Tue, Apr 25, 2017 at 10:09:34AM +0100, Julien Grall wrote:
> >> My understanding is BARs may be allocated by the kernel because the
> >> firmware
> >> didn't do it. This is the current case on A
At 05:59 -0600 on 25 Apr (1493099950), 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 10:26, wrote:
> BTW, how does Xen deal with MSI-X tables inside of BARs? AFAICT a PV Dom0 is
> able to move the BARs around as much as it wants.
The current expectation is that this doesn't happen with (pre) set up
MSI-X interrupts (i.e. do BAR placement first, then set up inte
flight 107705 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107705/
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
This run is configured for baseline tests only.
flight 71232 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71232/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 9e981317be20ab85bb68a670e79735f9685a3348
baseline v
>>> On 26.04.17 at 10:44, wrote:
> At 05:59 -0600 on 25 Apr (1493099950), 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
flight 71233 distros-debian-squeeze real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71233/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-i386-squeeze-netboot-pygrub 9 debian-di-install fail like
71204
test-amd64-i
>>> 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(uint32_t))
Instead of this, please use ...
> @@ -134,9 +13
Oleksandr Tyshchenko writes ("Re: [RFC PATCH 9/9] xen: Add use_iommu flag to
createdomain domctl"):
> On Tue, Apr 25, 2017 at 6:23 PM, Wei Liu wrote:
> > Let me explain where I'm coming from:
> >
> > 1. if not populating the iommu page table causes Xen to malfunction
> >(crash?), it is a bug.
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
>>
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 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.
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 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
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 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
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
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
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.
> >
>>> 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 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:
> --- 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 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 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 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 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 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 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 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 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: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 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 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: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 @@
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 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
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
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 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
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 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
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 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
>>> 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
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
>> 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
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
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_
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
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
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
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
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
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
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
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
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
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
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
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
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/
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 -
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
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
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 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, 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 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, 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 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
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
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
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
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
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 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
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 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
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
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 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 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
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
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
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
1 - 100 of 122 matches
Mail list logo
