>>> Sarah Newman 09/07/17 3:55 AM >>>
>On 09/05/2017 06:22 AM, Jan Beulich wrote:
>> For XEN_SMEP and XEN_SMAP to not be cleared while bringing up APs we'd
>> need to clone the respective hack used for CPUID_FAULTING. Introduce an
>> inverse of setup_clear_cpu_cap() instead, but let clearing of fe
flight 113118 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113118/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
test-arm64-arm
flight 113116 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113116/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
test-arm64-arm
This run is configured for baseline tests only.
flight 72070 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72070/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b80a4097393c90d041b299ef628e6104612a2586
baseline v
flight 113075 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113075/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-xsm
On 09/05/2017 06:22 AM, Jan Beulich wrote:
> For XEN_SMEP and XEN_SMAP to not be cleared while bringing up APs we'd
> need to clone the respective hack used for CPUID_FAULTING. Introduce an
> inverse of setup_clear_cpu_cap() instead, but let clearing of features
> overrule forced setting of them.
>
flight 113111 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113111/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
test-arm64-arm
flight 113078 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113078/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b80a4097393c90d041b299ef628e6104612a2586
baseline version:
ovmf 3f3a69b87a2d9b8e0186f
flight 113073 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113073/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-pvops
flight 113077 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113077/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf 7001ab0503fe91e4962ab270efc88d12412e3cb7
baseline version:
xtf 295eeb7e3cd8c506c5ade0
flight 113108 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113108/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
test-arm64-arm
On Wed, 2017-09-06 at 12:29 -0700, Stefano Stabellini wrote:
> On Wed, 6 Sep 2017, Dario Faggioli wrote:
> >
> > Or, in general, make sense out of the fact that the stack pointer
> > register changes in such a way that, when we get back in
> > do_softirq(),
> > what's in the stack in the place whe
flight 113072 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113072/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-pvops
flight 113070 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113070/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-xsm
flight 113102 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113102/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
test-arm64-arm
branch xen-unstable
xenbranch xen-unstable
job build-amd64-xsm
testid xen-build
Tree: ovmf https://github.com/tianocore/edk2.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduce
On Wed, 6 Sep 2017, Dario Faggioli wrote:
> On Tue, 2017-09-05 at 15:06 -0700, Stefano Stabellini wrote:
> > On Tue, 5 Sep 2017, Dario Faggioli wrote:
> > >
> > > Re-checking things now, I actually do see that context_switch() on
> > > ARM
> > > is not 'terminal'. It call schedule_tail(), which on
On Sun, 27 Aug 2017, Rajiv Ranganath wrote:
> Signed-off-by: Rajiv Ranganath
This is very detailed, good stuff. I have one question below:
> +
> +## Booting into Xen
> +
> +Build and install Xen and stage1-xen. Please see
> [BUILDING.md](/BUILDING.md#build_fedora).
> +
> +If you followed the c
flight 113067 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113067/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-xsm
On Sun, 27 Aug 2017, Rajiv Ranganath wrote:
> Signed-off-by: Rajiv Ranganath
Reviewed-by: Stefano Stabellini
> ---
> BUILDING.md | 96
> ---
> 1 file changed, 91 insertions(+), 5 deletions(-)
>
> diff --git a/BUILDING.md b/BUILDING.m
On Sun, 27 Aug 2017, Rajiv Ranganath wrote:
> From: Rajiv M Ranganath
>
> Signed-off-by: Rajiv Ranganath
Reviewed-by: Stefano Stabellini
> ---
> .circleci/config.yml | 21 +
> 1 file changed, 21 insertions(+)
> create mode 100644 .circleci/config.yml
>
> diff --git a
On Sun, 27 Aug 2017, Rajiv Ranganath wrote:
> From: Rajiv M Ranganath
>
> Signed-off-by: Rajiv Ranganath
> ---
> build/fedora/components/qemu | 50
> build/fedora/components/rkt | 58
> ++
> build/fedora/componen
On Sun, 27 Aug 2017, Rajiv Ranganath wrote:
> From: Rajiv M Ranganath
>
> Signed-off-by: Rajiv Ranganath
Reviewed-by: Stefano Stabellini
> ---
> README.md |2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/README.md b/README.md
> index 9ea6adf..e1cd40c 100644
> --- a/README.md
>
On Sun, 27 Aug 2017, Rajiv Ranganath wrote:
> From: Rajiv M Ranganath
>
> Signed-off-by: Rajiv Ranganath
Reviewed-by: Stefano Stabellini
> ---
> .gitignore |2 ++
> 1 file changed, 2 insertions(+)
> create mode 100644 .gitignore
>
> diff --git a/.gitignore b/.gitignore
> new file mode
On Sun, 27 Aug 2017, Rajiv Ranganath wrote:
> From: Rajiv M Ranganath
>
> Signed-off-by: Rajiv Ranganath
Reviewed-by: Stefano Stabellini
> ---
> build/fedora/buildroot-README.md | 50
> ++
> 1 file changed, 50 insertions(+)
> create mode 100644 build/f
On Sun, 27 Aug 2017, Rajiv Ranganath wrote:
> From: Rajiv M Ranganath
>
> Signed-off-by: Rajiv Ranganath
Reviewed-by: Stefano Stabellini
> ---
> build/fedora/buildroot-Dockerfile | 113
> +
> 1 file changed, 113 insertions(+)
> create mode 100644 build
On Sun, 27 Aug 2017, Rajiv Ranganath wrote:
> From: Rajiv M Ranganath
>
> Signed-off-by: Rajiv Ranganath
The series is much better now thank you. One question: why did you write
your own init scripts rather than reusing xencommons (with the caveat
that you would have to add make sure to source_
flight 113097 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113097/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
test-arm64-arm64-xl-xsm
On Wed, 30 Aug 2017, George John wrote:
> Hai all,
> Sorry for the delay
> First of all Thank you very much for the quick reply.
> I tried the same with MMC root .It boot up successfully but after typing
> xl list I am getting following errors
>
> libxl: error: libxl.c:662:libxl_list_domain:
With the boot parameter "xen_nopvspin" specified a Xen guest should not
make use of paravirt spinlocks, but behave as if running on bare
metal. This is not true, however, as the qspinlock code will fall back
to a test-and-set scheme when it is detecting a hypervisor.
In order to avoid this disable
With virt_spin_lock() being guarded by a static key the bare metal case
can be optimized by patching the call away completely. In case a kernel
running as a guest it can decide whether to use paravitualized
spinlocks, the current fallback to the unfair test-and-set scheme, or
to mimic the bare meta
There are cases where a guest tries to switch spinlocks to bare metal
behavior (e.g. by setting "xen_nopvspin" boot parameter). Today this
has the downside of falling back to unfair test and set scheme for
qspinlocks due to virt_spin_lock() detecting the virtualized
environment.
Add a static key c
On 06/09/17 18:13, Waiman Long wrote:
> On 09/06/2017 12:04 PM, Peter Zijlstra wrote:
>> On Wed, Sep 06, 2017 at 11:49:49AM -0400, Waiman Long wrote:
#define virt_spin_lock virt_spin_lock
static inline bool virt_spin_lock(struct qspinlock *lock)
{
+ if (!static_branch_likely
On 5 September 2017 at 15:01, Wei Liu wrote:
> On Mon, Sep 04, 2017 at 09:58:07PM +0530, Bhupinder Thakur wrote:
>> Hi Jan,
>>
>>
>> On 28 August 2017 at 14:41, Jan Beulich wrote:
>> On 28.08.17 at 10:56, wrote:
>> >> --- a/config/arm32.mk
>> >> +++ b/config/arm32.mk
>> >> @@ -1,5 +1,6 @@
>
On Tue, 2017-08-29 at 17:30 +0100, George Dunlap wrote:
> On 08/18/2017 07:04 PM, Dario Faggioli wrote:
> >
> > What we're trying to avoid is one of those idle CPUs to
> > wake up, only to discover that the grace period is still
> > running, and that it hence could have be slept longer
> > (saving
flight 113092 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113092/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
test-arm64-arm
On 09/06/2017 12:04 PM, Peter Zijlstra wrote:
> On Wed, Sep 06, 2017 at 11:49:49AM -0400, Waiman Long wrote:
>>> #define virt_spin_lock virt_spin_lock
>>> static inline bool virt_spin_lock(struct qspinlock *lock)
>>> {
>>> + if (!static_branch_likely(&virt_spin_lock_key))
>>> + retur
On Wed, Sep 06, 2017 at 11:49:49AM -0400, Waiman Long wrote:
> > #define virt_spin_lock virt_spin_lock
> > static inline bool virt_spin_lock(struct qspinlock *lock)
> > {
> > + if (!static_branch_likely(&virt_spin_lock_key))
> > + return false;
> > if (!static_cpu_has(X86_FEATURE
On Wed, Sep 06, 2017 at 02:46:50PM +0200, Juergen Gross wrote:
> In case a system has memory above the 16TB boundary double the default
> grant frame number limit per domain. This ensures a pv domain can still
> establish the same number of grants even if it is required to use
> version 2 grants wh
On Wed, Sep 06, 2017 at 02:46:49PM +0200, Juergen Gross wrote:
> Instead of using the same global resource limits of grant tables (max.
> number of grant frames, max. number of maptrack frames) for all domains
> make these limits per domain. This will allow setting individual limits
> in the future
On Tue, Sep 5, 2017 at 4:06 PM, Wei Liu wrote:
> On Tue, Jul 18, 2017 at 05:25:30PM +0300, Oleksandr Grytsov wrote:
>> From: Oleksandr Grytsov
>>
>> Due to changes in device framework setdefault function
>> should have same format. Otherwise calling devicetype
>> set_default causes segfault.
>>
>
On 09/06/2017 11:29 AM, Juergen Gross wrote:
> There are cases where a guest tries to switch spinlocks to bare metal
> behavior (e.g. by setting "xen_nopvspin" boot parameter). Today this
> has the downside of falling back to unfair test and set scheme for
> qspinlocks due to virt_spin_lock() detec
On 09/06/2017 11:29 AM, Juergen Gross wrote:
> With the boot parameter "xen_nopvspin" specified a Xen guest should not
> make use of paravirt spinlocks, but behave as if running on bare
> metal. This is not true, however, as the qspinlock code will fall back
> to a test-and-set scheme when it is de
Hi Tamas,
There are still some loose ends to tie up, but a soon as I will fix
then I will try to upstream my patch.
Best regards,
Petre
On Mi, 2017-09-06 at 09:12 -0600, Tamas K Lengyel wrote:
> On Wed, Sep 6, 2017 at 7:48 AM, Petre Pircalabu
> wrote:
> >
> > This patchset implements a mechan
On Mon, Sep 04, 2017 at 09:38:11AM -0600, Jan Beulich wrote:
> >>> On 14.08.17 at 16:28, wrote:
> > Changes since v4:
> >[...]
> > * Hypervisor code:
> >[...]
> > - Constify the data opaque parameter of read handlers.
>
> Is that a good idea? Such callbacks should generally be allowed to
> modif
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-4.14b-rc1-tag
xen: fixes and features for 4.14
It contains the following commits:
- the new pvcalls backend for routing socket calls from a guest to dom0
- some cleanups of Xen code
-
On Wed, Sep 06, 2017 at 05:36:54PM +0200, Juergen Gross wrote:
> On 06/09/17 17:32, Wei Liu wrote:
> > On Wed, Sep 06, 2017 at 05:15:46PM +0200, Juergen Gross wrote:
> +grant_table_init(struct domain *d)
> +{
> +struct grant_table *gt = d->grant_table;
> +unsigned int i,
On Tue, Sep 5, 2017 at 4:03 PM, Wei Liu wrote:
> On Tue, Jul 18, 2017 at 05:25:27PM +0300, Oleksandr Grytsov wrote:
>> From: Oleksandr Grytsov
>>
>> Signed-off-by: Oleksandr Grytsov
>> diff --git a/tools/libxl/libxl_nic.c b/tools/libxl/libxl_nic.c
>> index dd07a6c..16a6c8c 100644
>> --- a/tools/
On 06/09/17 17:32, Wei Liu wrote:
> On Wed, Sep 06, 2017 at 05:15:46PM +0200, Juergen Gross wrote:
+grant_table_init(struct domain *d)
+{
+struct grant_table *gt = d->grant_table;
+unsigned int i, j;
+
+if ( gt->nr_grant_frames )
+return 0;
>>>
On Wed, Sep 06, 2017 at 05:15:46PM +0200, Juergen Gross wrote:
> >> +grant_table_init(struct domain *d)
> >> +{
> >> +struct grant_table *gt = d->grant_table;
> >> +unsigned int i, j;
> >> +
> >> +if ( gt->nr_grant_frames )
> >> +return 0;
> >> +
> >
> > EBUSY here? I think we
Instead, preserve PGC_need_scrub bit when setting PGC_state_inuse
state while still under the lock and clear those pages later.
Note that we still need to grub the lock when clearing PGC_need_scrub
bit since count_info might be updated during MCE handling in
mark_page_offline().
Signed-off-by: Bo
With virt_spin_lock() being guarded by a static key the bare metal case
can be optimized by patching the call away completely. In case a kernel
running as a guest it can decide whether to use paravitualized
spinlocks, the current fallback to the unfair test-and-set scheme, or
to mimic the bare meta
There are cases where a guest tries to switch spinlocks to bare metal
behavior (e.g. by setting "xen_nopvspin" boot parameter). Today this
has the downside of falling back to unfair test and set scheme for
qspinlocks due to virt_spin_lock() detecting the virtualized
environment.
Add a static key c
With the boot parameter "xen_nopvspin" specified a Xen guest should not
make use of paravirt spinlocks, but behave as if running on bare
metal. This is not true, however, as the qspinlock code will fall back
to a test-and-set scheme when it is detecting a hypervisor.
In order to avoid this disable
On 06/09/17 17:11, Wei Liu wrote:
> On Wed, Sep 06, 2017 at 02:46:48PM +0200, Juergen Gross wrote:
>> diff --git a/xen/common/domain.c b/xen/common/domain.c
>> index 5aebcf265f..11eb1778a3 100644
>> --- a/xen/common/domain.c
>> +++ b/xen/common/domain.c
>> @@ -363,6 +363,9 @@ struct domain *domain_
On Wed, Sep 6, 2017 at 7:48 AM, Petre Pircalabu
wrote:
> This patchset implements a mechanism which allows XEN to send first an event
> if the emulator encountered an unsupported instruction.
> The monitor application can choose to mitigate the error, for example to
> singlestep
> the instruction
On Wed, Sep 06, 2017 at 02:46:48PM +0200, Juergen Gross wrote:
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index 5aebcf265f..11eb1778a3 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -363,6 +363,9 @@ struct domain *domain_create(domid_t domid, unsigned int
> dom
On Wed, Sep 06, 2017 at 12:18:03PM +0200, Juergen Gross wrote:
> On 05/09/17 09:28, Vincent Legout wrote:
> > Hello,
> >
> > Sorry for such a long delay. I'm still interested in having this patch
> > merged.
> >
> > I've tried to make the patch more generic and move it to xenbus as
> > discussed
flight 113084 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113084/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
test-arm64-arm
On Wed, Aug 23, 2017 at 02:25:05PM +0100, Ross Lagerwall wrote:
> When the guest writes to the RTC, Xen emulates it and broadcasts a
> TIMEOFFSET ioreq. Emit an RTC_CHANGE QMP event to all QMP monitors when
> this happens rather than ignoring it so that something useful can be
> done with the infor
All,
I am pleased to announce the release of Xen 4.8.2. This is
available immediately from its git repository
http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.8
(tag RELEASE-4.8.2) or from the XenProject download page
http://www.xenproject.org/downloads/xen-archives/xen-p
branch xen-unstable
xenbranch xen-unstable
job build-amd64
testid xen-build
Tree: ovmf https://github.com/tianocore/edk2.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced pr
On 09/06/2017 02:49 PM, Paul Durrant wrote:
>> -Original Message-
>> From: Joao Martins [mailto:joao.m.mart...@oracle.com]
>> Sent: 01 September 2017 15:51
>> To: Xen-devel
>> Cc: Wei Liu ; Paul Durrant ;
>> Konrad Rzeszutek Wilk ; Joao Martins
>>
>> Subject: [PATCH v2 1/1] public/io/neti
Roger Pau Monne writes ("[PATCH] osstest: fix a typo in mg-repro-setup"):
> Signed-off-by: Roger Pau Monné
Included in my latest push, thanks.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
flight 113063 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113063/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-pvops
> -Original Message-
> From: Joao Martins [mailto:joao.m.mart...@oracle.com]
> Sent: 01 September 2017 15:51
> To: Xen-devel
> Cc: Wei Liu ; Paul Durrant ;
> Konrad Rzeszutek Wilk ; Joao Martins
>
> Subject: [PATCH v2 1/1] public/io/netif.h: add gref mapping control messages
>
> Adds 3 m
Enforce the distinction between an instruction not implemented by the
emulator and the failure to emulate that instruction by defining a new
return code, X86EMUL_UNIMPLEMENTED.
This value should only be returned by the core emulator only if it fails to
properly decode the current instruction's opc
This patchset implements a mechanism which allows XEN to send first an event
if the emulator encountered an unsupported instruction.
The monitor application can choose to mitigate the error, for example to
singlestep
the instruction using the real processor and then resume execution of the normal
If case of a vm_event with the emulate_flags set, if the instruction
is not implemented by the emulator, the monitor should be notified instead
of directly injecting a hw exception.
This behavior can be used to re-execute an instruction not supported by
the emulator using the real processor (e.g. a
Signed-off-by: Petre Pircalabu
---
.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/.gitignore b/.gitignore
index 594ffd9..8af9c02 100644
--- a/.gitignore
+++ b/.gitignore
@@ -27,6 +27,7 @@ cscope.in.out
cscope.out
cscope.po.out
.config
+.vimrc
dist
stubdom/*.tar.gz
--
2.7.4
On Wed, Sep 06, 2017 at 04:02:23PM +0300, Oleksandr Grytsov wrote:
> On Tue, Sep 5, 2017 at 4:04 PM, Wei Liu wrote:
> > On Tue, Sep 05, 2017 at 01:58:53PM +0100, Ian Jackson wrote:
> >> Wei Liu writes ("Re: [PATCH v4 03/13] libxl: add vdispl device"):
> >> > > +rc = snprintf(connector_path, 12
This reverts commit 153eba4726dfa1bdfc31d1fe973b2a61b9035492.
This patch prevents PCI passthrough hotplug on Xen. Even if the Xen tool
stack prepares its own ACPI tables, we still rely on QEMU for hotplug
ACPI notifications.
The original issue is fixed by the two previous patch:
hw/acpi: Limit
HW part of ACPI PCI hotplug in QEMU depends on ACPI_PCIHP_PROP_BSEL
being set on a PCI bus that supports ACPI hotplug. It should work
regardless of the source of ACPI tables (QEMU generator/legacy SeaBIOS/Xen).
So move ACPI_PCIHP_PROP_BSEL initialization into HW ACPI implementation
part from QEMU's
Adding PCI passthrough before the guest start works fine (broken in 2.9 but now
fixed), but hotplug does not work anymore.
Anthony PERARD (3):
hw/acpi: Limit hotplug to root bus on legacy mode
hw/acpi: Move acpi_set_pci_info to pcihp
Revert "ACPI: don't call acpi_pcihp_device_plug_cb on xen"
Signed-off-by: Anthony PERARD
---
New patch in V3
---
hw/acpi/pcihp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/acpi/pcihp.c b/hw/acpi/pcihp.c
index c420a388ea..9db3c2eaf2 100644
--- a/hw/acpi/pcihp.c
+++ b/hw/acpi/pcihp.c
@@ -273,7 +273,7 @@ static void pci_write(voi
On 09/06/2017 09:06 AM, Peter Zijlstra wrote:
> On Wed, Sep 06, 2017 at 08:44:09AM -0400, Waiman Long wrote:
>> On 09/06/2017 03:08 AM, Peter Zijlstra wrote:
>>> Guys, please trim email.
>>>
>>> On Tue, Sep 05, 2017 at 10:31:46AM -0400, Waiman Long wrote:
For clarification, I was actually aski
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of
> Juergen Gross
> Sent: 06 September 2017 13:47
> To: xen-devel@lists.xen.org
> Cc: Juergen Gross ; sstabell...@kernel.org; Wei Liu
> ; George Dunlap ;
> Andrew Cooper ; Ian Jackson
> ; Tim (Xen.org
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of
> Juergen Gross
> Sent: 06 September 2017 13:47
> To: xen-devel@lists.xen.org
> Cc: Juergen Gross ; sstabell...@kernel.org; Wei Liu
> ; George Dunlap ;
> Andrew Cooper ; Ian Jackson
> ; Tim (Xen.org
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of
> Juergen Gross
> Sent: 06 September 2017 13:47
> To: xen-devel@lists.xen.org
> Cc: Juergen Gross ; sstabell...@kernel.org; Wei Liu
> ; George Dunlap ;
> Andrew Cooper ; Ian Jackson
> ; Tim (Xen.org
On Wed, Sep 06, 2017 at 08:44:09AM -0400, Waiman Long wrote:
> On 09/06/2017 03:08 AM, Peter Zijlstra wrote:
> > Guys, please trim email.
> >
> > On Tue, Sep 05, 2017 at 10:31:46AM -0400, Waiman Long wrote:
> >> For clarification, I was actually asking if you consider just adding one
> >> more jump
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of
> Juergen Gross
> Sent: 06 September 2017 13:47
> To: xen-devel@lists.xen.org
> Cc: Juergen Gross ; sstabell...@kernel.org; Wei Liu
> ; George Dunlap ;
> Andrew Cooper ; Ian Jackson
> ; Tim (Xen.org
On Tue, Sep 5, 2017 at 4:04 PM, Wei Liu wrote:
> On Tue, Sep 05, 2017 at 01:58:53PM +0100, Ian Jackson wrote:
>> Wei Liu writes ("Re: [PATCH v4 03/13] libxl: add vdispl device"):
>> > > +rc = snprintf(connector_path, 128, "%s/%d", path,
>> > > info->num_connectors);
>>
>> Why not use GCSPRINT
flight 113071 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113071/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 6dfb43d6f2cd8ea6274d203ca00ecfc7c565f11a
baseline version:
xen ee2c
Add new domain config items for setting the limits for the maximum
numbers of grant table frames and maptrack frames of a domain.
Signed-off-by: Juergen Gross
---
docs/man/xl.cfg.pod.5.in| 15 +++
tools/libxl/libxl.h | 6 ++
tools/libxl/libxl_dom.c | 8
Delay the allocation of the grant table sub structures in order to
allow modifying parameters needed for sizing of these structures at a
per domain basis. Either do it from gnttab_setup_table() or just
before the domain is started the first time.
Signed-off-by: Juergen Gross
---
V3:
- move call o
Add a domctl hypercall to set the domain's resource limits regarding
grant tables. It is accepted only as long as neither
gnttab_setup_table() has been called for the domain, nor the domain
has started to run.
Signed-off-by: Juergen Gross
---
V3:
- rename *gnttbl* to *gnttab* (Paul Durrant)
---
The x86 and arm versions of XENMAPSPACE_grant_table handling are nearly
identical. Move the code into a function in grant_table.c and add an
architecture dependant hook to handle the differences.
Switch to mfn_t in order to be more type safe.
Signed-off-by: Juergen Gross
Reviewed-by: Paul Durran
Add a new libxc function xc_domain_set_gnttbl_limits() setting the
limits for the maximum numbers of grant table frames and maptrack
frames of a domain.
Signed-off-by: Juergen Gross
---
tools/libxc/include/xenctrl.h | 14 ++
tools/libxc/xc_domain.c | 13 +
2 files c
Many definitions can be moved from xen/grant_table.h to
common/grant_table.c now, as they are no longer used in other sources.
Signed-off-by: Juergen Gross
Reviewed-by: Paul Durrant
Reviewed-by: Wei Liu
---
xen/common/grant_table.c | 83 --
xen/incl
Currently Linux has no support for grant v2 as this would reduce the
maximum number of active grants by a factor of 2 compared to v1,
because the number of possible grants are limited by the allowed number
of grant frames and grant entries of v2 need twice as much bytes as
those of v1.
Unfortunate
Instead of using the same global resource limits of grant tables (max.
number of grant frames, max. number of maptrack frames) for all domains
make these limits per domain. This will allow setting individual limits
in the future. For now initialize the per domain limits with the global
values.
Sig
In case a system has memory above the 16TB boundary double the default
grant frame number limit per domain. This ensures a pv domain can still
establish the same number of grants even if it is required to use
version 2 grants which need twice the space of v1 grants.
Signed-off-by: Juergen Gross
R
On 09/06/2017 03:08 AM, Peter Zijlstra wrote:
> Guys, please trim email.
>
> On Tue, Sep 05, 2017 at 10:31:46AM -0400, Waiman Long wrote:
>> For clarification, I was actually asking if you consider just adding one
>> more jump label to skip it for Xen/KVM instead of making
>> virt_spin_lock() a pv-
On Tue, Sep 5, 2017 at 2:51 PM, Wei Liu wrote:
> On Tue, Jul 18, 2017 at 05:25:19PM +0300, Oleksandr Grytsov wrote:
>> From: Oleksandr Grytsov
>>
>> Add libxl__device_list and libxl__device_list_free
>> functions to handle device list using the device
>> framework.
>>
>> Signed-off-by: Oleksandr
flight 113074 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113074/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
test-arm64-arm
On Wed, Sep 06, Andrew Cooper wrote:
> If a PVH guest has got MTRRs disabled, then it genuinely can run on an
> unshattered 1G superpage at 0.
Ok, the code will detect the holes and will release memory as needed. I
will drop these two lines.
Olaf
signature.asc
Description: PGP signature
_
On Wed, Sep 06, Andrew Cooper wrote:
> I still fail to understand why you need the bitmaps at all? You can
> calculate everything you need from the pfn list alone, which will also
> let you spot the presence or absence of the VGA hole.
These bitmaps track if a range has been allocated as superpa
On 06/09/17 13:17, Olaf Hering wrote:
> On Wed, Sep 06, Andrew Cooper wrote:
>
>> On 01/09/17 17:08, Olaf Hering wrote:
>>> +/* No superpage in 1st 2MB due to VGA hole */
>>> +xc_sr_set_bit(0, &ctx->x86_hvm.restore.attempted_1g);
>>> +xc_sr_set_bit(0, &ctx->x86_hvm.restore.attempted_2m)
On Wed, Sep 06, Andrew Cooper wrote:
> On 01/09/17 17:08, Olaf Hering wrote:
> > +/* No superpage in 1st 2MB due to VGA hole */
> > +xc_sr_set_bit(0, &ctx->x86_hvm.restore.attempted_1g);
> > +xc_sr_set_bit(0, &ctx->x86_hvm.restore.attempted_2m);
> This is false for PVH guests.
How can
On Wed, Sep 06, Andrew Cooper wrote:
> On 01/09/17 17:08, Olaf Hering wrote:
> > +static inline bool pfn_is_populated(struct xc_sr_context *ctx, xen_pfn_t
> > pfn)
> > +static inline int pfn_set_populated(struct xc_sr_context *ctx, xen_pfn_t
> > pfn)
> Why are these moved? They are still restor
1 - 100 of 158 matches
Mail list logo