flight 125876 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125876/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-xsm
flight 125874 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125874/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken
build-arm64
flight 125897 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125897/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
flight 125872 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125872/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken
build-arm64-xsm
On 8/13/18 4:45 PM, Razvan Cojocaru wrote:
> On 8/13/18 4:38 PM, Jan Beulich wrote:
> On 13.08.18 at 15:19, wrote:
>>> On 8/13/18 3:58 PM, Jan Beulich wrote:
>>> On 13.08.18 at 14:51, wrote:
> So first we've got that vmx_idtv_reinject() call writing to the VMCS,
> then we emulate
Resource mapping is not supported on Arm and results to an error message
at every guest boot:
xenforeignmemory: error: ioctl failed: Operation not supported
Hide the error message when errnor is ENOTSUPP.
Signed-off-by: Julien Grall
---
tools/libs/foreignmemory/linux.c | 2 +-
1 file changed,
flight 125891 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125891/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
Regressions wh
flight 125869 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125869/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken
build-arm64
From: Xiao Liang
Date: Sat, 11 Aug 2018 23:21:37 +0800
> There is a call trace generated after commit
> 2d408c0d4574b01b9ed45e02516888bf925e11a9(
> xen-netfront: fix queue name setting). There is no 'device/vif/xx-q0-tx' file
> found
> under /proc/irq/xx/.
>
> This patch only picks up device t
On 13/08/18 17:29, Jan Beulich wrote:
On 13.08.18 at 16:20, wrote:
>> On 13/08/18 15:54, Jan Beulich wrote:
>> On 13.08.18 at 15:06, wrote:
Suggested new interface
---
Hypercalls, memory map(s) and ACPI tables should stay the same (for
compatibilit
>>> On 13.08.18 at 16:20, wrote:
> On 13/08/18 15:54, Jan Beulich wrote:
> On 13.08.18 at 15:06, wrote:
>>> Suggested new interface
>>> ---
>>> Hypercalls, memory map(s) and ACPI tables should stay the same (for
>>> compatibility reasons or because they are architectural i
Hello,
On 13/08/18 14:01, Konrad Rzeszutek Wilk wrote:
On Mon, Aug 13, 2018 at 11:16:14AM +0530, Omkar Bolla wrote:
Please check below log:
Using modules provided by bootloader in FDT
Xen 4.11.1-pre (c/s Mon Jul 30 11:30:09 2018 +0200 git:33ced72) EFI
loader
On 13/08/18 15:57, Ian Jackson wrote:
Both our arm64 boxes are out of commission and repairing them is
taking too long.
CC: Julien Grall
Signed-off-by: Ian Jackson
Acked-by: Julien Grall
Cheers,
---
production-config | 3 +++
1 file changed, 3 insertions(+)
diff --git a/production-co
On Mon, Aug 13, 2018 at 04:27:06PM +0200, Juergen Gross wrote:
> On 13/08/18 16:12, Roger Pau Monné wrote:
> > On Mon, Aug 13, 2018 at 03:06:10PM +0200, Juergen Gross wrote:
> > Currently as you say there's a difference between the xenstore target
> > and the guest memory map, because some memory i
Both our arm64 boxes are out of commission and repairing them is
taking too long.
CC: Julien Grall
Signed-off-by: Ian Jackson
---
production-config | 3 +++
1 file changed, 3 insertions(+)
diff --git a/production-config b/production-config
index df02cd3..fae31ea 100644
--- a/production-config
Hi,
On 01/08/18 00:28, Stefano Stabellini wrote:
domain_build.c is too large.
Move all the ACPI specific device tree generating functions from
domain_build.c to acpi/acpi_dt_build.c.
The directory is called "acpi" so there is no point to duplicate in the
filename.
Also, looking at the code
On 13/08/18 16:12, Roger Pau Monné wrote:
> On Mon, Aug 13, 2018 at 03:06:10PM +0200, Juergen Gross wrote:
>> Today's interface of Xen for memory ballooning is quite a mess. There
>> are some shortcomings which should be addressed somehow. After a
>> discussion on IRC there was consensus we should
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 char by char for a
smooth user experience.
The size of SBS
On 13/08/18 15:54, Jan Beulich wrote:
On 13.08.18 at 15:06, wrote:
>> Suggested new interface
>> ---
>> Hypercalls, memory map(s) and ACPI tables should stay the same (for
>> compatibility reasons or because they are architectural interfaces).
>>
>> As the main confusion i
flight 125866 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125866/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64
On Mon, Aug 13, 2018 at 03:06:10PM +0200, Juergen Gross wrote:
> Today's interface of Xen for memory ballooning is quite a mess. There
> are some shortcomings which should be addressed somehow. After a
> discussion on IRC there was consensus we should try to design a new
> interface addressing the
Hi Stefano,
On 01/08/18 00:28, Stefano Stabellini wrote:
Make vpl011 being able to be used without a userspace component in Dom0.
In that case, output is printed to the Xen serial and input is received
from the Xen serial one character at a time.
Call domain_vpl011_init during construct_domU if
In case we don't want pv block devices we should not test parameters
for sanity and eventually print out error messages. So test precluding
conditions before checking parameters.
Signed-off-by: Juergen Gross
Reviewed-by: Roger Pau Monné
---
drivers/block/xen-blkfront.c | 18 +-
Add a periodic cleanup function to remove old persistent grants which
are no longer in use on the backend side. This avoids starvation in
case there are lots of persistent grants for a device which no longer
is involved in I/O business.
Signed-off-by: Juergen Gross
Reviewed-by: Roger Pau Monné
-
pers_gnts_lock isn't being used anywhere. Remove it.
Signed-off-by: Juergen Gross
Reviewed-by: Roger Pau Monné
---
drivers/block/xen-blkback/common.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/block/xen-blkback/common.h
b/drivers/block/xen-blkback/common.h
index 2339b8d39c5e..1
Persistent grants are used in the Xen's blkfront/blkback drivers to
avoid mapping/unmapping of I/O buffers in the backend for each I/O.
While this speeds up processing quite a bit there are problems related
to persistent grants in some configurations: domains with multiple
block devices making use
Persistent grants are allocated until a threshold per ring is being
reached. Those grants won't be freed until the ring is being destroyed
meaning there will be resources kept busy which might no longer be
used.
Instead of freeing only persistent grants until the threshold is
reached add a timesta
The struct persistent_gnt flags member is meant to be a bitfield of
different flags. There is only PERSISTENT_GNT_ACTIVE flag left, so
convert it to a bool named "active".
Signed-off-by: Juergen Gross
Reviewed-by: Roger Pau Monné
---
drivers/block/xen-blkback/blkback.c | 13 ++---
drive
Hi Stefano,
OOI, on the previous version you said you will explore the CTRL-x N
solution (where N is the domID console to switch too). What was the
result here?
On 01/08/18 00:28, Stefano Stabellini wrote:
Today Ctrl-AAA is used to switch between Xen and Dom0. Extend the
mechanism to allow f
>>> On 13.08.18 at 15:06, wrote:
> Suggested new interface
> ---
> Hypercalls, memory map(s) and ACPI tables should stay the same (for
> compatibility reasons or because they are architectural interfaces).
>
> As the main confusion in the current interface is related to the
>
On 8/13/18 4:38 PM, Jan Beulich wrote:
On 13.08.18 at 15:19, wrote:
>> On 8/13/18 3:58 PM, Jan Beulich wrote:
>> On 13.08.18 at 14:51, wrote:
So first we've got that vmx_idtv_reinject() call writing to the VMCS,
then we emulate a CLI, then the failed vmentry. I can't tell if th
On 8/13/18 4:38 PM, Jan Beulich wrote:
On 13.08.18 at 15:19, wrote:
>> On 8/13/18 3:58 PM, Jan Beulich wrote:
>> On 13.08.18 at 14:51, wrote:
So first we've got that vmx_idtv_reinject() call writing to the VMCS,
then we emulate a CLI, then the failed vmentry. I can't tell if th
On 01/08/18 00:28, Stefano Stabellini wrote:
Make vpl011 being able to be used without a userspace component in Dom0.
In that case, output is printed to the Xen serial and input is received
from the Xen serial one character at a time.
Call domain_vpl011_init during construct_domU if vpl011 is
>>> On 13.08.18 at 15:19, wrote:
> On 8/13/18 3:58 PM, Jan Beulich wrote:
> On 13.08.18 at 14:51, wrote:
>>> So first we've got that vmx_idtv_reinject() call writing to the VMCS,
>>> then we emulate a CLI, then the failed vmentry. I can't tell if the CLI
>>> ran first and then an interrupt po
Hi Stefano,
On 01/08/18 00:28, Stefano Stabellini wrote:
Move the code to calculate in_fifo_level and out_fifo_level out of
vpl011_data_avail, to the caller.
This change will make it possible to reuse vpl011_data_avail with
different ring structures in a later patch.
Signed-off-by: Stefano Stab
On 8/13/18 3:58 PM, Jan Beulich wrote:
On 13.08.18 at 14:51, wrote:
>> So first we've got that vmx_idtv_reinject() call writing to the VMCS,
>> then we emulate a CLI, then the failed vmentry. I can't tell if the CLI
>> ran first and then an interrupt popped up, or if an interrupt had
>> alrea
flight 125890 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125890/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
Regressions wh
On Mon, Aug 13, 2018 at 11:16:14AM +0530, Omkar Bolla wrote:
> Hi,
>
> Thankyou very much Konrad,
> As you suggested, I just have started testing previous versions of Xen, and
> it is working with xen-4.7 stable branch.
Does Xen 4.8 or Xen 4.9 or Xen 4.10 work? Trying to get a bisection point
wo
Today's interface of Xen for memory ballooning is quite a mess. There
are some shortcomings which should be addressed somehow. After a
discussion on IRC there was consensus we should try to design a new
interface addressing the current and probably future needs.
Current interface
-
>>> On 13.08.18 at 14:51, wrote:
> So first we've got that vmx_idtv_reinject() call writing to the VMCS,
> then we emulate a CLI, then the failed vmentry. I can't tell if the CLI
> ran first and then an interrupt popped up, or if an interrupt had
> already been __vmwrit()ten and then CLI caused th
On 8/13/18 3:22 PM, Jan Beulich wrote:
On 13.08.18 at 13:55, wrote:
>> On 8/9/18 11:35 AM, Jan Beulich wrote:
>> On 09.08.18 at 10:20, wrote:
On 8/9/18 10:54 AM, Jan Beulich wrote:
On 08.08.18 at 16:26, wrote:
>> 1. Is it possible to already have a valid interrupt writ
On Fri, Aug 10, 2018 at 3:50 PM, Julien Grall wrote:
> Hi Oleksandr,
Hi Julien.
>
> On 08/10/2018 12:47 PM, Oleksandr Tyshchenko wrote:
>>
>> On Fri, Aug 10, 2018 at 12:44 PM, Julien Grall
>> wrote:
>>>
>>> On 08/09/2018 07:18 PM, Oleksandr Tyshchenko wrote:
On Thu, Aug 9, 2018 at 7:20
>>> On 10.08.18 at 20:27, wrote:
> On Fri, Aug 10, 2018 at 06:49:12PM +0100, Andrew Cooper wrote:
>> All but one user wants mfn as mfn_t, so switch its type. offset is only ever
>> used when multipled by 8, so fold that into its initial calculation. Fold
>> all
>> the pointer arithmic on pl1e t
>>> On 13.08.18 at 13:55, wrote:
> On 8/9/18 11:35 AM, Jan Beulich wrote:
> On 09.08.18 at 10:20, wrote:
>>> On 8/9/18 10:54 AM, Jan Beulich wrote:
>>> On 08.08.18 at 16:26, wrote:
> 1. Is it possible to already have a valid interrupt written in
> VM_ENTRY_INTR_INFO at EXIT_REASO
On 8/9/18 11:35 AM, Jan Beulich wrote:
On 09.08.18 at 10:20, wrote:
>> On 8/9/18 10:54 AM, Jan Beulich wrote:
>> On 08.08.18 at 16:26, wrote:
1. Is it possible to already have a valid interrupt written in
VM_ENTRY_INTR_INFO at EXIT_REASON_EPT_VIOLATION-time in
vmx_vmexit_h
flight 125889 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125889/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-freebsd 7 freebsd-buildfail REGR. vs. 125317
Tests which did
Hi Stefano,
On 01/08/18 00:28, Stefano Stabellini wrote:
Introduce a union in struct vpl011 to contain the console ring members.
A later patch will add another member of the union for the case where
the backend is in Xen.
Signed-off-by: Stefano Stabellini
---
Changes in v3:
- rename ring field
Hi Stefano,
On 01/08/18 00:28, Stefano Stabellini wrote:
Introduce vpl011 support to guests started from Xen: it provides a
simple way to print output from a guest, as most guests come with a
pl011 driver. It is also able to provide a working console with
interrupt support.
The UART exposed to
Hi Stefano,
On 01/08/18 00:28, Stefano Stabellini wrote:
Introduce functions to generate a basic domU device tree, similar to the
existing functions in tools/libxl/libxl_arm.c.
Signed-off-by: Stefano Stabellini
---
Changes in v3:
- remove CONFIG_ACPI for make_chosen_node
- remove make_hypervis
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 v3:
- add patch
---
xen/arch/arm/domain_build.c | 7 ---
1 file changed, 4 insertions(+), 3 deletio
Hi,
Title: You don't really introduce "construct_domU". You implement it. So
a better title would be "Implement construct_domU".
On 01/08/18 00:27, Stefano Stabellini wrote:
Similar to construct_dom0, construct_domU creates a barebone DomU guest.
The device tree node passed as argument is co
On 01/08/18 00:27, Stefano Stabellini wrote:
Call a new function, "create_domUs", from setup_xen to start DomU VMs.
Introduce support for the "xen,domU" compatible node on device tree.
Create new DomU VMs based on the information found on device tree under
"xen,domU". Calls construct_domU for
Make dom0_max_vcpus() a common interface, and implement it on ARM by splitting
the existing alloc_dom0_vcpu0() function in half.
As domain_create() doesn't yet set up the vcpu array, the max value is also
passed into alloc_dom0_vcpu0(). This is temporary for bisectibility and
removed in the follo
For ARM, the call to arch_domain_create() needs to have completed before
domain_max_vcpus() will return the correct upper bound.
For each arch's dom0's, drop the temporary max_vcpus parameter, and allocation
of dom0->vcpu.
With d->max_vcpus now correctly configured before evtchn_init(), the poll
XEN_DOMCTL_max_vcpus is a mandatory hypercall, but nothing actually prevents a
toolstack from unpausing a domain with no vcpus.
Originally, d->vcpus[] was an embedded array in struct domain, but c/s
fb442e217 "x86_64: allow more vCPU-s per guest" in Xen 4.0 altered it to being
dynamically allocate
Hi Stefano,
On 01/08/18 00:27, Stefano Stabellini wrote:
Call a new function, "create_domUs", from setup_xen to start DomU VMs.
Introduce support for the "xen,domU" compatible node on device tree.
Create new DomU VMs based on the information found on device tree under
"xen,domU". Calls construc
Hi Stefano,
On 01/08/18 00:27, Stefano Stabellini wrote:
Move generic initializations out of construct_dom0 so that they can be
reused.
Rename prepare_dtb to prepare_dtb_hwdom to avoid confusion.
No functional changes in this patch.
Signed-off-by: Stefano Stabellini
---
Changes in v3:
- mov
flight 125887 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125887/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
Regressions wh
In future patches, the structure will be extended with further information,
and this is far cleaner than adding extra parameters.
The python stubs are the only user which passes NULL for the existing config
option (which is actually the arch substructure). Therefore, the #ifdefary
moves to compen
This is in preparation to set up d->max_cpus and d->vcpu[] in domain_create(),
and allow later parts of domain construction to have access to the values.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Stefano Stabellini
CC: Julien Grall
CC: Wei Liu
---
xen/common/domain.c | 34
Now that the max_{grant,maptrack}_frames are specified from the very beginning
of grant table construction, the various initialisation functions can be
folded together and simplified as a result.
Leave grant_table_init() as the public interface, which is more consistent
with other subsystems.
Sig
The main purpose of this series is to move the allocation of d->vcpu[] into
XEN_DOMCTL_createdomain, which resolves a longstanding issue since Xen 4.0
whereby the toolstack can cause NULL pointer deferences in Xen by issuing
hypercalls in an unexpected order.
Due to the way cleanup is currently pe
... rather than setting the limits up after domain_create() has completed.
This removes all the gnttab infrastructure for calculating the number of dom0
grant frames, opting instead to require the dom0 construction code to pass a
sane value in via the configuration.
In practice, this now means th
... rather than setting it up once domain_create() has completed. This
involves constructing a default value for dom0.
No practical change in functionality.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Stefano Stabellini
CC: Julien Grall
CC: Wei Liu
---
xen/arch/arm/setup.c |
set_max_evtchn is somewhat weird. It was introduced with the event_fifo work,
but has never been used. Still, it is a bounding on resources consumed by the
event channel infrastructure, and should be part of createdomain, rather than
editable after the fact.
Drop XEN_DOMCTL_set_max_evtchn comple
Now that XEN_DOMCTL_createdomain handles the grant table limits, remove
XEN_DOMCTL_set_gnttab_limits (including XSM hooks and libxc wrappers).
Signed-off-by: Andrew Cooper
Acked-by: Daniel De Graaf
Acked-by: Wei Liu
---
CC: Jan Beulich
v2:
* Split/rearrange to avoid the post-domain-create er
XEN_DOMCTL_set_gnttab_limits is a fairly new hypercall, and is strictly
mandatory. As it pertains to domain limits, it should be provided at
createdomain time.
In preparation to remove the hypercall, extend xen_domctl_createdomain with
the fields and arrange for all callers to pass appropriate de
The underlying C function is about to make the same change, and the structure
is going to gain extra fields.
Signed-off-by: Andrew Cooper
Acked-by: Christian Lindig
---
v2:
* Fix indirection bug with xen_x86_arch_domctlconfig
---
tools/ocaml/libs/xc/xenctrl.ml | 14 +++---
tools/ocaml
flight 75064 distros-debian-sid real [real]
http://osstest.xensource.com/osstest/logs/75064/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-amd64-sid-netboot-pygrub 10 debian-di-install fail like 75048
test-amd64-amd64-i386-sid-netboot-pygru
>>> On 13.08.18 at 09:46, wrote:
> proposed topics so far:
> * 4.10+ changes to Xen's memory scrubbing: discussion of the changes
> that made to it in recent versions of Xen (4.10+) - Christopher
> * Project Management stuff to keep the Momentum going - primarily
> looking for Intel upda
Hi all,
proposed topics so far:
* 4.10+ changes to Xen's memory scrubbing: discussion of the changes that
made to it in recent versions of Xen (4.10+) - Christopher
* Project Management stuff to keep the Momentum going - primarily looking
for Intel updates
Regards
Lars
On 07/08/2018, 1
Some of the paravirt ops defined in pv_irq_ops are for Xen PV guests
only. Define them only if CONFIG_PARAVIRT_XXL is set.
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/irqflags.h | 38 ++-
arch/x86/include/asm/paravirt.h | 2 --
arch/x86/incl
flight 125886 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125886/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
Regressions wh
Most of the paravirt ops defined in pv_cpu_ops are for Xen PV guests
only. Define them only if CONFIG_PARAVIRT_XXL is set.
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/debugreg.h | 2 +-
arch/x86/include/asm/desc.h | 4 ++--
arch/x86/include/asm/irqflags.h | 16 +
paravirt_patch_call() and paravirt_patch_jmp() are used in paravirt.c
only. Convert them to static.
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/paravirt_types.h | 6 --
arch/x86/kernel/paravirt.c| 12 ++--
2 files changed, 6 insertions(+), 12 deletions(-)
diff
The macros ENABLE_INTERRUPTS_SYSEXIT, GET_CR0_INTO_EAX and
PARAVIRT_ADJUST_EXCEPTION_FRAME are used nowhere. Remove their
definitions.
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/irqflags.h | 4
arch/x86/include/asm/paravirt.h | 9 +
arch/x86/kernel/asm-offsets.c | 1 -
Instead of using six globally visible paravirt ops structures combine
them in a single structure, keeping the original structures as
sub-structures.
This avoids the need to assemble struct paravirt_patch_template at
runtime on the stack each time apply_paravirt() is being called (i.e.
when loading
There is no need to have 32-bit code for CONFIG_PGTABLE_LEVELS >= 4.
Remove it.
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/paravirt.h | 20 +++-
1 file changed, 3 insertions(+), 17 deletions(-)
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravi
Most of the paravirt ops defined in pv_mmu_ops are for Xen PV guests
only. Define them only if CONFIG_PARAVIRT_XXL is set.
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/fixmap.h | 2 +-
arch/x86/include/asm/mmu_context.h| 4 +-
arch/x86/include/asm/paravirt.h | 115
All items but name in pv_info are needed by Xen PV only. Define them
with CONFIG_PARAVIRT_XXL set only.
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/paravirt.h | 2 ++
arch/x86/include/asm/paravirt_types.h | 2 ++
arch/x86/include/asm/pgtable-3level_types.h | 2 +-
arc
A large amount of paravirt ops is used by Xen PV guests only. Add a new
config option PARAVIRT_XXL which is selected by XEN_PV. Later we can
put the Xen PV only paravirt ops under the PARACVIRT_XXL umbrella.
Signed-off-by: Juergen Gross
---
arch/x86/Kconfig | 3 +++
arch/x86/xen/Kconfig | 1
The clobbers parameter from paravirt_patch_default() et al isn't used
any longer. Remove it.
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/paravirt_types.h | 7 +++
arch/x86/kernel/alternative.c | 2 +-
arch/x86/kernel/paravirt.c| 14 +-
arch/x86/ker
There is no need any longer to store the clobbers in struct
paravirt_patch_site. Remove clobbers from the struct and from the
related macros.
While at it fix some lines longer than 80 characters.
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/paravirt.h | 33 +++
This series removes some no longer needed stuff from paravirt
infrastructure and puts large quantities of paravirt ops under a new
config option PARAVIRT_XXL which is selected by XEN_PV only.
A pvops kernel without XEN_PV being configured is about 2.5% smaller
with this series applied.
tip commit
84 matches
Mail list logo
