flight 134252 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134252/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken
build-arm64
flight 134286 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134286/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64
flight 134368 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134368/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-xs
flight 134283 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134283/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-pvops
flight 134248 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134248/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-pvops
flight 134360 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134360/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-xs
> On Apr 3, 2019, at 12:33 PM, Anthony PERARD wrote:
>
> One particularity of Arch Linux, /usr/bin/python is python3.
>
> Signed-off-by: Anthony PERARD
Acked-by: Doug Goldstein
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-examine
testid reboot
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tre
flight 134279 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134279/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken
build-arm64-xsm
flight 134354 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134354/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-xs
This run is configured for baseline tests only.
flight 83865 ovmf real [real]
http://osstest.xensource.com/osstest/logs/83865/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm
These were made redundant by c/s 23058e7b3 "x86/shadow: put PV L1TF functions
under CONFIG_PV" but makes the code read as if outside of the ifdef.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/include/asm-x86/shadow.h | 4 ++--
1 file changed, 2 inse
On 13/03/2019 12:38, Jan Beulich wrote:
> When there's no XPTI-enabled PV domain at all, there's no need to issue
> respective TLB flushes. Hardwire opt_xpti_* to false when !PV, and
> record the creation of PV domains by bumping opt_xpti_* accordingly.
>
> Signed-off-by: Jan Beulich
> ---
> TBD:
On 13/03/2019 12:39, Jan Beulich wrote:
> While the mere updating of ->pv_cr3 and ->root_pgt_changed aren't overly
> expensive (but still needed only for the toggle_guest_mode() path), the
> effect of the latter on the exit-to-guest path is not insignificant.
> Move the logic into toggle_guest_mode
On 13/03/2019 12:38, Jan Beulich wrote:
> Instead of the separate iommu_ret, the general rc can be used even for
> the IOMMU operations.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.or
On 13/03/2019 12:38, Jan Beulich wrote:
> In a few cases only a query is intended, i.e. without populating a
> possible PoD or paged out entry, when the intention is to replace the
> current entry anyway. Use get_gfn_query() there instead.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
"amd-iommu: use a bitfield for DTE" renamed iommu_dte_set_guest_cr3()'s gcr3
parameter to gcr3_mfn but ended up with an off-by-PAGE_SIZE error when
extracting bits from the address.
First of all, get_guest_cr3_from_dte() and iommu_dte_set_guest_cr3()
are (almost) getters and setters for the same f
On 4/3/19 7:04 PM, Jan Beulich wrote:
On 03.04.19 at 17:48, wrote:
>> On 4/3/19 6:30 PM, Jan Beulich wrote:
>> On 03.04.19 at 17:17, wrote:
Changes to the hostp2m (also known as altp2m view 0) propagate to all
existing altp2ms, but they do so in a lazy manner, and also that won
One particularity of Arch Linux, /usr/bin/python is python3.
Signed-off-by: Anthony PERARD
---
Notes:
v2:
- Add the gitlab build stuff
- update containerize with new shortcut
- This time, the container is already pushed to the registry
one pipeline with the archlinux-* jobs:
On Wed, Apr 3, 2019 at 11:08 AM Razvan Cojocaru
wrote:
>
> On 4/3/19 7:16 PM, Tamas K Lengyel wrote:
> > It is right to fully populate a slot when for example we want
> > different mem_access permissions in different altp2m views. We can't
> > wait for the domain to on-demand populate the altp2m v
On 4/3/19 7:16 PM, Tamas K Lengyel wrote:
> It is right to fully populate a slot when for example we want
> different mem_access permissions in different altp2m views. We can't
> wait for the domain to on-demand populate the altp2m view because we
> don't know when (and if) that will actually happe
On Wed, Apr 03, 2019 at 05:26:45PM +0100, Anthony PERARD wrote:
> On Wed, Apr 03, 2019 at 05:19:10PM +0100, Wei Liu wrote:
> > On Wed, Apr 03, 2019 at 05:05:17PM +0100, Anthony PERARD wrote:
> > > Signed-off-by: Anthony PERARD
> >
> > Have you pushed the container to xen project's registry? If so
On Wed, Apr 03, 2019 at 05:19:10PM +0100, Wei Liu wrote:
> On Wed, Apr 03, 2019 at 05:05:17PM +0100, Anthony PERARD wrote:
> > Signed-off-by: Anthony PERARD
>
> Have you pushed the container to xen project's registry? If so, can you
I haven't, no.
> confirm it runs ok?
It works for me :-). You
On Wed, Apr 03, 2019 at 05:05:17PM +0100, Anthony PERARD wrote:
> Signed-off-by: Anthony PERARD
Have you pushed the container to xen project's registry? If so, can you
confirm it runs ok?
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
On Wed, Apr 3, 2019 at 10:06 AM Jan Beulich wrote:
>
> >>> On 03.04.19 at 17:48, wrote:
> > On 4/3/19 6:30 PM, Jan Beulich wrote:
> > On 03.04.19 at 17:17, wrote:
> >>> Changes to the hostp2m (also known as altp2m view 0) propagate to all
> >>> existing altp2ms, but they do so in a lazy mann
Signed-off-by: Anthony PERARD
---
automation/build/archlinux/current.dockerfile | 52 +++
1 file changed, 52 insertions(+)
create mode 100644 automation/build/archlinux/current.dockerfile
diff --git a/automation/build/archlinux/current.dockerfile
b/automation/build/archlinux/cu
>>> On 03.04.19 at 17:48, wrote:
> On 4/3/19 6:30 PM, Jan Beulich wrote:
> On 03.04.19 at 17:17, wrote:
>>> Changes to the hostp2m (also known as altp2m view 0) propagate to all
>>> existing altp2ms, but they do so in a lazy manner, and also that won't
>>> happen for altp2ms created after a w
flight 134327 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134327/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-xs
On 4/3/19 6:30 PM, Jan Beulich wrote:
On 03.04.19 at 17:17, wrote:
Changes to the hostp2m (also known as altp2m view 0) propagate to all
existing altp2ms, but they do so in a lazy manner, and also that won't
happen for altp2ms created after a while. So altp2ms will not
necessarily know about a
>>> On 03.04.19 at 17:21, wrote:
> On 2019/4/3 0:15, Jan Beulich wrote:
>> On 02.04.19 at 18:00, wrote:
>>> On 2019/4/2 23:14, Andrew Cooper wrote:
On 30/03/2019 10:40, Pu Wen wrote:
> This patch series have been applied and tested successfully on Hygon
> Dhyana processor, also been
On 2019/4/3 18:22, Jan Beulich wrote:
On 03.04.19 at 12:05, wrote:
I'm a little confused about which style to follow? In v3 series I
followed the style of the derived code. But in other patch you told me
to follow the Xen coding style, so in v4 series I changed the style to
match the bracing se
> On Apr 3, 2019, at 3:52 PM, Alexandru Stefan ISAILA
> wrote:
>
> Hi all,
>
> I came across some code in the p2m_set_altp2m_mem_access() that does not
> seem right. On the invalid mfn branch there is a try to set_entry() and
> if that is not successful then the function does not return and
>>> On 03.04.19 at 17:17, wrote:
> On 4/3/19 5:58 PM, Jan Beulich wrote:
> On 03.04.19 at 16:29, wrote:
>>> --- a/xen/arch/x86/mm/p2m.c
>>> +++ b/xen/arch/x86/mm/p2m.c
>>> @@ -3011,8 +3011,16 @@ int p2m_set_suppress_ve(struct domain *d, gfn_t gfn,
>>> bool suppress_ve,
>>> mfn = p2m->g
On 2019/4/3 0:15, Jan Beulich wrote:
> On 02.04.19 at 18:00, wrote:
>> On 2019/4/2 23:14, Andrew Cooper wrote:
>>> On 30/03/2019 10:40, Pu Wen wrote:
This patch series have been applied and tested successfully on Hygon
Dhyana processor, also been tested on AMD EPYC (family 17h) processor
>>> On 03.04.19 at 16:44, wrote:
> On 03/04/2019 13:43, Jan Beulich wrote:
> On 03.04.19 at 13:14, wrote:
>>> On 03/04/2019 11:12, Jan Beulich wrote:
>>> On 01.08.18 at 16:22, wrote:
> When putting CPUs to sleep permanently, we should try to put them into
> the most power conserv
On 4/3/19 5:58 PM, Jan Beulich wrote:
On 03.04.19 at 16:29, wrote:
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -3011,8 +3011,16 @@ int p2m_set_suppress_ve(struct domain *d, gfn_t gfn,
bool suppress_ve,
mfn = p2m->get_entry(p2m, gfn, &t, &a, 0, NULL, NULL);
if ( !mfn_
During a discussion in person, it was identified that Coverage doesn't
currently work for ARM yet. Also, there are a number of errors with the
existing coverage document.
Take the opportunity to rewrite it in RST, making it easier to follow for a
non-expert user.
Signed-off-by: Andrew Cooper
--
Include (and retrofit to the user guide) an introductory paragraph describing
the intended audience.
Signed-off-by: Andrew Cooper
---
CC: George Dunlap
CC: Ian Jackson
CC: Jan Beulich
CC: Konrad Rzeszutek Wilk
CC: Stefano Stabellini
CC: Tim Deegan
CC: Wei Liu
CC: Julien Grall
---
docs/hy
This was identified IRL at the safety summit, so I took the opportunity to
improve things.
The result of this series, and some other in-development bits, can be found
at:
https://andrewcoop-xen.readthedocs.io/en/docs-devel/index.html
Andrew Cooper (2):
docs/sphinx: Introduce a hypervisor gui
>>> On 03.04.19 at 16:29, wrote:
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -3011,8 +3011,16 @@ int p2m_set_suppress_ve(struct domain *d, gfn_t gfn,
> bool suppress_ve,
> mfn = p2m->get_entry(p2m, gfn, &t, &a, 0, NULL, NULL);
> if ( !mfn_valid(mfn) )
> {
> -
On 03/04/2019 13:43, Jan Beulich wrote:
On 03.04.19 at 13:14, wrote:
>> On 03/04/2019 11:12, Jan Beulich wrote:
>> On 01.08.18 at 16:22, wrote:
When putting CPUs to sleep permanently, we should try to put them into
the most power conserving state possible. For now it is unclear
Hi all,
I came across some code in the p2m_set_altp2m_mem_access() that does not
seem right. On the invalid mfn branch there is a try to set_entry() and
if that is not successful then the function does not return and calls
set_entry again for PAGE_ORDER_4K even if there was a check that page
o
On a new altp2m view the p2m_set_suppress_ve() func will fail with invalid mfn
from p2m->get_entry() if the p2m->set_entry() was not called before.
This patch solves the problem by getting the mfn from __get_gfn_type_access()
and then returning error if the mfn is invalid.
Signed-off-by: Alexandr
flight 134282 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134282/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b02873340b2de5c2fe8325d22214cd3a5b21c5e5
baseline version:
ovmf 1c27ec42363515bda9746
On 02/04/2019 18:58, Paul Durrant wrote:
> This is actually v2 of the patch posted in [1]. Please see the thread
> starting there for more context...
>
> The semantics of sector based quanties, such as first_sect and last_sect in
> blkif_request_segment, and the value of "sectors" in the backend i
On Wed, Apr 3, 2019 at 2:56 AM Razvan Cojocaru
wrote:
>
> p2m_set_mem_access() (and other places) treat view 0 as the
> hostp2m, but p2m_get_mem_access() does not. Correct that
> inconsistency.
>
> Signed-off-by: Razvan Cojocaru
Acked-by: Tamas K Lengyel
___
>>> On 02.04.19 at 18:42, wrote:
> --- a/xen/include/public/xen.h
> +++ b/xen/include/public/xen.h
> @@ -97,6 +97,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
> #define __HYPERVISOR_set_timer_op 15
> #define __HYPERVISOR_event_channel_op_compat 16 /* compat since 0x00030202 */
> #define _
>>> On 03.04.19 at 13:14, wrote:
> On 03/04/2019 11:12, Jan Beulich wrote:
> On 01.08.18 at 16:22, wrote:
>>> When putting CPUs to sleep permanently, we should try to put them into
>>> the most power conserving state possible. For now it is unclear whether,
>>> especially in a deep C-state, t
>>> On 03.04.19 at 13:33, wrote:
> On 03/04/2019 11:44, Jan Beulich wrote:
> On 03.04.19 at 12:17, wrote:
>>> On 03/04/2019 10:33, Jan Beulich wrote:
>>> On 02.04.19 at 21:57, wrote:
> Slightly RFC. I'm not very happy with the contination situation, but
> -EBUSY
> is the pr
On Thu, Mar 21, 2019 at 06:20:42PM +, Julien Grall wrote:
> (+ Stefano, Wei and Ian)
>
> Hello,
>
> Apologies for the late answer.
>
> First of all, please avoid sending e-mail using HTML encoding. E-mail on
> mailing should only be plain text.
>
> On 3/20/19 9:28 AM, rambl...@sina.com wrot
On Mon, Apr 01, 2019 at 10:27:42AM -0600, Tamas K Lengyel wrote:
> Hi all,
> I'm trying to compile RELEASE-4.12.0 branch with --enable-githttp on a
> network that blocks normal git accesses and I encountered the
> following failures:
>
> fatal: clone of 'git://git.qemu.org/capstone.git' into submo
On Tue, Apr 02, 2019 at 05:42:38PM +0100, Julien Grall wrote:
> 2 paths in the domU console handling are now the same. So they can be
> merged to make the code simpler.
>
> Signed-off-by: Julien Grall
Acked-by: Wei Liu
(This obviously is dependent on the acceptance of patch 2)
___
On Tue, Apr 02, 2019 at 05:42:35PM +0100, Julien Grall wrote:
> The output will be buffered if the buffer provided by the DomU does not
> contain a newline. This can also happen if buffer provided by DomU is
> split in multiple part (Xen can only process 127 characters at the time).
>
> As Xen wil
On Tue, Apr 02, 2019 at 05:42:37PM +0100, Julien Grall wrote:
> Currently, OS developpers will have to look at Xen code in order to know
> the parameters of an hypercall and how it is meant to work.
>
> This is not a trivial task as you may need to have a deep understanding
> of Xen internal.
>
>
On 03/04/2019 11:44, Jan Beulich wrote:
On 03.04.19 at 12:17, wrote:
>> On 03/04/2019 10:33, Jan Beulich wrote:
>> On 02.04.19 at 21:57, wrote:
Slightly RFC. I'm not very happy with the contination situation, but
-EBUSY
is the preexisting style and it seems like it is th
Ping.
On Tue, Mar 26, 2019 at 02:35:10PM +0100, Petr Mladek wrote:
> Linus,
>
> On Mon 2019-03-25 21:32:28, Sakari Ailus wrote:
> > %pF and %pf are functionally equivalent to %pS and %ps conversion
> > specifiers. The former are deprecated, therefore switch the current users
> > to use the prefer
On 03/04/2019 11:12, Jan Beulich wrote:
On 01.08.18 at 16:22, wrote:
>> When putting CPUs to sleep permanently, we should try to put them into
>> the most power conserving state possible. For now it is unclear whether,
>> especially in a deep C-state, the P-state also matters, so this series
flight 83863 distros-debian-squeeze real [real]
http://osstest.xensource.com/osstest/logs/83863/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvopsbroken
build-i386
>>> On 03.04.19 at 12:17, wrote:
> On 03/04/2019 10:33, Jan Beulich wrote:
> On 02.04.19 at 21:57, wrote:
>>> Slightly RFC. I'm not very happy with the contination situation, but -EBUSY
>>> is the preexisting style and it seems like it is the only option from
>>> tasklet
>>> context.
>> Wel
>>> On 03.04.19 at 12:05, wrote:
> On 2019/4/3 16:43, Jan Beulich wrote:
>> On 30.03.19 at 11:42, wrote:
>>> +static void init_hygon(struct cpuinfo_x86 *c)
>>> +{
>>> + unsigned long long value;
>>> +
>>> + /* Attempt to set LFENCE to be Dispatch Serialising. */
>>> + if (rdmsr_safe(MSR_AMD
On 03/04/2019 10:33, Jan Beulich wrote:
On 02.04.19 at 21:57, wrote:
>> Currently, a user can in combine the output of `xl info -n`, the APCI tables,
>> and some manual CPUID data to figure out which CPU numbers to feed into
>> `xen-hptool cpu-offline` to effectively disable SMT at runtime.
>
>>> On 01.08.18 at 16:22, wrote:
> When putting CPUs to sleep permanently, we should try to put them into
> the most power conserving state possible. For now it is unclear whether,
> especially in a deep C-state, the P-state also matters, so this series only
> arranges for the C-state side of thin
On 2019/4/3 16:43, Jan Beulich wrote:
On 30.03.19 at 11:42, wrote:
+static void init_hygon(struct cpuinfo_x86 *c)
+{
+ unsigned long long value;
+
+ /* Attempt to set LFENCE to be Dispatch Serialising. */
+ if (rdmsr_safe(MSR_AMD64_DE_CFG, value))
+ /* Unable to
flight 134335 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134335/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
coverity-amd647 coverity-upload fail REGR. vs. 133615
version t
>>> On 03.04.19 at 11:06, wrote:
> On 03/04/2019 09:53, Jan Beulich wrote:
> On 02.04.19 at 21:57, wrote:
>>> --- a/xen/arch/x86/sysctl.c
>>> +++ b/xen/arch/x86/sysctl.c
>>> @@ -137,27 +137,35 @@ long arch_do_sysctl(
>>> case XEN_SYSCTL_cpu_hotplug:
>>> {
>>> unsigned int c
flight 134268 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134268/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken
build-arm64-xsm
>>> On 02.04.19 at 21:57, wrote:
> Currently, a user can in combine the output of `xl info -n`, the APCI tables,
> and some manual CPUID data to figure out which CPU numbers to feed into
> `xen-hptool cpu-offline` to effectively disable SMT at runtime.
>
> A more convenient option is to teach Xen
flight 134271 qemu-upstream-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134271/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-pvops
On Wed, Apr 03, 2019 at 09:07:50AM +, Wieczorkiewicz, Pawel wrote:
> I'm btw also confused by the Cc list you've used: You should
> have Cc-ed THE REST, not just the tool stack maintainers.
>
> You’re right. My bad. Sorry.
>
./scripts/get_maintainers.pl is your friend. :-)
Wei.
___
> -Original Message-
> From: Julien Grall [mailto:julien.gr...@arm.com]
> Sent: 03 April 2019 10:08
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Konrad Rzeszutek Wilk ; Roger Pau Monne
> ; Anthony
> Perard ; Andrew Cooper
> ; George Dunlap
> ; Ian Jackson ; Jan Beulich
> ;
>
(+ Juergen as he maintains the PV I/O with Konrad)
On 02/04/2019 17:58, Paul Durrant wrote:
This is actually v2 of the patch posted in [1]. Please see the thread
starting there for more context...
Should not this belong after ---?
The semantics of sector based quanties, such as first_sect a
On 3. Apr 2019, at 10:10, Jan Beulich
mailto:jbeul...@suse.com>> wrote:
On 03.04.19 at 09:56, mailto:wipa...@amazon.de>> wrote:
The symbols tool is outdated and has a bug in it leading to crashes.
The tool is derived from linux kernel where this bug has been already
fixed.
Thanks for noticing
On 03/04/2019 09:53, Jan Beulich wrote:
On 02.04.19 at 21:57, wrote:
>> --- a/xen/arch/x86/sysctl.c
>> +++ b/xen/arch/x86/sysctl.c
>> @@ -137,27 +137,35 @@ long arch_do_sysctl(
>> case XEN_SYSCTL_cpu_hotplug:
>> {
>> unsigned int cpu = sysctl->u.cpu_hotplug.cpu;
>> +
p2m_set_mem_access() (and other places) treat view 0 as the
hostp2m, but p2m_get_mem_access() does not. Correct that
inconsistency.
Signed-off-by: Razvan Cojocaru
---
xen/arch/x86/mm/mem_access.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/mm/mem_access.c b/x
>>> On 02.04.19 at 21:57, wrote:
> --- a/xen/arch/x86/sysctl.c
> +++ b/xen/arch/x86/sysctl.c
> @@ -137,27 +137,35 @@ long arch_do_sysctl(
> case XEN_SYSCTL_cpu_hotplug:
> {
> unsigned int cpu = sysctl->u.cpu_hotplug.cpu;
> +bool plug;
> +long (*fn)(void *) = NULL
>>> On 02.04.19 at 21:57, wrote:
> All methods of querying the online state of a CPU are racy without the hotplug
> lock held, which can lead to a TOCTOU race trying to online or offline CPUs.
>
> Distinguish this case with -EEXIST rather than -EINVAL, so the caller can take
> other actions if ne
>>> On 07.02.19 at 12:42, wrote:
> There are a few array accesses here the indexes of which are (at least
> indirectly) driven by the guest. Use array_access_nospec() to bound
> such accesses. In the {,_}decode_gpr() cases replace existing guarding
> constructs.
>
> To deal with an otherwise occu
>>> On 30.03.19 at 11:42, wrote:
> +static void init_hygon(struct cpuinfo_x86 *c)
> +{
> + unsigned long long value;
> +
> + /* Attempt to set LFENCE to be Dispatch Serialising. */
> + if (rdmsr_safe(MSR_AMD64_DE_CFG, value))
> + /* Unable to read. Assume the safer default
>>> On 03.04.19 at 09:56, wrote:
> The symbols tool is outdated and has a bug in it leading to crashes.
> The tool is derived from linux kernel where this bug has been already
> fixed.
Thanks for noticing this omission of ours.
> Original linux kernel commit:
> e0a04b11e4059cab033469617 scripts/
>>> On 02.04.19 at 19:49, wrote:
> On 02/04/2019 17:42, Julien Grall wrote:
>> diff --git a/xen/arch/arm/early_printk.c b/xen/arch/arm/early_printk.c
>> index 97466a12b1..35a47c7229 100644
>> --- a/xen/arch/arm/early_printk.c
>> +++ b/xen/arch/arm/early_printk.c
>> @@ -17,9 +17,10 @@
>> void earl
The symbols tool is outdated and has a bug in it leading to crashes.
The tool is derived from linux kernel where this bug has been already
fixed.
Original linux kernel commit:
e0a04b11e4059cab033469617 scripts/kallsyms.c: fix potential segfault
Signed-off-by: Pawel Wieczorkiewicz
Reviewed-by: Bj
flight 134270 qemu-upstream-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134270/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken
build-
82 matches
Mail list logo
