flight 139316 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139316/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 6 kernel-build fail REGR. vs. 129313
Tests which are fail
On Wed, Jul 24, 2019 at 05:53:26PM -0700, christopher.w.cl...@gmail.com wrote:
> From: Christopher Clark
>
> gcc 9.1.0 reports:
>
> | test-cpu-policy.c:64:18: error: '%.12s' directive argument is not a
> nul-terminated string [-Werror=format-overflow=]
> |64 | fail(" Test '%.12
On Wed, Jul 24, 2019 at 05:17:59PM +0100, Anthony PERARD wrote:
> On Tue, Jul 23, 2019 at 11:42:07AM +0200, Roger Pau Monné wrote:
> > On Mon, Jul 22, 2019 at 03:53:19PM +0100, Anthony PERARD wrote:
> > > On Mon, Jul 15, 2019 at 04:15:21PM +0200, Roger Pau Monné wrote:
> > > > On Thu, Jul 04, 2019
On Tue, Jul 23, 2019 at 05:06:04PM +0100, Paul Durrant wrote:
> These are canonical source of data used to set various other flags. If
> they are available directly in struct domain then the other flags are no
> longer needed.
>
> This patch simply copies the flags into a new 'createflags' field i
On Tue, Jul 23, 2019 at 05:06:05PM +0100, Paul Durrant wrote:
> The enum guest_type was introduced in commit 6c6492780ea "pvh prep:
> introduce pv guest type and has_hvm_container macros" to allow a new guest
> type, distinct from either PV or HVM guest types, to be added in commit
> 8271d6522c6 "p
On Tue, Jul 23, 2019 at 05:06:06PM +0100, Paul Durrant wrote:
> -#ifdef CONFIG_HVM
> -#define hap_enabled(d) (is_hvm_domain(d) && (d)->arch.hvm.hap_enabled)
> -#else
> -#define hap_enabled(d) ({(void)(d); false;})
> -#endif
> +#define hap_enabled(d) \
> +(hvm_hap_supported() && is_hvm_domain(
On Tue, Jul 23, 2019 at 05:06:08PM +0100, Paul Durrant wrote:
> This patch introduces a convenience macro, is_xenstore_domain(), which
> tests the domain 'createflags' directly and then uses that in place of
> the 'is_xenstore' flag.
>
> Signed-off-by: Paul Durrant
Reviewed-by: Roger Pau Monné
On Tue, Jul 23, 2019 at 05:06:09PM +0100, Paul Durrant wrote:
> The flag is not needed since the domain 'createflags' can now be tested
> directly.
>
> Signed-off-by: Paul Durrant
Reviewed-by: Roger Pau Monné
___
Xen-devel mailing list
Xen-devel@list
On 25.07.2019 02:53, christopher.w.cl...@gmail.com wrote:
> gcc 9.1.0 reports:
>
> | test-cpu-policy.c:64:18: error: '%.12s' directive argument is not a
> nul-terminated string [-Werror=format-overflow=]
> |64 | fail(" Test '%.12s', expected vendor %u, got %u\n",
> | |
On Thu, Jul 25, 2019 at 11:08:29AM +0200, Roger Pau Monné wrote:
> On Wed, Jul 24, 2019 at 05:17:59PM +0100, Anthony PERARD wrote:
> > On Tue, Jul 23, 2019 at 11:42:07AM +0200, Roger Pau Monné wrote:
> > > On Mon, Jul 22, 2019 at 03:53:19PM +0100, Anthony PERARD wrote:
> > > > On Mon, Jul 15, 2019
> -Original Message-
> From: Roger Pau Monne
> Sent: 25 July 2019 10:44
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Jan Beulich ; Andrew
> Cooper
> ; Wei Liu
> Subject: Re: [PATCH 3/6] x86/hvm/domain: remove the 'hap_enabled' flag
>
> On Tue, Jul 23, 2019 at 05:06:06PM +01
> -Original Message-
> From: Roger Pau Monne
> Sent: 25 July 2019 10:48
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Stefano Stabellini
> ; Wei Liu ;
> Konrad Rzeszutek Wilk ; George Dunlap
> ; Andrew
> Cooper ; Ian Jackson ; Tim
> (Xen.org) ;
> Julien Grall ; Jan Beulich ;
On 24.07.2019 20:19, Andrew Cooper wrote:
> On 24/07/2019 19:02, Oleg Ginzburg wrote:
>> (d2) Booting from Hard Disk...
>> (d2) Booting from :7c00
>> (XEN) d2v0 VMLAUNCH error: 0x7
So this tells us it's the very first insn in the (nested) guest that
causes the failure.
>> (XEN) *** Guest Stat
> -Original Message-
> From: Roger Pau Monne
> Sent: 25 July 2019 10:23
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Stefano Stabellini
> ; Wei Liu ;
> Konrad Rzeszutek Wilk ; George Dunlap
> ; Andrew
> Cooper ; Ian Jackson ; Tim
> (Xen.org) ;
> Julien Grall ; Jan Beulich
> -Original Message-
> From: Tim Deegan
> Sent: 24 July 2019 18:45
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; George Dunlap ;
> Jan Beulich
> ; Andrew Cooper ; Wei Liu
> ; Roger Pau Monne
>
> Subject: Re: [PATCH 4/6] x86/domain: remove the 'oos_off' flag
>
> At 17:06 +01
On 23.07.2019 17:48, Roger Pau Monne wrote:
> Current code only prevent mapping the lapic page into the guest
> physical memory map. Expand the range to be 0xFEEx_ as described
> in the Intel VTd specification section 3.13 "Handling Requests to
> Interrupt Address Range".
>
> AMD also lists th
On 22.07.2019 15:22, Juergen Gross wrote:
> @@ -756,6 +758,7 @@ void load_system_tables(void)
> offsetof(struct tss_struct, __cacheline_filler) - 1,
> SYS_DESC_tss_busy);
>
> +per_cpu(full_gdt_loaded, cpu) = false;
> lgdt(&gdtr);
> lidt(&idtr);
>
On 24.07.2019 19:42, Andrew Cooper wrote:
> This option is hardcoded to 1, and the #ifdef-ary doesn't exclude wakeup.S,
> which makes it useless code noise.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel
On 24.07.2019 19:42, Andrew Cooper wrote:
> dmi_check_system() returns the number of matches. This being nonzero is more
> efficient than calling into a trivial function to modify a variable.
>
> No functional change, but this results in less compiled code, which is
> also (fractionally) quicker
On 25.07.2019 12:11, Paul Durrant wrote:
>> -Original Message-
>> From: Roger Pau Monne
>> Sent: 25 July 2019 10:23
>> To: Paul Durrant
>> Cc: xen-devel@lists.xenproject.org; Stefano Stabellini
>> ; Wei Liu ;
>> Konrad Rzeszutek Wilk ; George Dunlap
>> ; Andrew
>> Cooper ; Ian Jackson ;
On 24.07.2019 19:42, Andrew Cooper wrote:
> All DMI quirks tables are mutable, but are only ever read.
>
> Update dmi_check_system() and dmi_system_id.callback to pass a const pointer,
> and move all quirks tables into __initconst.
I think you need to use __initconstrel throughout.
> No function
On 24.07.2019 19:55, Andrew Cooper wrote:
> This quirk doesn't change anything in Xen, and the web page doesn't exist.
>
> The wayback machine confirms that the link disappeared somewhere between
> 2003-06-14 and 2004-07-07.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
__
On 25/07/2019 11:37, Jan Beulich wrote:
> On 24.07.2019 19:42, Andrew Cooper wrote:
>> All DMI quirks tables are mutable, but are only ever read.
>>
>> Update dmi_check_system() and dmi_system_id.callback to pass a const pointer,
>> and move all quirks tables into __initconst.
> I think you need to
On Thu, Jul 25, 2019 at 10:22:17AM +, Jan Beulich wrote:
> On 23.07.2019 17:48, Roger Pau Monne wrote:
> > Current code only prevent mapping the lapic page into the guest
> > physical memory map. Expand the range to be 0xFEEx_ as described
> > in the Intel VTd specification section 3.13 "Ha
On Thu, Jul 25, 2019 at 11:05:34AM +0100, Anthony PERARD wrote:
> On Thu, Jul 25, 2019 at 11:08:29AM +0200, Roger Pau Monné wrote:
> > On Wed, Jul 24, 2019 at 05:17:59PM +0100, Anthony PERARD wrote:
> > > On Tue, Jul 23, 2019 at 11:42:07AM +0200, Roger Pau Monné wrote:
> > > > On Mon, Jul 22, 2019
> -Original Message-
> From: Jan Beulich
> Sent: 25 July 2019 11:25
> To: Paul Durrant
> Cc: Roger Pau Monne ; Julien Grall
> ; Andrew Cooper
> ; George Dunlap ; Ian
> Jackson
> ; Stefano Stabellini ;
> xen-devel@lists.xenproject.org;
> KonradRzeszutek Wilk ; Tim (Xen.org) ;
> Wei Liu
> -Original Message-
> From: Xen-devel On Behalf Of Roger
> Pau Monné
> Sent: 25 July 2019 11:54
> To: Jan Beulich
> Cc: Andrew Cooper ; xen-devel@lists.xenproject.org
> Subject: Re: [Xen-devel] [PATCH 1/2] x86/iommu: avoid mapping the interrupt
> address range for hwdom
>
> On Thu, Ju
On 25.07.2019 12:46, Andrew Cooper wrote:
> On 25/07/2019 11:37, Jan Beulich wrote:
>> On 24.07.2019 19:42, Andrew Cooper wrote:
>>> All DMI quirks tables are mutable, but are only ever read.
>>>
>>> Update dmi_check_system() and dmi_system_id.callback to pass a const
>>> pointer,
>>> and move all
flight 139328 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139328/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-qcow2 15 guest-start/debian.repeat fail REGR. vs.
139303
Tests which did not
On 25.07.2019 12:54, Roger Pau Monné wrote:
> On Thu, Jul 25, 2019 at 10:22:17AM +, Jan Beulich wrote:
>> On 23.07.2019 17:48, Roger Pau Monne wrote:
>>> Current code only prevent mapping the lapic page into the guest
>>> physical memory map. Expand the range to be 0xFEEx_ as described
>>>
Hi,
Sorry I forgot the CC xen-devel.
On 25/07/2019 13:15, Julien Grall wrote:
Hi all,
I don't have the e-mail address of all the attendees. Feel free to CC/forward to
anyone that should be involved.
First all thank you Artem for taking the notes. I tried to summarize them below.
Please let
On Wed, 2019-07-24 at 17:41 +0200, Roger Pau Monné wrote:
> > > What hardware interface does thermald (or the driver in Linux if
> > > there's one) use to get the temperature data?
In our initial POC using Xen 4.8.x we where using Linux coretemp driver
reading by example /class/sys/hwmon/hwmon0/t
> -Original Message-
> From: Xen-devel On Behalf Of Paul
> Durrant
> Sent: 25 July 2019 11:08
> To: Roger Pau Monne
> Cc: xen-devel@lists.xenproject.org; Wei Liu ; Jan Beulich
> ; Andrew
> Cooper
> Subject: Re: [Xen-devel] [PATCH 3/6] x86/hvm/domain: remove the 'hap_enabled'
> flag
>
On 24.07.2019 11:43, Jan Beulich wrote:
> On 23.07.2019 18:45, Andrew Cooper wrote:
>> On 23/07/2019 17:09, Jan Beulich wrote:
>>> On 23.07.2019 17:48, Roger Pau Monne wrote:
Current code only prevents mapping the io-apic page into the guest
physical memory map. Expand the range to be 0xF
On 25.07.2019 14:44, Fredy P. wrote:
> On Wed, 2019-07-24 at 17:41 +0200, Roger Pau Monné wrote:
What hardware interface does thermald (or the driver in Linux if
there's one) use to get the temperature data?
>
> In our initial POC using Xen 4.8.x we where using Linux coretemp driver
>
On IRC Andrew told me
"I can see why thermal monitoring is useful from dom0, and we should figure out
some way to fix it, but simply undoing that change isn't the right thing to do"
--
Fredy Pulido,
Consultant en logiciel libre
Infrastructure, Infonuagique et architecture de systèmes
Savoir-fair
On Thu, Jul 25, 2019 at 12:54:46PM +, Jan Beulich wrote:
> On 25.07.2019 14:44, Fredy P. wrote:
> > On Wed, 2019-07-24 at 17:41 +0200, Roger Pau Monné wrote:
> What hardware interface does thermald (or the driver in Linux if
> there's one) use to get the temperature data?
> >
> > I
flight 139324 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139324/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt 7 xen-boot fail REGR. vs. 133580
test-amd64-i386-xl-
flight 139334 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139334/
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
On Thu, 2019-07-25 at 15:13 +0200, Roger Pau Monné wrote:
> On Thu, Jul 25, 2019 at 12:54:46PM +, Jan Beulich wrote:
> > On 25.07.2019 14:44, Fredy P. wrote:
> > > On Wed, 2019-07-24 at 17:41 +0200, Roger Pau Monné wrote:
> > > > > > What hardware interface does thermald (or the driver in
> >
flight 139329 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139329/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 0dd8d7d556df46c503254d37b22b2b34f6ad12f6
baseline version:
ovmf 7d0a56c4a125917a474d3
Also introduce a field in struct amd_iommu caching the most recently
written control register. All writes should now happen exclusively from
that cached value, such that it is guaranteed to be up to date.
Take the opportunity and add further fields. Also convert a few boolean
function parameters t
At the same time restrict its scope to just the single source file
actually using it, and abstract accesses by introducing a union of
pointers. (A union of the actual table entries is not used to make it
impossible to [wrongly, once the 128-bit form gets added] perform
pointer arithmetic / array ac
The functions will want to know IOMMU properties (specifically the IRTE
size) subsequently.
Rather than introducing a second error path bogusly returning -E... from
amd_iommu_read_ioapic_from_ire(), also change the existing one to follow
VT-d in returning the raw (untranslated) IO-APIC RTE.
Signe
On Thu, Jul 25, 2019 at 12:47:01PM +, Jan Beulich wrote:
> On 24.07.2019 11:43, Jan Beulich wrote:
> > On 23.07.2019 18:45, Andrew Cooper wrote:
> >> On 23/07/2019 17:09, Jan Beulich wrote:
> >>> On 23.07.2019 17:48, Roger Pau Monne wrote:
> Current code only prevents mapping the io-apic p
In order to be able to express all possible destinations we need to make
use of this non-MSI-capability based mechanism. The new IRQ controller
structure can re-use certain MSI functions, though.
For now general and PPR interrupts still share a single vector, IRQ, and
hence handler.
Signed-off-by
Early enabling (to enter x2APIC mode) requires deferring of the IRQ
setup. Code to actually do that setup in the x2APIC case will get added
subsequently.
Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
Acked-by: Brian Woods
---
v3: Re-base.
--- a/xen/drivers/passthrough/amd/iommu_init.c
+++
In order for the CPUs to use x2APIC mode, the IOMMU(s) first need to be
switched into suitable state.
The post-AP-bringup IRQ affinity adjustment is done also for the non-
x2APIC case, matching what VT-d does.
Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
Acked-by: Brian Woods
---
v4: Re-
Log SBDF headers only when there are actual IRTEs to log. This is
particularly important for the total volume of output when the ACPI
tables describe far more than just the existing devices. On my Rome
system so far there was one line for every function of every device on
all 256 buses of segment 0
First and foremost switch boolean fields to bool. Adjust a few related
function parameters as well. Then
- in amd_iommu_set_intremap_table() don't use literal numbers,
- in iommu_dte_add_device_entry() use a compound literal instead of many
assignments,
- in amd_iommu_setup_domain_device()
-
This also takes care of several of the shift values wrongly having been
specified as hex rather than dec.
Take the opportunity and
- replace a readl() pair by a single readq(),
- add further fields.
Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
---
v4: Drop stray/leftover #undef.
v3: Anoth
The flag is not needed since the domain 'options' can now be tested
directly.
Signed-off-by: Paul Durrant
Reviewed-by: "Roger Pau Monné"
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: Gang Wei
Cc: Shane Wang
---
xen/arch/x86/domain.c| 2 --
xen/arch/x86/tboot.c | 2 +
These are canonical source of data used to set various other flags. If
they are available directly in struct domain then the other flags are no
longer needed.
This patch simply copies the flags into a new 'options' field in
struct domain. Subsequent patches will do the related clean-up work.
Sign
The hap_enabled() macro can determine whether the feature is available
using the domain 'options'; there is no need for a separate flag.
Signed-off-by: Paul Durrant
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: "Roger Pau Monné"
v2:
- Defer changes to shadow_domain_init() to patch #
This series starts with a patch to stash the domain create flags in struct
domain then then follows up with various clean-up patches that this
enables.
Paul Durrant (6):
domain: stash xen_domctl_createdomain flags in struct domain
domain: remove 'guest_type' field (and enum guest_type)
x86/h
The flag is not needed since the domain 'options' can now be tested
directly.
Signed-off-by: Paul Durrant
Acked-by: Tim Deegan
---
Cc: George Dunlap
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: "Roger Pau Monné"
v2:
- Move some of the hunks from patch #3
- Also update the definition
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é"
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
The enum guest_type was introduced in commit 6c6492780ea "pvh prep:
introduce pv guest type and has_hvm_container macros" to allow a new guest
type, distinct from either PV or HVM guest types, to be added in commit
8271d6522c6 "pvh: introduce PVH guest type". Subsequently, commit
33e5c32559e "x86:
This is in preparation of actually enabling x2APIC mode, which requires
this wider IRTE format to be used.
A specific remark regarding the first hunk changing
amd_iommu_ioapic_update_ire(): This bypass was introduced for XSA-36,
i.e. by 94d4a1119d ("AMD,IOMMU: Clean up old entries in remapping
tab
On 25.07.2019 15:34, Roger Pau Monné wrote:
> On Thu, Jul 25, 2019 at 12:47:01PM +, Jan Beulich wrote:
>> On 24.07.2019 11:43, Jan Beulich wrote:
>>> On 23.07.2019 18:45, Andrew Cooper wrote:
On 23/07/2019 17:09, Jan Beulich wrote:
> On 23.07.2019 17:48, Roger Pau Monne wrote:
>>
Mapping the MMIO space and obtaining feature information needs to happen
slightly earlier, such that for x2APIC support we can set XTEn prior to
calling amd_iommu_update_ivrs_mapping_acpi() and
amd_iommu_setup_ioapic_remapping().
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
Acked-by: Br
Flushing didn't get done along the lines of what the specification says.
Mark entries to be updated as not remapped (which will result in
interrupt requests to get target aborted, but the interrupts should be
masked anyway at that point in time), issue the flush, and only then
write the new entry.
On Thu, Jul 25, 2019 at 09:29:01AM -0400, Fredy P. wrote:
> On Thu, 2019-07-25 at 15:13 +0200, Roger Pau Monné wrote:
> > On Thu, Jul 25, 2019 at 12:54:46PM +, Jan Beulich wrote:
> > > On 25.07.2019 14:44, Fredy P. wrote:
> > > > On Wed, 2019-07-24 at 17:41 +0200, Roger Pau Monné wrote:
> > >
On 25.07.2019 15:13, Roger Pau Monné wrote:
> On Thu, Jul 25, 2019 at 12:54:46PM +, Jan Beulich wrote:
>> On 25.07.2019 14:44, Fredy P. wrote:
>>> On Wed, 2019-07-24 at 17:41 +0200, Roger Pau Monné wrote:
>> What hardware interface does thermald (or the driver in Linux if
>> there's
Gang Wei Intel email address has been bouncing for some time now, and
the other maintainer is non-responsive to patches [0], so remove
maintainers and declare INTEL(R) TRUSTED EXECUTION TECHNOLOGY (TXT)
orphaned.
[0] https://lists.xenproject.org/archives/html/xen-devel/2019-05/msg00563.html
Signe
On 25/07/2019 14:51, Roger Pau Monne wrote:
> Gang Wei Intel email address has been bouncing for some time now, and
> the other maintainer is non-responsive to patches [0], so remove
> maintainers and declare INTEL(R) TRUSTED EXECUTION TECHNOLOGY (TXT)
> orphaned.
>
> [0] https://lists.xenproject.o
On Thu, Jul 25, 2019 at 01:33:02PM +, Jan Beulich wrote:
> Flushing didn't get done along the lines of what the specification says.
> Mark entries to be updated as not remapped (which will result in
> interrupt requests to get target aborted, but the interrupts should be
> masked anyway at that
On 25.07.2019 15:47, Roger Pau Monné wrote:
> On Thu, Jul 25, 2019 at 09:29:01AM -0400, Fredy P. wrote:
>> On Thu, 2019-07-25 at 15:13 +0200, Roger Pau Monné wrote:
>>> On Thu, Jul 25, 2019 at 12:54:46PM +, Jan Beulich wrote:
On 25.07.2019 14:44, Fredy P. wrote:
> On Wed, 2019-07-24
On Thu, Jul 25, 2019 at 01:43:34PM +, Jan Beulich wrote:
> On 25.07.2019 15:13, Roger Pau Monné wrote:
> > On Thu, Jul 25, 2019 at 12:54:46PM +, Jan Beulich wrote:
> >> On 25.07.2019 14:44, Fredy P. wrote:
> >>> On Wed, 2019-07-24 at 17:41 +0200, Roger Pau Monné wrote:
> >> What hard
Hi,
On Sat, Jun 8, 2019 at 1:46 AM Amit Singh Tomar wrote:
>
> This series tries to enable XEN booting on i.MX 8MQuad Applications
> Processors[1].
>
> Patch-set includes driver for UART controller found on i.MX8MQ SoC and debug
> code
> for earlyprintk support.
>
Gentle Ping.
Thanks
-Amit
__
On Thu, Jul 25, 2019 at 01:59:22PM +, Jan Beulich wrote:
> On 25.07.2019 15:47, Roger Pau Monné wrote:
> > On Thu, Jul 25, 2019 at 09:29:01AM -0400, Fredy P. wrote:
> >> On Thu, 2019-07-25 at 15:13 +0200, Roger Pau Monné wrote:
> >>> On Thu, Jul 25, 2019 at 12:54:46PM +, Jan Beulich wrote:
On 25/07/2019 15:15, Amit Tomer wrote:
Hi,
Hi,
On Sat, Jun 8, 2019 at 1:46 AM Amit Singh Tomar wrote:
This series tries to enable XEN booting on i.MX 8MQuad Applications
Processors[1].
Patch-set includes driver for UART controller found on i.MX8MQ SoC and debug
code
for earlyprintk supp
--
Fredy Pulido,
Consultant en logiciel libre
Infrastructure, Infonuagique et architecture de systèmes
Savoir-faire Linux, Montréal, Qc
Bureau : (+ 1) 514 276-5468 p.410
Message de confidentialité :
Ce courriel (de même que les fichiers joints) est strictement réservé à
l'usage de la personne ou
On 25.07.2019 16:17, Roger Pau Monné wrote:
> On Thu, Jul 25, 2019 at 01:59:22PM +, Jan Beulich wrote:
>> On 25.07.2019 15:47, Roger Pau Monné wrote:
>>> On Thu, Jul 25, 2019 at 09:29:01AM -0400, Fredy P. wrote:
On Thu, 2019-07-25 at 15:13 +0200, Roger Pau Monné wrote:
> On Thu, Jul
On Thu, Jul 25, 2019 at 02:31:40PM +, Jan Beulich wrote:
> On 25.07.2019 16:17, Roger Pau Monné wrote:
> > On Thu, Jul 25, 2019 at 01:59:22PM +, Jan Beulich wrote:
> >> On 25.07.2019 15:47, Roger Pau Monné wrote:
> >>> On Thu, Jul 25, 2019 at 09:29:01AM -0400, Fredy P. wrote:
> On Th
Hi Juergen,
I've found another regression that happens only with sched-gran=core.
CentOS 5.11 (PV, CPUs: 32; RAM: 6GB) kernel hangs during suspend attempt.
The last kernel messages are:
CPU 1 offline: Remove Rx thread
CPU 2 offline: Remove Rx thread
Kernel: Linux localhost 2.6.18-398.el5
flight 139326 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139326/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 12
guest-start/debianhvm.repeat fail REGR. v
On Thu, 2019-07-25 at 17:34 +0200, Roger Pau Monné wrote:
> On Thu, Jul 25, 2019 at 02:31:40PM +, Jan Beulich wrote:
> > On 25.07.2019 16:17, Roger Pau Monné wrote:
> > > On Thu, Jul 25, 2019 at 01:59:22PM +, Jan Beulich wrote:
> > > > On 25.07.2019 15:47, Roger Pau Monné wrote:
> > > > >
flight 139340 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139340/
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
(cc Intel and tboot-devel)
Hi Roger,
Thanks for your interest in documenting the status of maintenance for Intel TXT
support in Xen. Intel TXT and Xen are deployed in production today by OpenXT
and QubesOS for boot integrity. Xen was a pioneering adopter of DRTM, almost a
decade ago, but mai
Hi Rich,
On 25/07/2019 20:08, Rich Persaud wrote:
> Could you include Lukasz patch, along with Julien's requested formatting
> changes, in your update to the MAINTAINERS file? As a new Xen
> maintainer and contributor, Lukasz may not yet be familiar with the
> procedures and practices of the X
flight 139343 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139343/
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 139331 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139331/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 6 kernel-build fail REGR. vs. 129313
Tests which did not
flight 139335 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139335/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 19 guest-start.2fail REGR. vs. 139300
test-armhf-armhf-
Hey,
openSUSE Tumbleweed has: gcc version 9.1.1 20190703
And this fails to build QEMU, like this:
CC hw/watchdog/wdt_ib700.o
/build/tools/qemu-xen-dir/hw/usb/dev-mtp.c: In function
‘usb_mtp_write_metadata’:
/build/tools/qemu-xen-dir/hw/usb/dev-mtp.c:1715:36: error: taking address of
pac
On Wed, 2019-07-24 at 09:39 +0300, Andrii Anisov wrote:
> From: Andrii Anisov
>
> Fix the comment misprint, so it refers to the exact function name.
>
> Signed-off-by: Andrii Anisov
>
Acked-by: Dario Faggioli
In case it's worth a commit...
Thanks and Regards
--
Dario Faggioli, Ph.D
http://
On Wed, 2019-07-24 at 13:26 +0200, Juergen Gross wrote:
> Today there are two scenarios which are pinning vcpus temporarily to
> a single physical cpu:
>
> - wait_event() handling
> - SCHEDOP_pin_override handling
>
> Each of those cases are handled independently today using their own
> temporary
Hi Roger!
With your patch (and build as a debug build) Xen crashes on boot
(which I guess was the point of your BUG_ON statement).
The log is attached
Thanks,
Roman.
On Wed, Jul 24, 2019 at 7:11 AM Roger Pau Monné wrote:
>
> On Tue, Jul 23, 2019 at 10:32:26AM -0700, Roman Shaposhnik wrote:
> >
Hey, Andy,
openSUSE Tumbleweed has: gcc version 9.1.1 20190703
And this fails to build test-cpu-policy.c, like this:
test-cpu-policy.c: In function ‘main’:
test-cpu-policy.c:64:18: error: ‘%.12s’ directive argument is not a
nul-terminated string [-Werror=format-overflow=]
64 | fa
On 26/07/2019 01:50, Dario Faggioli wrote:
> Hey, Andy,
>
> openSUSE Tumbleweed has: gcc version 9.1.1 20190703
>
> And this fails to build test-cpu-policy.c, like this:
>
> test-cpu-policy.c: In function ‘main’:
> test-cpu-policy.c:64:18: error: ‘%.12s’ directive argument is not a
> nul-terminate
On Wed, Jul 24, 2019 at 10:42 AM Rich Persaud wrote:
>
> On Jul 19, 2019, at 15:31, Roman Shaposhnik wrote:
>
> Hi!
>
> we're using Xen on Advantech ARK-2250 Embedded Box PC:
>
> https://www.elmark.com.pl/web/uploaded/karty_produktow/advantech/ark-2250l/ark-2250l_instrukcja-uzytkownika.pdf
>
On Wed, Jul 24, 2019 at 4:07 AM Julien Grall wrote:
>
> Hi,
>
> On 23/07/2019 18:55, Roman Shaposhnik wrote:
> > It would be great to have Xen running on RPi, but I have to wonder: is
> > it now possible to workaround RPi limitations of how GPU boots?
> > https://www.raspberrypi.org/forums/vie
flight 139338 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139338/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt 7 xen-boot fail REGR. vs. 133580
test-amd64-i386-xl-
If a vCPU is, or is going, offline we want it to be neither
assigned to a pCPU, nor in the wait list, so:
- if an offline vcpu is inserted (or migrated) it must not
go on a pCPU, nor in the wait list;
- if an offline vcpu is removed, we are sure that it is
neither on a pCPU nor in the wait list
vcpu_deassign() is called only once (in _vcpu_remove()).
Let's consolidate the two functions into one.
No functional change intended.
Signed-off-by: Dario Faggioli
Acked-by: George Dunlap
---
xen/common/sched_null.c | 76 ++-
1 file changed, 35 in
Hello,
Here it is v2 of my series, about fixing vcpu off- and on-lining in the
null scheduler, recently reviewed by George.
v1 posting is here:
https://lists.xenproject.org/archives/html/xen-devel/2018-08/msg02182.html
Message-Id: <153515586506.7407.8908626058440527641.st...@palanthas.fritz.box>
When a vcpu that was offline, comes back online, we do want it to either
be assigned to a pCPU, or go into the wait list.
Detecting that a vcpu is coming back online is a bit tricky. Basically,
if the vcpu is waking up, and is neither assigned to a pCPU, nor in the
wait list, it must be coming bac
It is all the time that we call vcpu_deassing() that the vcpu _must_ be
assigned to a pCPU, and hence that such pCPU can't be free.
Therefore, move the ASSERT-s which check for these properties in that
function, where they belong better.
Signed-off-by: Dario Faggioli
Reviewed-by: George Dunlap
From: Zhang Chen
Xen COLO and KVM COLO shared lots of code in Qemu.
KVM COLO has added the iothread support, so we add it on Xen.
Detail:
https://wiki.qemu.org/Features/COLO
Signed-off-by: Zhang Chen
---
tools/libxl/libxl_dm.c | 14 +++---
tools/libxl/libxl_types.idl | 1 +
tool
99 matches
Mail list logo
