flight 149477 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149477/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 48f0e94921d83b8204f1025412e071b000394f04
baseline version:
ovmf ee026ea78b0e32a9ffbaf
> -Original Message-
> From: Xen-devel On Behalf Of Andrew
> Cooper
> Sent: 06 April 2020 19:07
> To: Harsha Shamsundara Havanur ;
> xen-devel@lists.xenproject.org
> Cc: Ian Jackson ; Wei Liu ; Jan
> Beulich ;
> Roger Pau Monné
> Subject: Re: [XEN PATCH] hvmloader: Enable MMIO and I/O
> -Original Message-
> From: Xen-devel On Behalf Of Harsha
> Shamsundara Havanur
> Sent: 06 April 2020 18:47
> To: xen-devel@lists.xenproject.org
> Cc: Wei Liu ; Andrew Cooper ; Ian
> Jackson
> ; Jan Beulich ; Harsha
> Shamsundara Havanur
> ; Roger Pau Monné
> Subject: [XEN PATCH] hvml
> -Original Message-
> From: Xen-devel On Behalf Of Tamas K
> Lengyel
> Sent: 06 April 2020 18:31
> To: Andrew Cooper
> Cc: Xen-devel ; Anastassios Nanos
>
> Subject: Re: Live migration and PV device handling
>
> On Mon, Apr 6, 2020 at 11:24 AM Andrew Cooper
> wrote:
> >
> > On 06/0
On 06.04.2020 19:46, Harsha Shamsundara Havanur wrote:
> --- a/tools/firmware/hvmloader/pci.c
> +++ b/tools/firmware/hvmloader/pci.c
> @@ -84,6 +84,7 @@ void pci_setup(void)
> uint32_t vga_devfn = 256;
> uint16_t class, vendor_id, device_id;
> unsigned int bar, pin, link, isa_irq;
>
On 04.04.2020 15:10, Julien Grall wrote:
> From: Julien Grall
>
> Add missing emacs magics for xen/guest_access.h and
> asm-x86/guest_access.h.
>
> Signed-off-by: Julien Grall
I don't think these are "missing"; as per ./CODING_STYLE they're
permitted, but not required (and I continue to questi
On Tue, Apr 07, 2020 at 08:48:42AM +0100, Paul Durrant wrote:
> > -Original Message-
> > From: Xen-devel On Behalf Of
> > Harsha Shamsundara Havanur
> > Sent: 06 April 2020 18:47
> > To: xen-devel@lists.xenproject.org
> > Cc: Wei Liu ; Andrew Cooper ; Ian
> > Jackson
> > ; Jan Beulich ;
On 04.04.2020 15:10, Julien Grall wrote:
> From: Julien Grall
>
> Most of the helpers to access guest memory are implemented the same way
> on Arm and x86. The only differences are:
> - guest_handle_{from, to}_param(): while on x86 XEN_GUEST_HANDLE()
> and XEN_GUEST_HANDLE_PARAM() are t
> -Original Message-
> From: Roger Pau Monné
> Sent: 07 April 2020 09:07
> To: p...@xen.org
> Cc: 'Harsha Shamsundara Havanur' ;
> xen-devel@lists.xenproject.org; 'Wei Liu'
> ; 'Andrew Cooper' ; 'Ian Jackson'
> ;
> 'Jan Beulich'
> Subject: Re: [XEN PATCH] hvmloader: Enable MMIO and I/O
On 04.04.2020 15:10, Julien Grall wrote:
> From: Julien Grall
>
> * Add space before and after operator
> * Align \
> * Format comments
To be honest, despite the reason you give for the split in patch 6,
I'd rather see code movement like this to do formatting adjustments
right away.
On Tue, Apr 07, 2020 at 09:14:53AM +0100, Paul Durrant wrote:
> > -Original Message-
> > From: Roger Pau Monné
> > Sent: 07 April 2020 09:07
> > To: p...@xen.org
> > Cc: 'Harsha Shamsundara Havanur' ;
> > xen-devel@lists.xenproject.org; 'Wei Liu'
> > ; 'Andrew Cooper' ; 'Ian Jackson'
> >
On 07.04.2020 10:14, Paul Durrant wrote:
>> -Original Message-
>> From: Roger Pau Monné
>> Sent: 07 April 2020 09:07
>> To: p...@xen.org
>> Cc: 'Harsha Shamsundara Havanur' ;
>> xen-devel@lists.xenproject.org; 'Wei Liu'
>> ; 'Andrew Cooper' ; 'Ian Jackson'
>> ;
>> 'Jan Beulich'
>> Subje
On 07.04.2020 10:25, Roger Pau Monné wrote:
> IMO forcefully disabling decodings (and enabling them afterwards if
> already enabled) and leaving bus mastering as-is would be better.
Limiting this to the "already enabled" case may not be enough:
Devices needed for guest booting may need them to be
flight 149475 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149475/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs.
144861
test-amd6
Hi Jan,
On 06/04/2020 12:01, Jan Beulich wrote:
On 04.04.2020 15:06, Julien Grall wrote:
From: Julien Grall
At the moment, *copy_to_guest_offset() will allow the hypervisor to copy
data to guest handle marked const.
Thankfully, no users of the helper will do that. Rather than hoping this
can
On 07.04.2020 11:01, Julien Grall wrote:
> Hi Jan,
>
> On 06/04/2020 12:01, Jan Beulich wrote:
>> On 04.04.2020 15:06, Julien Grall wrote:
>>> From: Julien Grall
>>>
>>> At the moment, *copy_to_guest_offset() will allow the hypervisor to copy
>>> data to guest handle marked const.
>>>
>>> Thankfu
On 07/04/2020 09:17, Jan Beulich wrote:
On 04.04.2020 15:10, Julien Grall wrote:
From: Julien Grall
* Add space before and after operator
* Align \
* Format comments
To be honest, despite the reason you give for the split in patch 6,
I'd rather see code movement like this t
Could someone please have a look at this patch? It solves an actual issue:
Try soft-reset with qemu-xen-traditional and it will fail.
On 3/13/20 1:33 PM, Maximilian Heyne wrote:
Following up on commit 9c0eed61 ("qemu-trad: stop using the default IOREQ
server"), clean up the IOREQ server on exit.
Commit 0537d246f8db ("mm: add 'is_special_page' inline function...")
moved the is_special_page() checks first in its respective changes to
PoD code. While this is fine for p2m_pod_zero_check_superpage(), the
validity of the MFN is inferred in both cases from the p2m_is_ram()
check, which therefore
On 06.04.20 16:02, Anthony PERARD wrote:
> Commit a31ca6801c02 ("qemu/queue.h: clear linked list pointers on
> remove") revealed that a request was removed twice from a list, once
> in xen_block_finish_request() and a second time in
> xen_block_release_request() when both function are called from
>
> -Original Message-
> From: Jan Beulich
> Sent: 07 April 2020 12:08
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Roger Pau Monné
> ; Wei Liu
> ; Paul Durrant
> Subject: [PATCH] x86/PoD: correct ordering of checks in p2m_pod_zero_check()
>
> Commit 0537d246f8db ("mm: add '
On 07.04.2020 14:39, Paul Durrant wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 07 April 2020 12:08
>> To: xen-devel@lists.xenproject.org
>> Cc: Andrew Cooper ; Roger Pau Monné
>> ; Wei Liu
>> ; Paul Durrant
>> Subject: [PATCH] x86/PoD: correct ordering of checks in p2m_pod_
On 07/04/2020 12:07, Jan Beulich wrote:
> Commit 0537d246f8db ("mm: add 'is_special_page' inline function...")
> moved the is_special_page() checks first in its respective changes to
> PoD code. While this is fine for p2m_pod_zero_check_superpage(), the
> validity of the MFN is inferred in both cas
We haven't used mini-os master for about 2 years now due to a stubdom
test failing [1]. Booting a guest with mini-os master used for building
stubdom didn't reveal any problem, so use master for unstable in order
to let OSStest find any problems not showing up in the local test.
[1]: https://lists
On Mon, 2020-04-06 at 13:03 +0200, Jan Beulich wrote:
> On 06.04.2020 10:27, Hongyan Xia wrote:
> > Ping.
>
> Does this somehow imply you didn't get my replies sent on the 1st?
>
> Jan
Apologies. Somehow your replies ended up in a separate thread. There is
a problem with my email client.
Hongya
On Tue, Apr 7, 2020 at 1:57 AM Paul Durrant wrote:
>
> > -Original Message-
> > From: Xen-devel On Behalf Of Tamas
> > K Lengyel
> > Sent: 06 April 2020 18:31
> > To: Andrew Cooper
> > Cc: Xen-devel ; Anastassios Nanos
> >
> > Subject: Re: Live migration and PV device handling
> >
> >
On Wed, 2020-04-01 at 14:29 +0200, Jan Beulich wrote:
> On 23.03.2020 10:41, Hongyan Xia wrote:
> > --- a/xen/include/asm-x86/page.h
> > +++ b/xen/include/asm-x86/page.h
> > @@ -196,6 +196,24 @@ static inline l4_pgentry_t
> > l4e_from_paddr(paddr_t pa, unsigned int flags)
> > #define map_l2t_from_
On 07.04.2020 17:11, Hongyan Xia wrote:
> On Wed, 2020-04-01 at 14:29 +0200, Jan Beulich wrote:
>> On 23.03.2020 10:41, Hongyan Xia wrote:
>>> --- a/xen/include/asm-x86/page.h
>>> +++ b/xen/include/asm-x86/page.h
>>> @@ -196,6 +196,24 @@ static inline l4_pgentry_t
>>> l4e_from_paddr(paddr_t pa, uns
The following changes since commit 8f0d25c464a1989d606f7b988d07b1147dfcde33:
Merge remote-tracking branch
'remotes/philmd-gitlab/tags/acceptance-fixes-20200407' into staging (2020-04-07
15:10:11 +0100)
are available in the Git repository at:
https://xenbits.xen.org/git-http/peop
From: Peter Maydell
The function usbback_packet_complete() currently takes a USBPacket*,
which must be a pointer to the packet field within a struct
usbback_req; the function uses container_of() to get the struct
usbback_req* given the USBPacket*.
This is unnecessarily confusing (and in particul
Since 7f5d9b206d1e ("object-add: don't create return value if
failed"), qmp_object_add() don't write any value in 'ret_data', thus
has random data. Then qobject_unref() fails and abort().
Fix by initialising 'ret_data' properly.
Fixes: 5f07c4d60d09 ("qapi: Flatten object-add")
Signed-off-by: Anth
Signed-off-by: Anthony PERARD
Acked-by: Paul Durrant
Message-Id: <20200406165043.1447837-1-anthony.per...@citrix.com>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 9d156d73b31e..839959f7e4ac 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -440,
Dmitry Isaykin writes ("[PATCH] tools/xl: Remove the filelock when building VM
if autoballooning is off"):
> The presence of this filelock does not allow building several VMs at the same
> time. This filelock was added to prevent other xl instances from using memory
> freeed for the currently buil
Feature support status is tracked in SUPPORT.md nowadays.
Signed-off-by: Ian Jackson
---
MAINTAINERS | 60
1 file changed, 60 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8a4c869704..e784169d1b 100644
--- a/MAINTAINERS
++
> On Apr 6, 2020, at 7:47 PM, Julien Grall wrote:
>
> On 06/04/2020 18:58, George Dunlap wrote:
>>> On Apr 3, 2020, at 9:27 PM, Julien Grall wrote:
>>>
>>> On Fri, 3 Apr 2020 at 20:41, Stefano Stabellini
>>> wrote:
On Thu, 2 Apr 2020, Julien Grall wrote:
> As we discussed on
On Wed, 2020-04-01 at 14:40 +0200, Jan Beulich wrote:
> On 23.03.2020 10:41, Hongyan Xia wrote:
> > @@ -297,26 +298,33 @@ static void destroy_m2p_mapping(struct
> > mem_hotadd_info *info)
> > continue;
> > }
> >
> > -l2_ro_mpt = l3e_to_l2e(l3_ro_mpt[l3_table_offset(v
On 7 Apr 2020, at 17:16, George Dunlap
mailto:george.dun...@citrix.com>> wrote:
On Apr 6, 2020, at 7:47 PM, Julien Grall
mailto:jul...@xen.org>> wrote:
On 06/04/2020 18:58, George Dunlap wrote:
On Apr 3, 2020, at 9:27 PM, Julien Grall
mailto:julien.grall@gmail.com>> wrote:
On Fri, 3 A
On 07/04/2020 17:16, George Dunlap wrote:
On Apr 6, 2020, at 7:47 PM, Julien Grall wrote:
On 06/04/2020 18:58, George Dunlap wrote:
On Apr 3, 2020, at 9:27 PM, Julien Grall wrote:
On Fri, 3 Apr 2020 at 20:41, Stefano Stabellini wrote:
On Thu, 2 Apr 2020, Julien Grall wrote:
As we d
On 07/04/2020 17:25, Bertrand Marquis wrote:
This is possible to do on a per interrupt basis or when all interrupts
in LR registers have all been handled (maintenance interrupt when there
is nothing left to handle in LR registers, used to fire other interrupts
if we have more pending interru
On 07/04/2020 17:50, Julien Grall wrote:
On 07/04/2020 17:16, George Dunlap wrote:
On Apr 6, 2020, at 7:47 PM, Julien Grall wrote:
On 06/04/2020 18:58, George Dunlap wrote:
On Apr 3, 2020, at 9:27 PM, Julien Grall
wrote:
On Fri, 3 Apr 2020 at 20:41, Stefano Stabellini
wrote:
On
flight 149478 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149478/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-dom0pvh-xl-intel 17 guest-saverestore.2 fail pass in 149451
test-amd64-amd64-examine 4
Hi,
On 07/04/2020 17:15, Ian Jackson wrote:
Feature support status is tracked in SUPPORT.md nowadays.
I don't think we track everything the same way. At least...
Signed-off-by: Ian Jackson
---
MAINTAINERS | 60
1 file changed,
From: Paul Durrant
Paul Durrant (5):
xen/common: introduce a new framework for save/restore of 'domain'
context
xen/common/domctl: introduce XEN_DOMCTL_get/setdomaincontext
tools/misc: add xen-domctx to present domain context
common/domain: add a domain context record for shared_info.
To allow enlightened HVM guests (i.e. those that have PV drivers) to be
migrated without their co-operation it will be necessary to transfer 'PV'
state such as event channel state, grant entry state, etc.
Currently there is a framework (entered via the hvm_save/load() functions)
that allows a doma
This tool is analogous to 'xen-hvmctx' which presents HVM context.
Subsequent patches will add 'dump' functions when new records are
introduced.
Signed-off-by: Paul Durrant
---
Cc: Ian Jackson
Cc: Wei Liu
v2:
- Change name from 'xen-ctx' to 'xen-domctx'
---
.gitignore | 1 +
t
... and update xen-domctx to dump some information describing the record.
Signed-off-by: Paul Durrant
---
Cc: Ian Jackson
Cc: Wei Liu
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Jan Beulich
Cc: Julien Grall
Cc: Stefano Stabellini
v2:
- Drop the header change to define a 'Xen' page size and i
... in the save/restore code.
This patch replaces direct mapping of the shared_info_frame (retrieved
using XEN_DOMCTL_getdomaininfo) with save/load of the domain context
SHARED_INFO record.
No modifications are made to the definition of the migration stream at
this point. Subsequent patches will
These domctls provide a mechanism to get and set domain context from
the toolstack.
Signed-off-by: Paul Durrant
---
Cc: Daniel De Graaf
Cc: Ian Jackson
Cc: Wei Liu
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Jan Beulich
Cc: Julien Grall
Cc: Stefano Stabellini
v2:
- drop mask parameter
- co
> On Apr 7, 2020, at 5:50 PM, Julien Grall wrote:
>
>
>
> On 07/04/2020 17:16, George Dunlap wrote:
>>> On Apr 6, 2020, at 7:47 PM, Julien Grall wrote:
>>>
>>> On 06/04/2020 18:58, George Dunlap wrote:
> On Apr 3, 2020, at 9:27 PM, Julien Grall
> wrote:
>
> On Fri, 3 Apr
flight 149485 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149485/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf aab6a9c9aebb1f6614e72e98bdf6b5af93a43527
baseline version:
ovmf 48f0e94921d83b8204f10
Hi George,
On 07/04/2020 19:16, George Dunlap wrote:
On Apr 7, 2020, at 5:50 PM, Julien Grall wrote:
On 07/04/2020 17:16, George Dunlap wrote:
On Apr 6, 2020, at 7:47 PM, Julien Grall wrote:
On 06/04/2020 18:58, George Dunlap wrote:
On Apr 3, 2020, at 9:27 PM, Julien Grall wrote:
On
On Tue, Apr 07, 2020 at 03:48:31PM +0200, Juergen Gross wrote:
> We haven't used mini-os master for about 2 years now due to a stubdom
> test failing [1]. Booting a guest with mini-os master used for building
> stubdom didn't reveal any problem, so use master for unstable in order
> to let OSStest
On Tue, Apr 07, 2020 at 02:52:22PM +, Andrew Panyakin wrote:
> libxc defines XGS_POLICY_ABORT for precopy policy to signal that migration
> should be aborted (eg. if the estimated pause time is too huge for the
> instance). Default simple precopy policy never returns that, but it could be
> ove
On Tue, 7 Apr 2020 at 16:22, Anthony PERARD wrote:
>
> The following changes since commit 8f0d25c464a1989d606f7b988d07b1147dfcde33:
>
> Merge remote-tracking branch
> 'remotes/philmd-gitlab/tags/acceptance-fixes-20200407' into staging
> (2020-04-07 15:10:11 +0100)
On 07/04/2020 23:06, Panyakin, Andrew wrote:
> On 4/7/20 10:22 PM, Wei Liu wrote:
>>> +PERROR("Abort precopy loop");
>>> +rc = -1;
>>> +goto out;
>> There is no need to have "goto out" here.
> I was considering two more examples of "goto out" in a branch right before
> the
flight 149499 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149499/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
flight 149497 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149497/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 9bb1f080c45f7253f9270662d55865a8718cebc8
baseline version:
ovmf aab6a9c9aebb1f6614e72
flight 149480 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149480/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-pvshim 7 xen-boot fail REGR. vs. 149238
test-amd64-i386-xl-
flight 149487 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149487/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs.
144861
test-amd6
Introduce native_pv_ops where we stash the pv_ops array before
hypervisor specific hooks have modified it.
native_pv_ops get used when switching between paravirt and native
pv-ops at runtime.
Signed-off-by: Ankur Arora
---
arch/x86/include/asm/paravirt_types.h | 4
arch/x86/kernel/paravir
Various text_poke() variants don't return a useful value. Remove it.
Signed-off-by: Ankur Arora
---
arch/x86/include/asm/text-patching.h | 4 ++--
arch/x86/kernel/alternative.c| 11 +--
2 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/arch/x86/include/asm/text-patc
A KVM host (or another hypervisor) might advertise paravirtualized
features and optimization hints (ex KVM_HINTS_REALTIME) which might
become stale over the lifetime of the guest. For instance, the
host might go from being undersubscribed to being oversubscribed
(or the other way round) and it woul
Persist .parainstructions.runtime in memory. We will use it to
patch paravirt-ops at runtime.
The extra memory footprint depends on chosen config options but the
inlined queued_spin_unlock() presents an edge case:
$ objdump -h vmlinux|grep .parainstructions
Idx Name Size
Rename alternatives_smp_module_*(), smp_alt_module to reflect
their new purpose.
Signed-off-by: Ankur Arora
---
arch/x86/include/asm/alternative.h | 10 +++---
arch/x86/kernel/alternative.c | 54 +++---
arch/x86/kernel/module.c | 8 ++---
3 files changed,
runtime_patch() generates insn sequences for patching supported pv_ops.
It does this by calling paravirt_patch_default() or native_patch()
dpending on if the target is a paravirt or native pv-op.
In addition, runtime_patch() also whitelists pv-ops that are safe to
patch at runtime.
The static con
Allow PVOP macros to specify a subsection such that _paravirt_alt() can
optionally put sites in .parainstructions.*.
Signed-off-by: Ankur Arora
---
arch/x86/include/asm/paravirt_types.h | 158 +-
1 file changed, 102 insertions(+), 56 deletions(-)
diff --git a/arch/x86/in
Paravirt-ops are patched at init to convert indirect calls into
direct calls and in some cases, to inline the target at the call-site.
This is done by way of PVOP* macros which save the call-site
information via compile time annotations.
Pull this state out in .parainstructions.runtime for some pv
Add paravirt_stage_alt() which conditionally selects between a paravirt
or native pv-op and then stages it for later patching.
Signed-off-by: Ankur Arora
---
arch/x86/include/asm/paravirt_types.h | 6 +++
arch/x86/include/asm/text-patching.h | 3 ++
arch/x86/kernel/alternative.c | 58
__start_parainstructions and __stop_parainstructions aren't
defined, remove them.
Signed-off-by: Ankur Arora
---
arch/x86/kernel/alternative.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index 4157f848b537..09e4ee0e09a2 10064
Intended to handle scenarios where we might want to patch arbitrary
instructions (ex. inlined opcodes in pv_lock_ops.)
Users for native mode (as opposed to emulated) are introduced in
later patches.
Signed-off-by: Ankur Arora
---
arch/x86/include/asm/text-patching.h | 4 +-
arch/x86/kernel/alt
Add a selftest that triggers paravirt_runtime_patch() which
toggles between the paravirt and native pv_lock_ops.
The selftest also register an NMI handler, which exercises the
patched pv-ops by spin-lock operations. These are triggered via
artificially sent NMIs.
And last, introduce patch sites i
Patching at runtime needs to handle interdependent pv-ops: as an example,
lock.queued_lock_slowpath(), lock.queued_lock_unlock() and the other
pv_lock_ops are paired and so need to be updated atomically. This is
difficult with emulation because non-patching CPUs could be executing in
critical secti
Enable runtime patching of paravirt spinlocks. These can be trivially
enabled because pv_lock_ops are never preemptible -- preemption is
disabled at entry to spin_lock*().
Note that a particular CPU instance might get preempted in the host but
because runtime_patching() is called via stop_machine(
Add paravirt_patch_runtime() which uses text_poke_late() to patch
paravirt sites.
Also add paravirt_worker() which does the actual insn generation
generate_paravirt() (which uses runtime_patch() to generate the
appropriate native or paravirt insn sequences) and then calls
text_poke_site() to do th
Make __pv_init_lock_hash() conditional on either paravirt spinlocks
being enabled (via kvm_pv_spinlock()) or if paravirt spinlocks
might get enabled (runtime patching via CONFIG_PARAVIRT_RUNTIME.)
Also add a handler for CPUID reprobe which can trigger this patching.
Signed-off-by: Ankur Arora
--
text_poke() uses get_locked_pte() to map poking_addr. However, this
introduces a dependency on locking code which precludes using
text_poke() to modify qspinlock primitives.
Accesses to this pte (and poking_addr) are protected by text_mutex
so we can safely switch to __get_unlocked_pte() here. Not
Add a blocking notifier that triggers when the host sends a hint
change notification.
Suggested-by: Joao Martins
Signed-off-by: Ankur Arora
---
arch/x86/include/asm/kvm_para.h | 10 ++
arch/x86/kernel/kvm.c | 16
include/asm-generic/kvm_para.h | 8
Handle breakpoints if we hit an INT3 either by way of an NMI while
patching a site in the NMI handling path, or if we are patching text
in text_poke_site() (executes on the primary), or in the pipeline sync
path in text_poke_sync_site() (executes on secondary CPUs.)
(The last two are not expected t
Add actual poking and pipeline sync logic in poke_sync(). This is called
from text_poke_site()).
The patching logic is similar to that in text_poke_bp_batch() where we
patch the first byte with an INT3, which serves as a barrier, then patch
the remaining bytes and then come back and fixup the firs
Runtime patching can deadlock with multiple simultaneous NMIs.
This can happen while patching inter-dependent pv-ops which are
used in the NMI path (ex pv_lock_ops):
CPU0 CPUx
patch_worker() patch_worker(
If the hypervisor supports KVM_FEATURE_DYNAMIC_HINTS, then register a
callback vector (currently chosen to be HYPERVISOR_CALLBACK_VECTOR.)
The callback triggers on a change in the active hints which are
are exported via KVM CPUID in %ecx.
Trigger re-evaluation of KVM_HINTS based on change in their
Refactor alternatives_smp_module* logic to make it available for
holding generic late patching state.
Most of the changes are to pull the module handling logic out
from CONFIG_SMP. In addition now we unconditionally call
alternatives_smp_module_add() and make the decision on patching
for UP or not
Define PVRT* macros which can be used to put pv-ops in
.parainstructions.runtime.
Signed-off-by: Ankur Arora
---
arch/x86/include/asm/paravirt_types.h | 49 +++
1 file changed, 49 insertions(+)
diff --git a/arch/x86/include/asm/paravirt_types.h
b/arch/x86/include/asm/pa
Separate __text_poke() into map, memcpy and unmap portions,
(__text_poke_map(), __text_do_poke() and __text_poke_unmap().)
Do this to separate the non-reentrant bits from the reentrant
__text_do_poke(). __text_poke_map()/_unmap() modify poking_mm,
poking_addr and do the pte-mapping and thus are no
Change in the state of a KVM hint like KVM_HINTS_REALTIME can lead
to significant performance impact. Given that the hint might not be
stable across the lifetime of a guest, dynamic hints allow the host
to inform the guest if the hint changes.
Do this via KVM CPUID leaf in %ecx. If the guest has
KVM pv-ops are dependent on KVM features/hints which are exposed
via CPUID. Decouple the probing and the enabling of these ops from
__init so they can be called post-init as well.
Signed-off-by: Ankur Arora
---
arch/x86/Kconfig | 1 +
arch/x86/kernel/kvm.c | 87
Fix the following sparse warning:
arch/x86/xen/setup.c:998:12: warning: symbol 'xen_pvmmu_arch_setup' was not
declared. Should it be static?
Reported-by: Hulk Robot
Signed-off-by: Jason Yan
---
arch/x86/xen/setup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/xe
flight 149508 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149508/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146182
build-i386-libvirt
88 matches
Mail list logo
