flight 140119 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140119/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict broken in
140084
flight 140117 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140117/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 18 guest-localmigrate/x10 fail REGR. vs. 139876
Tests which did
On Thu, 15 Aug 2019, Michael Young wrote:
> This patch may help your issue with the default kernel setting on Fedora 30
> as it uses the setting of saved_entry or next_entry from the grubenv file to
> choose the default kernel which should override any setting picked up from if
> clauses in
This patch may help your issue with the default kernel setting on Fedora
30 as it uses the setting of saved_entry or next_entry from the grubenv
file to choose the default kernel which should override any setting picked
up from if clauses in the grub.cfg file.
I have only done limited and
On Tue, 13 Aug 2019, Julien Grall wrote:
> On 8/12/19 11:28 PM, Stefano Stabellini wrote:
> > Change the signature of process_memory_node to match
> > device_tree_node_func. Thanks to this change, the next patch will be
> > able to use device_tree_for_each_node to call process_memory_node on all
>
On Tue, 13 Aug 2019, Julien Grall wrote:
> On 8/13/19 3:34 PM, Volodymyr Babchuk wrote:
> >
> > Stefano Stabellini writes:
> >
> > > Don't allow reserved-memory regions to be remapped into any unprivileged
> > > guests, until reserved-memory regions are properly supported in Xen. For
> > > now,
On Tue, 13 Aug 2019, Volodymyr Babchuk wrote:
> > @@ -162,6 +156,10 @@ static void __init process_memory_node(const void
> > *fdt, int node,
> > bootinfo.mem.bank[bootinfo.mem.nr_banks].size = size;
> > bootinfo.mem.nr_banks++;
> > }
> > +
> > +if (
On Tue, 13 Aug 2019, Julien Grall wrote:
> Hi,
>
> On 8/13/19 3:28 PM, Volodymyr Babchuk wrote:
> >
> > Stefano Stabellini writes:
> >
> > > Improve early_print_info to also print the banks saved in
> > > bootinfo.reserved_mem. Print them right after RESVD, increasing the same
> > > index.
> >
On Tue, 13 Aug 2019, Volodymyr Babchuk wrote:
> Hi Stefano,
>
> Stefano Stabellini writes:
>
> > Add a new parameter to device_tree_for_each_node: node, the node to
> > start the search from. Passing 0 triggers the old behavior.
> >
> > Set min_depth to depth of the current node + 1 and replace
On Tue, 13 Aug 2019, Julien Grall wrote:
> Hi,
>
> On 8/12/19 11:28 PM, Stefano Stabellini wrote:
> > Add a new parameter to device_tree_for_each_node: node, the node to
> > start the search from. Passing 0 triggers the old behavior.
> >
> > Set min_depth to depth of the current node + 1 and
flight 140106 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140106/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-xl-credit1 1 build-check(1) blocked n/a
test-armhf-armhf-libvirt 1
On Wed, 14 Aug 2019, Julien Grall wrote:
> Hi Oleksandr,
>
> On 13/08/2019 13:35, Oleksandr wrote:
> >
> > On 12.08.19 22:46, Julien Grall wrote:
> > > Hi Oleksandr,
> >
> > Hi, Julien
> >
> >
> > >
> > > On 8/12/19 1:01 PM, Oleksandr wrote:
> > > > On 12.08.19 14:11, Julien Grall wrote:
> >
flight 140108 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140108/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd 4bc76934c5c155105ae508148fec86f5b3513f2a
baseline version:
freebsd
On 14.08.19 20:38, Julien Grall wrote:
Hi Oleksandr,
Hi Julien.
On 02/08/2019 17:39, Oleksandr Tyshchenko wrote:
+static int ipmmu_iommu_domain_init(struct domain *d)
+{
+ struct ipmmu_vmsa_xen_domain *xen_domain;
+
+ xen_domain = xzalloc(struct ipmmu_vmsa_xen_domain);
+ if (
flight 140116 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140116/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 08a54c9e0a3db85d6a9fa7f418a914ea978fecc7
baseline version:
ovmf
flight 140124 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140124/
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
Hi Oleksandr,
On 02/08/2019 17:39, Oleksandr Tyshchenko wrote:
+static int ipmmu_iommu_domain_init(struct domain *d)
+{
+struct ipmmu_vmsa_xen_domain *xen_domain;
+
+xen_domain = xzalloc(struct ipmmu_vmsa_xen_domain);
+if ( !xen_domain )
+return -ENOMEM;
+
+
On Wed, 2019-08-14 at 09:27 -0700, Stefano Stabellini wrote:
> On Wed, 14 Aug 2019, Dario Faggioli wrote:
> > On Tue, 2019-08-13 at 14:14 -0700, Stefano Stabellini wrote:
> > >
> > Now, while staring at the code of that loop, I've seen that
> > pick_cpu()
> > may mess up with the scratch cpumask
Hi Oleksandr,
On 13/08/2019 13:35, Oleksandr wrote:
On 12.08.19 22:46, Julien Grall wrote:
Hi Oleksandr,
Hi, Julien
On 8/12/19 1:01 PM, Oleksandr wrote:
On 12.08.19 14:11, Julien Grall wrote:
On 02/08/2019 17:39, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
This patch
On Tue, Aug 13, 2019 at 10:32:00AM +0300, Oleksandr Andrushchenko wrote:
>
> On 8/13/19 9:27 AM, Nishka Dasgupta wrote:
> > Static structure fb_funcs, of type drm_framebuffer_funcs, is used only
> > when it is passed to drm_gem_fb_create_with_funcs() as its last
> > argument.
> -Original Message-
> From: Julien Grall
> Sent: 14 August 2019 18:15
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Ian Jackson ; Wei Liu ; Anthony
> Perard
> ; Andrew Cooper ;
> George Dunlap
> ; Jan Beulich ; Konrad Rzeszutek
> Wilk
> ; Stefano Stabellini ; Tim
>
flight 140097 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140097/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail in 140072 REGR.
vs. 139698
Tests
On Wed, 2019-08-14 at 17:15 +0100, George Dunlap wrote:
> On Fri, Aug 2, 2019 at 2:08 PM Juergen Gross wrote:
> > --- a/xen/common/cpupool.c
> > +++ b/xen/common/cpupool.c
> > @@ -762,18 +762,28 @@ static struct notifier_block cpu_nfb = {
> > .notifier_call = cpu_callback
> > };
> >
> >
On Wed, 14 Aug 2019, Dario Faggioli wrote:
> On Tue, 2019-08-13 at 14:14 -0700, Stefano Stabellini wrote:
> > On Tue, 13 Aug 2019, Dario Faggioli wrote:
> > >
> > > I am attaching an updated debug patch, with an additional printk
> > > when
> > > we reach the point, within the null scheduler,
On Fri, Aug 2, 2019 at 2:08 PM Juergen Gross wrote:
>
> With core or socket scheduling we need to know the number of siblings
> per scheduling unit before we can setup the scheduler properly. In
> order to prepare that do cpupool0 population only after all cpus are
> up.
>
> With that in place
flight 140074 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140074/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-amd64 broken
test-amd64-i386-examine 8 reboot
flight 140093 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140093/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 129313
build-armhf-pvops
flight 140094 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140094/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 139829
build-i386-libvirt
On 7/16/19 1:01 PM, Alexandru Stefan ISAILA wrote:
> At this moment IOMMU pt sharing is disabled by commit [1].
>
> This patch aims to clear the IOMMU hap share support as it will not be
> used in the future. By doing this the IOMMU bits used in pte[52:58] can
> be used in other ways.
>
> [1]
> -Original Message-
> From: Julien Grall
> Sent: 14 August 2019 15:00
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Ian Jackson ; Wei Liu ; Anthony
> Perard
> ; Andrew Cooper ;
> George Dunlap
> ; Jan Beulich ; Konrad Rzeszutek
> Wilk
> ; Stefano Stabellini ; Tim
>
flight 140112 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140112/
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
Hi Paul,
On 14/08/2019 14:38, Paul Durrant wrote:
This patch introduces a common domain creation flag to determine whether
the domain is permitted to make use of the IOMMU. Currently the flag is
always set (for both dom0 and domU) if the IOMMU is globally enabled
(i.e. iommu_enabled == 1).
...and hence the ability to disable IOMMU mappings, and control EPT
sharing.
This patch introduces a new 'libxl_passthrough' enumeration into
libxl_domain_create_info. The value will be set by xl either when it parses
a new 'passthrough' option in xl.cfg, or implicitly if there is passthrough
The hap_enabled() macro can determine whether the feature is available
using the domain 'options'; there is no need for a separate flag.
NOTE: Furthermore, by extending sanitiziing of the domain 'options', the
macro can be transformed into an inline function and re-located to
Now that there is a per-domain IOMMU enable flag, which should be enabled if
any device is going to be passed through, stop deferring page table
construction until the assignment is done. Also don't tear down the tables
again when the last device is de-assigned; defer that task until domain
The flag is not needed since the domain 'options' can now be tested
directly.
Signed-off-by: Paul Durrant
Reviewed-by: "Roger Pau Monné"
Reviewed-by: Jan Beulich
---
Cc: Andrew Cooper
Cc: Wei Liu
v4:
- s/TBOOT/CONFIG_TBOOT/g
v3:
- Also sanitise the flag against CONFIG_TBOOT being set
---
This patch introduces a convenience macro, is_xenstore_domain(), which
tests the domain 'options' directly and then uses that in place of
the 'is_xenstore' flag.
Signed-off-by: Paul Durrant
Reviewed-by: "Roger Pau Monné"
Acked-by: George Dunlap
---
Cc: Andrew Cooper
Cc: Ian Jackson
Cc: Jan
Thes macros really ought to live in the common xen/iommu.h header rather
then being distributed amongst architecture specific iommu headers and
xen/sched.h. This patch moves them there.
NOTE: Disabling 'sharept' in the command line iommu options should really
be hard error on ARM (as
...rather than testing the global iommu_enabled flag and ops pointer.
Now that there is a per-domain flag indicating whether the domain is
permitted to use the IOMMU (which determines whether the ops pointer will
be set), many tests of the global iommu_enabled flag and ops pointer can
be
...and add per-domain IOMMU control
This is a combination of my previously separate series [1] and [2].
[1] https://lists.xenproject.org/archives/html/xen-devel/2019-07/msg02253.html
[2] https://lists.xenproject.org/archives/html/xen-devel/2019-07/msg02267.html
Paul Durrant (10):
The flag is not needed since the domain 'options' can now be tested
directly.
Signed-off-by: Paul Durrant
Reviewed-by: Jan Beulich
---
Cc: Tim Deegan
Cc: George Dunlap
Cc: Andrew Cooper
Cc: Wei Liu
Cc: "Roger Pau Monné"
v3:
- Force 'oos_off' to be set for PV guests (to avoid call to
This function is only ever called from within the same source module and
really has no business being declared xen/iommu.h. This patch relocates
the function ahead of the first called and makes it static.
Signed-off-by: Paul Durrant
Acked-by: Jan Beulich
---
Previously part of series
This patch introduces a common domain creation flag to determine whether
the domain is permitted to make use of the IOMMU. Currently the flag is
always set (for both dom0 and domU) if the IOMMU is globally enabled
(i.e. iommu_enabled == 1). sanitise_domain_config() is modified to reject
the flag
flight 140084 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140084/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrictbroken
On 14/08/2019 00:16, Sander Eikelenboom wrote:
> On 13/08/2019 23:05, Andrew Cooper wrote:
>> On 13/08/2019 22:03, Sander Eikelenboom wrote:
>>> On 13/08/2019 15:31, Andrew Cooper wrote:
On 13/08/2019 12:51, Sander Eikelenboom wrote:
> On 13/08/2019 13:21, Andrew Cooper wrote:
>> On
On 14/08/2019 13:51, George Dunlap wrote:
> On 8/7/19 5:03 PM, Jan Beulich wrote:
>> Whatever we do in Xen, it'll only allow to work around that issue.
>> An actual fix belongs in the kernel(s). For this reason I suppose
>> what we're talking about here is a feature (from Xen's pov), not a
>> bug
flight 140088 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140088/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 139876
Tests which did
Hi Stefano,
On 12/08/2019 23:28, Stefano Stabellini wrote:
Improve early_print_info to also print the banks saved in
bootinfo.reserved_mem. Print them right after RESVD, increasing the same
index.
Since we are at it, also switch the existing RESVD print to use unsigned
int.
Signed-off-by:
On 8/7/19 5:03 PM, Jan Beulich wrote:
> Whatever we do in Xen, it'll only allow to work around that issue.
> An actual fix belongs in the kernel(s). For this reason I suppose
> what we're talking about here is a feature (from Xen's pov), not a
> bug fix. And it being a feature, it should
Hi Stefano,
On 12/08/2019 23:28, Stefano Stabellini wrote:
As we parse the device tree in Xen, keep track of the reserved-memory
regions as they need special treatment (follow-up patches will make use
of the stored information.)
Reuse process_memory_node to add reserved-memory regions to the
> -Original Message-
[snip]
> >>> +/* Are we using the domain P2M table as its IOMMU pagetable? */
> >>> +#define iommu_use_hap_pt(d) \
> >>> +(hap_enabled(d) && is_iommu_enabled(d) && iommu_hap_pt_share)
> >>
> >> Does this build for Arm, seeing that there's no
Hi,
On 14/08/2019 12:11, Paul Durrant wrote:
-Original Message-
From: Julien Grall
Sent: 14 August 2019 11:45
To: Paul Durrant ; 'Jan Beulich'
Cc: xen-devel@lists.xenproject.org; Andrew Cooper ;
Roger Pau Monne
; Volodymyr Babchuk ; George
Dunlap
; Ian Jackson ; Stefano
Stabellini
A lot of legitimate error messages were hidden behind debug printk
only. Most of these messages can be triggered by loading a malformed
hotpatch payload and are priceless for understanding issues with such
payloads.
Thus, always display all relevant XENLOG_ERR messages.
Signed-off-by: Pawel
On Tue, Aug 13, 2019 at 11:53:50AM +0100, Andrew Cooper wrote:
> These domctls exist to work around bugs in obsolete 32bit PV guests. They are
> no longer useful.
>
> Andrew Cooper (2):
> xen: Drop XEN_DOMCTL_suppress_spurious_page_faults
> xen: Drop XEN_DOMCTL_{get,set}_machine_address_size
> On 13 Aug 2019, at 11:53, Andrew Cooper wrote:
>
> This functionality is obsolete. It was introduced by c/s 41296317a31 into
> Xend, but was never exposed in libxl.
>
> Nothing limits this to PV guests, but it makes no sense for HVM guests.
>
> Looking through the XenServer templates,
With default implementation the ELF_LIVEPATCH_FUNC section containing
all functions to be replaced or added must be part of the hotpatch
payload, otherwise the payload is rejected (with -EINVAL).
However, with the extended hooks implementation, a hotpatch may be
constructed of only hooks to
On 14/08/2019 13:00, Wei Liu wrote:
> On Wed, Aug 14, 2019 at 11:44:04AM +0100, Andrew Cooper wrote:
> [...]
>> diff --git a/xen/include/asm-x86/config.h b/xen/include/asm-x86/config.h
>> index 22dc795eea..35705441ff 100644
>> --- a/xen/include/asm-x86/config.h
>> +++
On Wed, Aug 14, 2019 at 11:44:04AM +0100, Andrew Cooper wrote:
[...]
> diff --git a/xen/include/asm-x86/config.h b/xen/include/asm-x86/config.h
> index 22dc795eea..35705441ff 100644
> --- a/xen/include/asm-x86/config.h
> +++ b/xen/include/asm-x86/config.h
> @@ -56,6 +56,11 @@
> #define
In the process of creating a final hotpatch module file make sure to
strip all transient symbols that have not been caught and removed by
create-diff-object processing. For now these are only the hooks
kpatch load/unload symbols.
For all new object files that are carried along for the final
Strip all unneeded metadata symbols from generated hotpatch modules.
The metadata symbols are the symbols from metadata-like sections (e.g.
'.livepatch.funcs') or livepatch hooks symbols (defined by a set of
prefixes. E.g. 'livepatch_load_data_').
By default the create-diff-object does not create
flight 140089 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140089/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 46f8a6891606746ca8b1e684ac379ce271306dc0
baseline version:
ovmf
This is the initial implementation of the expectations enhancement
to improve inline asm hotpatching.
Expectations are designed as optional feature, since the main use of
them is planned for inline asm hotpatching. The flag enabled allows
to control the expectation state.
Each expectation has
Extend livepatch_patch_func to support a new field: expect. This new
field describes the expected data, its length and whether expectation
is enabled. The expectation's data is of opaque padding size.
Bump the payload version for hotpatches built with expectations.
The expectations are supported
Hi Julien,
Julien Grall writes:
> Commit af156ff085 "xen/arm: types: Specify the zero padding in the
> definition of PRIregister" moved the zero padding within the definition
> of PRIregister.
>
> However, some of the users still had zero padding before which result
> to print tens of zero when
On 13/08/2019 22:02, YOUNG, MICHAEL A. wrote:
> I have been looking at the pygrub code to see if it is possible to cope
> with grub files with BLSCFG and spotted this minor issue in GrubConf.py
> where the code intends to replace ${saved_entry} and ${next_entry} with 0
> but doesn't succeed.
>
> -Original Message-
> From: Julien Grall
> Sent: 14 August 2019 11:45
> To: Paul Durrant ; 'Jan Beulich'
> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
> ; Roger Pau Monne
> ; Volodymyr Babchuk ;
> George Dunlap
> ; Ian Jackson ; Stefano
> Stabellini
> ; Konrad Rzeszutek Wilk ;
Hi,
On 14/08/2019 11:27, Paul Durrant wrote:
-Original Message-
From: Julien Grall
Sent: 14 August 2019 11:21
To: Paul Durrant ; 'Jan Beulich'
Cc: xen-devel@lists.xenproject.org; Andrew Cooper ;
Roger Pau Monne
; Volodymyr Babchuk ; George
Dunlap
; Ian Jackson ; Stefano
Stabellini
Introduce a new ENDDATA() helper which sets type and size together.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/boot/x86_64.S | 18 +-
xen/include/asm-x86/config.h | 5 +
2 files changed, 14 insertions(+), 9
> -Original Message-
> From: Jan Beulich
> Sent: 07 August 2019 13:13
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Julien Grall ;
> Andrew Cooper
> ; Anthony Perard ;
> Roger Pau Monne
> ; Volodymyr Babchuk ;
> George Dunlap
> ; Ian Jackson ; Stefano
> Stabellini
> ;
On Tue, Aug 13, 2019 at 03:21:28PM +0100, Andrew Cooper wrote:
> When compiling xenstat with -Werror, Clang complains:
>
> src/xenstat.c:134:34: error: unused function 'parse'
> [-Werror,-Wunused-function]
> static inline unsigned long long parse(char *s, char *match)
>
On Tue, Aug 13, 2019 at 01:01:17PM +0100, Andrew Cooper wrote:
> Clang-3.5 from Debian Jessie fails with:
>
> smpboot.c:829:29: error: statement expression not allowed at file scope
> BUILD_BUG_ON(sizeof(this_cpu(tss_page)) != PAGE_SIZE);
> ^
>
On Tue, Aug 13, 2019 at 02:52:11PM +0100, Andrew Cooper wrote:
> Building with GCC 8.3 on Buster identifies:
>
> src/xenstat_linux.c: In function 'xenstat_collect_networks':
> src/xenstat_linux.c:307:32: warning: 'snprintf' output may be truncated
> before
> the last format character
> -Original Message-
> From: Julien Grall
> Sent: 14 August 2019 11:21
> To: Paul Durrant ; 'Jan Beulich'
> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
> ; Roger Pau Monne
> ; Volodymyr Babchuk ;
> George Dunlap
> ; Ian Jackson ; Stefano
> Stabellini
> ; Konrad Rzeszutek Wilk ;
Hi Paul,
On 14/08/2019 11:13, Paul Durrant wrote:
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -268,6 +268,13 @@ struct domain_iommu {
#define iommu_set_feature(d, f) set_bit(f, dom_iommu(d)->features)
#define iommu_clear_feature(d, f) clear_bit(f,
Hi,
On 07/08/2019 13:57, Viktor Mitin wrote:
Functions make_timer_node and make_timer_domU_node are quite similar,
so it is better to consolidate them to avoid discrepancy.
This patch series achives this goal in two steps:
- Extend fdt_property_interrupts to deal with other domain than the
> -Original Message-
> From: Jan Beulich
> Sent: 07 August 2019 11:41
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Julien Grall ;
> Andrew Cooper
> ; Roger Pau Monne ;
> Volodymyr Babchuk
> ; George Dunlap ; Ian
> Jackson
> ; Stefano Stabellini ; Konrad
> Rzeszutek Wilk
>
flight 140105 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140105/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 243cc95d485846e35f5e2445fdaafe77c8c114d2
baseline version:
xen
> -Original Message-
> From: Jan Beulich
> Sent: 06 August 2019 16:54
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org
> Subject: Re: [PATCH 4/6] make passthrough/pci.c:deassign_device() static
>
> On 30.07.2019 15:44, Paul Durrant wrote:
> > This function is only ever called
On 8/9/19 4:40 PM, Jan Beulich wrote:
> Commit fd35f32b4b ("tools/x86emul: Use struct cpuid_policy in the
> userspace test harnesses") didn't account for the dependencies of
> cpuid-autogen.h to potentially change between incremental builds. In
> particular the harness has a "run" goal which is
> -Original Message-
> From: Xen-devel On Behalf Of Paul
> Durrant
> Sent: 12 August 2019 17:26
> To: 'Jan Beulich'
> Cc: 'Petre Pircalabu' ; 'Stefano Stabellini'
> ;
> 'Wei Liu' ; 'Razvan Cojocaru' ;
> 'Konrad Rzeszutek Wilk'
> ; Andrew Cooper ; Tim
> (Xen.org) ;
> George Dunlap ;
Commit af156ff085 "xen/arm: types: Specify the zero padding in the
definition of PRIregister" moved the zero padding within the definition
of PRIregister.
However, some of the users still had zero padding before which result
to print tens of zero when dumping the CPU state.
To prevent this,
By default, in the quiescing zone, a hotpatch payload is applied with
apply_payload() and reverted with revert_payload() functions. Both of
the functions receive the payload struct pointer as a parameter. The
functions are also a place where standard 'load' and 'unload' module
hooks are executed.
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemut-win7-amd64
testid xen-boot
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf
Livepatch only tracks an entire payload applied/reverted state. But,
with an option to supply the apply_payload() and/or revert_payload()
functions as optional hooks, it becomes possible to intermix the
execution of the original apply_payload()/revert_payload() functions
with their dynamically
With version 2 of a payload structure additional field is supported
to track whether given function has been applied or reverted.
There also comes additional 8-byte alignment padding to reserve
place for future flags and options.
The new fields are zero-out upon .livepatch.funcs section creation.
Include new sections containing optional apply and revert action
hooks.
The following new section names are supported:
- .livepatch.hooks.apply
- .livepatch.hooks.revert
Signed-off-by: Pawel Wieczorkiewicz
---
create-diff-object.c | 10 ++
1 file changed, 10 insertions(+)
diff
On Tue, Aug 13, 2019 at 12:24:32PM -0700, Roman Shaposhnik wrote:
> Hi Roger,
>
> sorry for the delay -- I hope you will understand that I actually had
> a good reason. See below:
No problem, just wanted to make sure this doesn't fell through the
cracks.
> On Mon, Aug 12, 2019 at 1:57 AM Roger
This is an implementation of 4 new livepatch module vetoing hooks,
that can be optionally supplied along with modules.
Hooks that currently exists in the livepatch mechanism aren't agile
enough and have various limitations:
* run only from within a quiescing zone
* cannot conditionally prevent
The payload structure will be used by the new hooks implementation and
therefore its definition has to be exported via the livepatch_payload
header.
The new hooks will make use of the payload structure fields and the
hooks' pointers will also be defined in the payload structure, so
the structure
On Wed, Aug 14, 2019 at 09:51:45AM +0200, Olaf Hering wrote:
> On Wed, May 15, Olaf Hering wrote:
>
> > Am Mon, 13 May 2019 17:20:05 +0200
> > schrieb Roger Pau Monné :
> >
> > > Let me know if that works for you and I will submit it formally.
> > Yes, it works for me. Thanks.
>
> Did you have
Include new sections containing optional pre-, post- action hooks.
The following new section names are supported:
- .livepatch.hooks.preapply
- .livepatch.hooks.postapply
- .livepatch.hooks.prerevert
- .livepatch.hooks.postrevert
Signed-off-by: Pawel Wieczorkiewicz
---
On Wed, May 15, Olaf Hering wrote:
> Am Mon, 13 May 2019 17:20:05 +0200
> schrieb Roger Pau Monné :
>
> > Let me know if that works for you and I will submit it formally.
> Yes, it works for me. Thanks.
Did you have a chance to submit a fix to support '--disable-pv-shim'?
Olaf
signature.asc
92 matches
Mail list logo
