> -Original Message-
> From: Igor Druzhinin
> Sent: 28 August 2019 21:40
> To: xen-devel@lists.xenproject.org
> Cc: jbeul...@suse.com; Andrew Cooper ; Paul Durrant
> ; w...@xen.org; Roger Pau Monne
> ; Igor Druzhinin
>
> Subject: [PATCH] x86/domain: don't destroy IOREQ servers on soft
flight 140739 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140739/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 12 guest-start fail REGR. vs. 140282
Tests which did
On Thu, Aug 29, 2019 at 05:02:27PM +0800, Chao Gao wrote:
> Currently, for a HVM on Xen, no reset method is virtualized. So in a VM's
> perspective, assigned devices cannot be reset. But some devices rely on PCI
> reset to recover from hardware hangs. When being assigned to a VM, those
> devices
On 28.08.2019 20:23, Oleksandr wrote:
> --- a/xen/include/xen/xmalloc.h
> +++ b/xen/include/xen/xmalloc.h
> @@ -35,6 +35,18 @@
> #define xzalloc_array(_type, _num) \
> ((_type *)_xzalloc_array(sizeof(_type), __alignof__(_type), _num))
>
> +/* Allocate space for a structure with a flexible
On Thu, Aug 29, 2019 at 11:33:11AM +0200, Jan Beulich wrote:
> On 29.08.2019 10:49, Roger Pau Monne wrote:
> > @@ -640,9 +670,17 @@ p2m_pt_set_entry(struct p2m_domain *p2m, gfn_t gfn_,
> > mfn_t mfn,
> > && (gfn + (1UL << page_order) - 1 > p2m->max_mapped_pfn) )
> >
On 29.08.2019 11:02, Chao Gao wrote:
> Currently, for a HVM on Xen, no reset method is virtualized. So in a VM's
> perspective, assigned devices cannot be reset. But some devices rely on PCI
> reset to recover from hardware hangs. When being assigned to a VM, those
> devices cannot be reset and
On 12. 08. 19, 19:06, Borislav Petkov wrote:
>> + Again, every ``SYM_CODE_START*`` **shall** be coupled by ``SYM_CODE_END``.
>
> Btw, this coupling: I haven't gone through the whole patchset but do we
> have automatic checking which makes sure a starting macro is coupled
> with the correct
On 8/29/19 9:49 AM, Roger Pau Monne wrote:
> This partially reverts commit
> 854a49a7486a02edae5b3e53617bace526e9c1b1 by re-adding the logic that
> propagates changes to the domain physmap done by p2m_pt_set_entry into
> the iommu page tables. Without this logic changes to the guest physmap
> are
Hi, all
+
+static __init int ipmmu_init(struct dt_device_node *node, const void *data)
+{
+int ret;
+
+/*
+ * Even if the device can't be initialized, we don't want to give
+ * the IPMMU device to dom0.
+ */
+dt_device_set_used_by(node, DOMID_XEN);
+
+if (
On 28.08.2019 20:24, Andrew Cooper wrote:
> On 27/08/2019 15:36, Jan Beulich wrote:
>> On 14.08.2019 12:44, Andrew Cooper wrote:
>>> Introduce a new ENDDATA() helper which sets type and size together.
>>
>> Except this isn't very natural: Setting the size late is quite
>> common, to avoid the need
On 29.08.2019 09:15, Chao Gao wrote:
> On Wed, Aug 28, 2019 at 05:12:34PM +0200, Jan Beulich wrote:
>> On 19.08.2019 03:25, Chao Gao wrote:
>>> --- a/xen/arch/x86/microcode_intel.c
>>> +++ b/xen/arch/x86/microcode_intel.c
>>> @@ -134,14 +134,39 @@ static int collect_cpu_info(unsigned int cpu_num,
On Fri, Aug 23, 2019 at 11:09:07AM +0200, Roger Pau Monné wrote:
>On Fri, Aug 23, 2019 at 12:44:34AM +0800, Chao Gao wrote:
>> On Thu, Aug 22, 2019 at 04:10:46PM +0200, Roger Pau Monné wrote:
>> >On Mon, Aug 19, 2019 at 09:25:24AM +0800, Chao Gao wrote:
>> >> Both are loading the cached patch.
> -Original Message-
> From: Roger Pau Monne
> Sent: 23 August 2019 11:56
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Stefano Stabellini
> ; Julien Grall
> ; Volodymyr Babchuk ; Jan
> Beulich
> ; Andrew Cooper ; Wei Liu
> ; Jun Nakajima
> ; Kevin Tian ; George Dunlap
> ;
setup_clear_cpu_cap() is __init and hence may not be called post-boot.
Note that opt_pku nevertheless is not getting __initdata added - see
e.g. commit 43fa95ae6a ("mm: make opt_bootscrub non-init").
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@
On 22.08.2019 15:59, Roger Pau Monné wrote:
> Seeing how this works I'm not sure what's the best option here. As
> updating will be attempted on other CPUs, I'm not sure if it's OK to
> return an error if the update succeed on some CPUs but failed on
> others.
The overall result of a partially
On Tue, Aug 27, 2019 at 05:23:33PM +0200, Jan Beulich wrote:
> On 23.08.2019 07:58, Tian, Kevin wrote:
> > > From: Roger Pau Monne [mailto:roger@citrix.com]
> > > Sent: Tuesday, August 20, 2019 11:38 PM
> > >
> > > The level passed to ept_invalidate_emt corresponds to the EPT entry
> > >
On 29.08.2019 12:20, Paul Durrant wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 29 August 2019 10:52
>> To: Paul Durrant
>> Cc: 'JulienGrall' ; 'Alexandru Isaila'
>> ; 'Petre
>> Pircalabu' ; 'Razvan Cojocaru'
>> ; Andrew Cooper
>> ; George Dunlap ; Ian
>> Jackson
>> ;
On Thu, Aug 29, 2019 at 03:37:47PM +0800, Chao Gao wrote:
> On Fri, Aug 23, 2019 at 11:09:07AM +0200, Roger Pau Monné wrote:
> >On Fri, Aug 23, 2019 at 12:44:34AM +0800, Chao Gao wrote:
> >> On Thu, Aug 22, 2019 at 04:10:46PM +0200, Roger Pau Monné wrote:
> >> >On Mon, Aug 19, 2019 at 09:25:24AM
This partially reverts commit
854a49a7486a02edae5b3e53617bace526e9c1b1 by re-adding the logic that
propagates changes to the domain physmap done by p2m_pt_set_entry into
the iommu page tables. Without this logic changes to the guest physmap
are not propagated to the iommu, leaving stale iommu
Drop the explicit default from all the call sites. This centralises
the default. This is going to be the new scheme for host properties
in general.
(Two of the call sites had a different default, "", which in their
context was semantically equivalent to "bios".)
Signed-off-by: Ian Jackson
---
No semantic change.
Signed-off-by: Ian Jackson
---
mg-hosts | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/mg-hosts b/mg-hosts
index 58b4acc3..d68f7b4e 100755
--- a/mg-hosts
+++ b/mg-hosts
@@ -121,7 +121,14 @@ sub l ($) { return split /,/, $_[0]; }
sub
If one runs
./mg-hosts mknetbootdir HOST
before having sorted out all the host configuration, it uses the
default configuration value for the host's firmware kind, which is
"bios". If the configuration is then changed, things don't work.
This is confusing.
So ask the user to specify one or
On 29.08.2019 09:37, Chao Gao wrote:
> On Fri, Aug 23, 2019 at 11:09:07AM +0200, Roger Pau Monné wrote:
>> On Fri, Aug 23, 2019 at 12:44:34AM +0800, Chao Gao wrote:
>>> On Thu, Aug 22, 2019 at 04:10:46PM +0200, Roger Pau Monné wrote:
On Mon, Aug 19, 2019 at 09:25:24AM +0800, Chao Gao wrote:
Currently, for a HVM on Xen, no reset method is virtualized. So in a VM's
perspective, assigned devices cannot be reset. But some devices rely on PCI
reset to recover from hardware hangs. When being assigned to a VM, those
devices cannot be reset and won't work any longer if a hardware hang
On 29.08.2019 10:00, Roger Pau Monné wrote:
> On Wed, Aug 28, 2019 at 04:24:22PM +0100, Igor Druzhinin wrote:
>> --- a/xen/arch/x86/x86_64/mmconfig-shared.c
>> +++ b/xen/arch/x86/x86_64/mmconfig-shared.c
>> @@ -26,33 +26,34 @@
>>
>> #include "mmconfig.h"
>>
>> +static bool_t __read_mostly
Inspired by Linux commit c49a0a80137c7ca7d6ced4c812c9e07a949f6f24:
There have been reports of RDRAND issues after resuming from suspend on
some AMD family 15h and family 16h systems. This issue stems from a BIOS
not performing the proper steps during resume to ensure RDRAND continues
> -Original Message-
> From: Jan Beulich
> Sent: 27 August 2019 08:46
> To: Paul Durrant
> Cc: JulienGrall ; Alexandru Isaila
> ; Petre Pircalabu
> ; Razvan Cojocaru ;
> Andrew Cooper
> ; George Dunlap ; Ian
> Jackson
> ; Roger Pau Monne ;
> VolodymyrBabchuk
> ; Stefano Stabellini ;
On 28.08.2019 17:24, Igor Druzhinin wrote:
> If MCFG area is not reserved in E820 Xen by default will defer its usage
> until Dom0 registers it explicitly after ACPI parser recognizes it as
> a reserved resource in DSDT. Having it reserved in E820 is not
> mandatory according to "PCI Firmware
On 29/08/2019 10:27, Jan Beulich wrote:
> setup_clear_cpu_cap() is __init and hence may not be called post-boot.
> Note that opt_pku nevertheless is not getting __initdata added - see
> e.g. commit 43fa95ae6a ("mm: make opt_bootscrub non-init").
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew
On 19.08.2019 03:25, Chao Gao wrote:
> @@ -542,29 +505,21 @@ static struct microcode_patch
> *cpu_request_microcode(const void *buf,
> while ( (error = get_ucode_from_buffer_amd(mc_amd, buf, bufsize,
> )) == 0 )
> {
> -struct
On Wed, Aug 28, 2019 at 05:12:34PM +0200, Jan Beulich wrote:
>On 19.08.2019 03:25, Chao Gao wrote:
>> to a more generic function. So that it can be used alone to check
>> an update against the CPU signature and current update revision.
>>
>> Note that enum microcode_match_result will be used in
On Tue, Aug 27, 2019 at 11:59:33AM +0100, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH 2/3] build: allow picking the env values for
> compiler variables"):
> > On 20.08.2019 09:58, Roger Pau Monné wrote:
> > > I don't have things 'left' in the environment, neither have most build
> > >
Hi Oleksandr-san,
> From: Oleksandr Tyshchenko, Sent: Wednesday, August 21, 2019 3:10 AM
>
> From: Oleksandr Tyshchenko
>
> The IPMMU-VMSA is VMSA-compatible I/O Memory Management Unit (IOMMU)
> which provides address translation and access protection functionalities
> to processing units and
> -Original Message-
> From: Jan Beulich
> Sent: 27 August 2019 08:49
> To: Paul Durrant
> Cc: 'JulienGrall' ; 'Alexandru Isaila'
> ; 'Petre
> Pircalabu' ; 'Razvan Cojocaru'
> ; Andrew Cooper
> ; George Dunlap ; Ian
> Jackson
> ; Roger Pau Monne ;
> 'VolodymyrBabchuk'
> ; 'Stefano
On 29.08.2019 10:49, Roger Pau Monne wrote:
> @@ -640,9 +670,17 @@ p2m_pt_set_entry(struct p2m_domain *p2m, gfn_t gfn_,
> mfn_t mfn,
> && (gfn + (1UL << page_order) - 1 > p2m->max_mapped_pfn) )
> p2m->max_mapped_pfn = gfn + (1UL << page_order) - 1;
>
> +if (
On 29.08.2019 11:33, Paul Durrant wrote:
> TBH I've seen sufficient numbers of domain create failures when using
> auto-ballooning that I stopped using it some time ago (besides the fact
> that it's slow). If you're happy with the simplistic
> double-the-page-table-reservation calculation then I
> -Original Message-
> From: Jan Beulich
> Sent: 29 August 2019 10:52
> To: Paul Durrant
> Cc: 'JulienGrall' ; 'Alexandru Isaila'
> ; 'Petre
> Pircalabu' ; 'Razvan Cojocaru'
> ; Andrew Cooper
> ; George Dunlap ; Ian
> Jackson
> ; Roger Pau Monne ;
> 'VolodymyrBabchuk'
> ; 'Stefano
Add the cpu currently holding the lock to struct lock_debug. This makes
analysis of locking errors easier and it can be tested whether the
correct cpu is releasing a lock again.
Signed-off-by: Juergen Gross
---
V2: adjust types (Jan Beulich)
---
xen/common/spinlock.c | 33
Print the lock profile data when the system crashes and add some more
information for each lock data (lock address, cpu holding the lock).
While at it use the PRI_stime format specifier for printing time data.
This is especially beneficial for watchdog triggered crashes in case
of deadlocks.
In
On 19.08.2019 03:25, Chao Gao wrote:
> @@ -300,32 +322,44 @@ int microcode_update(XEN_GUEST_HANDLE_PARAM(const_void)
> buf, unsigned long len)
> if ( microcode_ops == NULL )
> return -EINVAL;
>
> -info = xmalloc_bytes(sizeof(*info) + len);
> -if ( info == NULL )
> +
On 19.08.2019 03:25, Chao Gao wrote:
> +static enum microcode_match_result compare_patch(
> +const struct microcode_patch *new, const struct microcode_patch *old)
> +{
> +return (new->mc_intel->hdr.rev > old->mc_intel->hdr.rev) ? NEW_UCODE :
> +
Instead of enabling debugging for debug builds only add a dedicated
Kconfig option for that purpose which defaults to DEBUG.
Signed-off-by: Juergen Gross
---
V2:
- rename to CONFIG_DEBUG_LOCKS (Jan Beulich)
---
xen/Kconfig.debug | 7 +++
xen/common/spinlock.c | 4 ++--
On 29.08.2019 12:26, Roger Pau Monné wrote:
> On Tue, Aug 27, 2019 at 05:23:33PM +0200, Jan Beulich wrote:
>> On 23.08.2019 07:58, Tian, Kevin wrote:
From: Roger Pau Monne [mailto:roger@citrix.com]
Sent: Tuesday, August 20, 2019 11:38 PM
The level passed to
On 29.08.2019 12:46, Andrew Cooper wrote:
> On 29/08/2019 10:27, Jan Beulich wrote:
>> setup_clear_cpu_cap() is __init and hence may not be called post-boot.
>> Note that opt_pku nevertheless is not getting __initdata added - see
>> e.g. commit 43fa95ae6a ("mm: make opt_bootscrub non-init").
>>
>>
On 27.08.2019 06:52, Chao Gao wrote:
> On Mon, Aug 26, 2019 at 04:07:59PM +0800, Chao Gao wrote:
>> On Fri, Aug 23, 2019 at 09:46:37AM +0100, Sergey Dyasli wrote:
>>> On 19/08/2019 02:25, Chao Gao wrote:
register an nmi callback. And this callback does busy-loop on threads
which are
On 19.08.2019 03:25, Chao Gao wrote:
> @@ -481,12 +478,28 @@ static int do_microcode_update(void *patch)
> return ret;
> }
>
> +static int microcode_nmi_callback(const struct cpu_user_regs *regs, int cpu)
> +{
> +/* The first thread of a core is to load an update. Don't block it. */
>
On 29.08.19 14:27, Jan Beulich wrote:
On 29.08.2019 14:01, Juergen Gross wrote:
On 29.08.19 13:42, Andrew Cooper wrote:
On 29/08/2019 10:28, Jan Beulich wrote:
Inspired by Linux commit c49a0a80137c7ca7d6ced4c812c9e07a949f6f24:
There have been reports of RDRAND issues after resuming
On 29/08/2019 14:13, Jan Beulich wrote:
> On 29.08.2019 12:46, Andrew Cooper wrote:
>> On 29/08/2019 10:27, Jan Beulich wrote:
>>> setup_clear_cpu_cap() is __init and hence may not be called post-boot.
>>> Note that opt_pku nevertheless is not getting __initdata added - see
>>> e.g. commit
On 14/06/2019 12:37, Jan Beulich wrote:
> Aiui when resuming from S3, CPUs come back out of RESET/INIT.
From a programmers point of view, all APs are in Wait-for-SIPI after
resume, and this is confirmed by several of the BWG flowcharts. This is
a logical consequence of the CPU losing all power,
On 22.08.2019 16:02, Alexandru Stefan ISAILA wrote:
> This patch adds access control for NPT mode.
>
> The access rights are stored in the NPT p2m table 56:53.
Why starting from bit 53? I can't seem to find any use of bit 52.
> The bits are free after clearing the IOMMU flags [1].
>
> Modify
On 29.08.2019 14:01, Juergen Gross wrote:
> On 29.08.19 13:42, Andrew Cooper wrote:
>> On 29/08/2019 10:28, Jan Beulich wrote:
>>> Inspired by Linux commit c49a0a80137c7ca7d6ced4c812c9e07a949f6f24:
>>>
>>> There have been reports of RDRAND issues after resuming from suspend on
>>> some
On 19.08.2019 20:26, Andrew Cooper wrote:
> AMD Pre-Fam17h CPUs "optimise" {F,}X{SAVE,RSTOR} by not saving/restoring
> FOP/FIP/FDP if an x87 exception isn't pending. This causes an information
> leak, CVE-2006-1056, and worked around by several OSes, including Xen. AMD
> Fam17h CPUs no longer
On 14/06/2019 12:38, Jan Beulich wrote:
> To "compensate" for the code size growth by an earlier change:
> - drop "trampoline" labels (in almost all cases the target label is
> reachable with an 8-bit-displacement branch anyway, and a single 16-
> bit-displacement branch is still better than a
On 16.08.2019 19:20, Paul Durrant wrote:
> ...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
> diff --git a/xen/test/livepatch/Makefile b/xen/test/livepatch/Makefile
> index 23113d3418..067861903f 100644
> --- a/xen/test/livepatch/Makefile
> +++ b/xen/test/livepatch/Makefile
> @@ -27,6 +27,8 @@ LIVEPATCH_ACTION_HOOKS_NOFUNC :=
> xen_action_hooks_nofunc.livepatch
>
On 29.08.19 13:42, Andrew Cooper wrote:
On 29/08/2019 10:28, Jan Beulich wrote:
Inspired by Linux commit c49a0a80137c7ca7d6ced4c812c9e07a949f6f24:
There have been reports of RDRAND issues after resuming from suspend on
some AMD family 15h and family 16h systems. This issue stems from
The list of suites in ALL_SUITES is in decreasing order of preference:
it gets passed to cs-hosts-list, where the order is significant.
Without this patch, we try to commission hosts by running jessie if
the host flags seem to say jessie would be supported. That's not
really sensible.
CC:
On 16.08.2019 19:19, Paul Durrant wrote:
> ...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
On 16.08.2019 19:19, Paul Durrant wrote:
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -146,6 +146,17 @@ static int __init parse_dom0_iommu_param(const char *s)
> }
> custom_param("dom0-iommu", parse_dom0_iommu_param);
>
> +static void __hwdom_init
On 19.08.2019 03:25, Chao Gao wrote:
> @@ -232,6 +276,34 @@ bool microcode_update_cache(struct microcode_patch
> *patch)
> return true;
> }
>
> +/* Wait for a condition to be met with a timeout (us). */
> +static int wait_for_condition(int (*func)(void *data), void *data,
> +
On 29.08.2019 15:21, Andrew Cooper wrote:
> On 29/08/2019 14:13, Jan Beulich wrote:
>> On 29.08.2019 12:46, Andrew Cooper wrote:
>>> On 29/08/2019 10:27, Jan Beulich wrote:
setup_clear_cpu_cap() is __init and hence may not be called post-boot.
Note that opt_pku nevertheless is not
On 16.08.2019 19:20, Paul Durrant wrote:
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -102,8 +102,10 @@ static int __init parse_iommu_param(const char *s)
> iommu_hwdom_passthrough = val;
> else if ( (val = parse_boolean("dom0-strict",
On 29.08.2019 16:08, Andrew Cooper wrote:
> On 14/06/2019 12:38, Jan Beulich wrote:
>> To "compensate" for the code size growth by an earlier change:
>> - drop "trampoline" labels (in almost all cases the target label is
>> reachable with an 8-bit-displacement branch anyway, and a single 16-
>>
On 14/06/2019 12:37, Jan Beulich wrote:
> In order for "acpi_sleep=s3_mode" to have any effect, we should record
> the video mode we switched to during boot. Since right now there's mode
> setting code for VESA modes only in the resume case, record the mode
> just in that one case.
>
>
flight 140745 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140745/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 140676
Tests which did not
On 29/08/2019 13:39, Juergen Gross wrote:
> On 29.08.19 14:27, Jan Beulich wrote:
>> On 29.08.2019 14:01, Juergen Gross wrote:
>>> On 29.08.19 13:42, Andrew Cooper wrote:
On 29/08/2019 10:28, Jan Beulich wrote:
> Inspired by Linux commit c49a0a80137c7ca7d6ced4c812c9e07a949f6f24:
>
> -Original Message-
> From: Jan Beulich
> Sent: 29 August 2019 14:39
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Julien Grall ;
> Alexandru Isaila
> ; Petre Pircalabu ;
> Razvan Cojocaru
> ; Andrew Cooper ; Roger
> Pau Monne
> ; Volodymyr Babchuk ;
> George Dunlap
> ;
On 29/08/2019 15:23, Jan Beulich wrote:
> On 29.08.2019 16:08, Andrew Cooper wrote:
>> On 14/06/2019 12:38, Jan Beulich wrote:
>>> To "compensate" for the code size growth by an earlier change:
>>> - drop "trampoline" labels (in almost all cases the target label is
>>> reachable with an
On 29.08.2019 16:38, Andrew Cooper wrote:
> On 29/08/2019 15:23, Jan Beulich wrote:
>> On 29.08.2019 16:08, Andrew Cooper wrote:
>>> On 14/06/2019 12:38, Jan Beulich wrote:
@@ -38,9 +38,9 @@ ENTRY(wakeup_start)
movw%ax, %ss# Need this? How to ret if clobbered?
On 29. Aug 2019, at 16:34, Konrad Rzeszutek Wilk
mailto:kon...@darnok.org>> wrote:
…snip...
+
+struct livepatch_func __section(".livepatch.funcs") livepatch_exceptions = {
+.version = LIVEPATCH_PAYLOAD_VERSION,
+.name = livepatch_exceptions_str,
+.new_addr = xen_hello_world,
+
On 19.08.2019 16:26, Julien Grall wrote:
> No functional change intended.
>
> Only reasonable clean-ups are done in this patch. The rest will use _gfn
> for the time being.
>
> The code in get_page_from_gfn is slightly reworked to also handle a bad
> behavior because it is not safe to use
flight 140800 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140800/
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
On 29.08.2019 16:45, Andrew Cooper wrote:
> On 14/06/2019 12:37, Jan Beulich wrote:
>> ---
>> I'm wondering actually whether the user having to explicitly request the
>> mode restoration is a good model: Why would we _not_ want to restore the
>> mode we've set during boot? In the worst case Dom0
On Thu, Aug 29, 2019 at 12:03:44PM +0200, Jan Beulich wrote:
>On 29.08.2019 11:02, Chao Gao wrote:
>> Currently, for a HVM on Xen, no reset method is virtualized. So in a VM's
>> perspective, assigned devices cannot be reset. But some devices rely on PCI
>> reset to recover from hardware hangs.
IS_ERR(), IS_ERR_OR_NULL(), IS_ERR_VALUE() and WARN*() already contain
unlikely() optimization internally. Thus, there is no point in calling
these functions and defines under likely()/unlikely().
This check is based on the coccinelle rule developed by Enrico Weigelt
> -Original Message-
> From: Roger Pau Monne
> Sent: 23 August 2019 15:17
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Ian Jackson ; Wei
> Liu ; Andrew
> Cooper ; George Dunlap ;
> Jan Beulich
> ; Julien Grall ; Konrad Rzeszutek
> Wilk
> ; Stefano Stabellini ; Tim
>
On 23.08.2019 16:16, Andrew Cooper wrote:
> On 19/08/2019 15:26, Julien Grall wrote:
>> diff --git a/xen/include/public/vcpu.h b/xen/include/public/vcpu.h
>> index 3623af932f..dc4c6a72a0 100644
>> --- a/xen/include/public/vcpu.h
>> +++ b/xen/include/public/vcpu.h
>> @@ -182,7 +182,7 @@
> +CODE_GET_EXPECT=$(shell objdump -d --insn-width=1 $(1) | grep -A6 -E
> '<'$(2)'>:' | tail -n +2 | awk 'BEGIN {printf "{"} {printf "0x%s,", $$2}' |
> sed 's/,$$/}/g')
Ony my Hikey 960 when I compile using an native compiler I get:
gcc -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall
On 29. Aug 2019, at 17:58, Konrad Rzeszutek Wilk
mailto:konrad.w...@oracle.com>> wrote:
+CODE_GET_EXPECT=$(shell objdump -d --insn-width=1 $(1) | grep -A6 -E
'<'$(2)'>:' | tail -n +2 | awk 'BEGIN {printf "{"} {printf "0x%s,", $$2}' | sed
's/,$$/}/g')
Ony my Hikey 960 when I compile using an
Hi,
On 29/08/2019 17:41, Jan Beulich wrote:
> On 19.08.2019 16:26, Julien Grall wrote:
>> No functional change intended.
>>
>> Only reasonable clean-ups are done in this patch. The rest will use _gfn
>> for the time being.
>>
>> The code in get_page_from_gfn is slightly reworked to also handle a
> -Original Message-
> From: Jan Beulich
> Sent: 29 August 2019 15:07
> 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
> ;
flight 140757 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140757/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 129313
build-armhf-pvops
"unlikely(WARN(x))" is excessive. WARN() already uses unlikely()
internally.
Signed-off-by: Denis Efremov
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Joe Perches
Cc: Andrew Morton
Cc: xen-devel@lists.xenproject.org
---
drivers/xen/events/events_base.c | 2 +-
1 file changed, 1 insertion(+), 1
On Wed, Aug 28, 2019 at 04:24:22PM +0100, Igor Druzhinin wrote:
> If MCFG area is not reserved in E820 Xen by default will defer its usage
> until Dom0 registers it explicitly after ACPI parser recognizes it as
> a reserved resource in DSDT. Having it reserved in E820 is not
> mandatory according
> -Original Message-
> From: Roger Pau Monne
> Sent: 23 August 2019 11:33
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Ian Jackson ; Wei
> Liu ;
> Anthony Perard ; Andrew Cooper
> ; George Dunlap
> ; Jan Beulich ; Julien Grall
> ;
> Konrad Rzeszutek Wilk ; Stefano
> -Original Message-
> From: Roger Pau Monne
> Sent: 23 August 2019 12:34
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Alexandru Isaila
> ; Stefano Stabellini
> ; Julien Grall ; Volodymyr
> Babchuk
> ; Andrew Cooper ;
> George Dunlap
> ; Ian Jackson ; Jan Beulich
> ;
>
On 29.08.2019 11:49, Roger Pau Monne wrote:
> This partially reverts commit
> 854a49a7486a02edae5b3e53617bace526e9c1b1 by re-adding the logic that
> propagates changes to the domain physmap done by p2m_pt_set_entry into
> the iommu page tables. Without this logic changes to the guest physmap
>
On 19.08.2019 03:25, Chao Gao wrote:
> Both are loading the cached patch. Since APs call the unified function,
> microcode_update_one(), during wakeup, the 'start_update' parameter
> which originally used to distinguish BSP and APs is redundant. So remove
> this parameter.
>
> Signed-off-by: Chao
On 29.08.19 11:37, Yoshihiro Shimoda wrote:
Hi Oleksandr-san,
Hi Shimoda-san.
From: Oleksandr Tyshchenko, Sent: Wednesday, August 21, 2019 3:10 AM
From: Oleksandr Tyshchenko
The IPMMU-VMSA is VMSA-compatible I/O Memory Management Unit (IOMMU)
which provides address translation and
On 29/08/2019 10:28, Jan Beulich wrote:
> Inspired by Linux commit c49a0a80137c7ca7d6ced4c812c9e07a949f6f24:
>
> There have been reports of RDRAND issues after resuming from suspend on
> some AMD family 15h and family 16h systems. This issue stems from a BIOS
> not performing the
+ Boris, Juergen
On Mon, 26 Aug 2019, Christoph Hellwig wrote:
> x86 currently calls alloc_pages, but using dma-direct works as well
> there, with the added benefit of using the CMA pool if available.
> The biggest advantage is of course to remove a pointless bit of
> architecture specific code.
On Tue, 27 Aug 2019, Christoph Hellwig wrote:
> And this was still buggy I think, it really needs some real Xen/Arm
> testing which I can't do. Hopefully better version below:
>
> --
> >From 5ad4b6e291dbb49f65480c9b769414931cbd485a Mon Sep 17 00:00:00 2001
> From: Christoph Hellwig
> Date: Wed,
> Ah, I forgot about endianness of course...
> I am sending an improved patch. I hope it works this time as expected.
Works nicely! (Tested only on ARM64, hadn't tried ARM32 yet).
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
On Mon, 26 Aug 2019, Christoph Hellwig wrote:
> xen_dma_map_page uses a different and more complicated check for foreign
> pages than the other three cache maintainance helpers. Switch it to the
> simpler pfn_valid method a well, and document the scheme with a single
> improved comment in
On Mon, 26 Aug 2019, Christoph Hellwig wrote:
> The only thing left of page-coherent.h is two functions implemented by
> the architecture for non-coherent DMA support that are never called for
> fully coherent architectures. Just move the prototypes for those to
> swiotlb-xen.h instead.
>
>
On Mon, 26 Aug 2019, Christoph Hellwig wrote:
> Now that we know we always have the dma-noncoherent.h helpers available
> if we are on an architecture with support for non-coherent devices,
> we can just call them directly, and remove the calls to the dma-direct
> routines, including the fact that
On Mon, 26 Aug 2019, Christoph Hellwig wrote:
> No need for a no-op wrapper.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Stefano Stabellini
> ---
> drivers/xen/swiotlb-xen.c | 15 ---
> 1 file changed, 4 insertions(+), 11 deletions(-)
>
> diff --git
On Mon, 26 Aug 2019, Christoph Hellwig wrote:
> Now that the Xen special cases are gone nothing worth mentioning is
> left in the arm64 file, so switch to use the
> asm-generic version instead.
>
> Signed-off-by: Christoph Hellwig
> Acked-by: Will Deacon
Reviewed-by: Stefano Stabellini
>
flight 140769 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140769/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 18 guest-start/debianhvm.repeat fail
REGR. vs. 140559
version
On Tue, Aug 27, 2019 at 08:46:23AM +, Pawel Wieczorkiewicz wrote:
> Extend the livepatch list operation to fetch also payloads' metadata.
> This is achieved by extending the sysctl list interface with 2 extra
> guest handles:
> * metadata - an array of arbitrary size strings
> *
1 - 100 of 125 matches
Mail list logo
