On Mon, 2019-04-01 at 08:06 +0200, Juergen Gross wrote:
> On 30/03/2019 11:24, Juergen Gross wrote:
> > I think its is easier to do it myself, as I'm touching nearly all
> > of
> > the call sites anyway.
>
> And another thought I had: with RETPOLINE indirect jumps are even
> more
> expensive. Woul
>>> On 29.03.19 at 20:20, wrote:
> However, the whole point of testing is to find places where your assumptions
> are violated. If the emulator ever *did* behave differently for canonical
> and non-canonical addresses, or near the boundary of canonicity, we’d want
> those behaviors to be teste
On Mon, 2019-04-01 at 08:49 +0200, Juergen Gross wrote:
> On 01/04/2019 08:41, Jan Beulich wrote:
> > One further general question came to mind: How about also having
> > "sched-granularity=thread" (or "...=none") to retain current
> > behavior, at least to have an easy way to compare effects if
>
>>> On 01.04.19 at 08:49, wrote:
> On 01/04/2019 08:41, Jan Beulich wrote:
> On 29.03.19 at 16:08, wrote:
>>> Via boot parameter sched_granularity=core (or sched_granularity=socket)
>>> it is possible to change the scheduling granularity from thread (the
>>> default) to either whole cores or
On 01/04/2019 09:10, Dario Faggioli wrote:
> On Mon, 2019-04-01 at 08:49 +0200, Juergen Gross wrote:
>> On 01/04/2019 08:41, Jan Beulich wrote:
>>> One further general question came to mind: How about also having
>>> "sched-granularity=thread" (or "...=none") to retain current
>>> behavior, at leas
Don't enforce any other dependencies for now, just like we don't enforce
e.g. PAE enabled as a prereq for long mode.
Signed-off-by: Jan Beulich
--- a/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
+++ b/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
@@ -662,21 +662,21 @@ static void set_sizes(
This is to accompany sanitize_input(). Just like for initial state we
want to have state between two emulated insns sane, at least as far as
assumptions in the main emulator go. Do minimal checking after segment
register, CR, and MSR writes, and roll back to the old value in case of
failure (raisin
>>> On 30.03.19 at 10:59, wrote:
> On 29/03/2019 22:33, Andrew Cooper wrote:
>> If at all possible, I'd prefer to see about disentangling the bits which
>> actually need external use, and putting them in sched.h, and making
>> sched-if.h properly private to the schedulers. I actually even started
>>> On 01.04.19 at 07:59, wrote:
> On 30/03/2019 10:59, Juergen Gross wrote:
>> On 29/03/2019 22:33, Andrew Cooper wrote:
>>> If at all possible, I'd prefer to see about disentangling the bits which
>>> actually need external use, and putting them in sched.h, and making
>>> sched-if.h properly pri
>>> On 30.03.19 at 11:22, wrote:
> On 29/03/2019 20:36, Andrew Cooper wrote:
>> In practice, all this flag does is permit the use of VCPUOP_get_physid,
>> disallow the use of vcpu_set_hard_affinity(), and allow dom0 to attempt
>> to actually write to MSR_AMD64_NB_CFG, MSR_FAM10H_MMIO_CONF_BASE,
>>
On 01/04/2019 08:05, Dario Faggioli wrote:
> On Mon, 2019-04-01 at 08:06 +0200, Juergen Gross wrote:
>> On 30/03/2019 11:24, Juergen Gross wrote:
>>> I think its is easier to do it myself, as I'm touching nearly all
>>> of
>>> the call sites anyway.
>> And another thought I had: with RETPOLINE indi
On 01/04/2019 09:05, Jan Beulich wrote:
On 01.04.19 at 07:59, wrote:
>> On 30/03/2019 10:59, Juergen Gross wrote:
>>> On 29/03/2019 22:33, Andrew Cooper wrote:
If at all possible, I'd prefer to see about disentangling the bits which
actually need external use, and putting them in sc
>>> On 29.03.19 at 17:57, wrote:
> timer_softirq_action() realloc's itself a larger timer heap whenever
> necessary, which includes bootstrapping from the empty dummy_heap. Nothing
> ever freed this allocation.
>
> CPU hot unplug and plug has the side effect of zeroing the percpu data area,
> wh
On 01/04/2019 09:01, Jan Beulich wrote:
On 30.03.19 at 10:59, wrote:
>> On 29/03/2019 22:33, Andrew Cooper wrote:
>>> If at all possible, I'd prefer to see about disentangling the bits which
>>> actually need external use, and putting them in sched.h, and making
>>> sched-if.h properly privat
>>> On 30.03.19 at 11:42, wrote:
> @@ -876,6 +877,10 @@ static int __init vpmu_init(void)
> if ( amd_vpmu_init() )
> vpmu_mode = XENPMU_MODE_OFF;
> break;
> +case X86_VENDOR_HYGON:
> +if ( hygon_vpmu_init() )
> + vpmu_mode = XENPMU_MODE_OFF;
> +
>>> On 30.03.19 at 11:42, wrote:
> There is no MSR_INTEL_PLATFORM_INFO for AMD and Hygon families. So directly
> return false in the function probe_cpuid_faulting() if !cpu_has_hypervisor.
I think it would have been nice if you had mentioned the real
reason why you want to bypass the MSR accesses
>>> On 01.04.19 at 10:26, wrote:
> While I did suggest this originally, I too am a little wary about the
> scope creep.
>
> If moving everything is too much, can we at least try to not make the
> sched-if.h situation any worse than it currently is.
+1
Jan
On 01/04/2019 10:33, Andrew Cooper wrote:
> On 01/04/2019 09:01, Jan Beulich wrote:
> On 30.03.19 at 10:59, wrote:
>>> On 29/03/2019 22:33, Andrew Cooper wrote:
If at all possible, I'd prefer to see about disentangling the bits which
actually need external use, and putting them in sc
On 01/04/2019 10:26, Andrew Cooper wrote:
> On 01/04/2019 09:05, Jan Beulich wrote:
> On 01.04.19 at 07:59, wrote:
>>> On 30/03/2019 10:59, Juergen Gross wrote:
On 29/03/2019 22:33, Andrew Cooper wrote:
> If at all possible, I'd prefer to see about disentangling the bits which
> a
On 01/04/2019 10:10, Jan Beulich wrote:
On 30.03.19 at 11:22, wrote:
>> On 29/03/2019 20:36, Andrew Cooper wrote:
>>> In practice, all this flag does is permit the use of VCPUOP_get_physid,
>>> disallow the use of vcpu_set_hard_affinity(), and allow dom0 to attempt
>>> to actually write to MS
On 01/04/2019 10:05, Jan Beulich wrote:
On 01.04.19 at 07:59, wrote:
>> On 30/03/2019 10:59, Juergen Gross wrote:
>>> On 29/03/2019 22:33, Andrew Cooper wrote:
If at all possible, I'd prefer to see about disentangling the bits which
actually need external use, and putting them in sc
On 01/04/2019 10:19, Andrew Cooper wrote:
> On 01/04/2019 08:05, Dario Faggioli wrote:
>> On Mon, 2019-04-01 at 08:06 +0200, Juergen Gross wrote:
>>> On 30/03/2019 11:24, Juergen Gross wrote:
I think its is easier to do it myself, as I'm touching nearly all
of
the call sites anyway.
On 29/03/2019 15:09, Juergen Gross wrote:
> Make sure the number of vcpus is always a multiple of the scheduling
> granularity. Note that we don't support a scheduling granularity above
> one on ARM.
I'm afraid that I don't think this is a clever move. In turn, this
brings into question the appro
> -Original Message-
> From: Andrew Cooper
> Sent: 28 March 2019 11:46
> To: Anthony Perard ; Paul Durrant
>
> Cc: xen-devel@lists.xenproject.org; qemu-bl...@nongnu.org;
> qemu-de...@nongnu.org; Kevin Wolf
> ; Stefano Stabellini ; Max Reitz
> ; Stefan
> Hajnoczi
> Subject: Re: [Xen-dev
CC: Lars Kurth
CC: Juergen Gross
Signed-off-by: Ian Jackson
---
SUPPORT.md | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/SUPPORT.md b/SUPPORT.md
index 19fc8d7533..d4173d70ad 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -9,10 +9,10 @@ for the definitions of the suppo
>>> On 31.03.19 at 10:11, wrote:
> There is problem in PCI device allocation algorithm (pci_setup()).
> Algorithm allocates PCI BAR sorted by size and this allows
> mixed allocation of prefetchable and non-prefetchable PCI MEM BAR.
> This leads to wrong config of PCI root port (see "Type 1 Configu
>>> On 01.04.19 at 10:56, wrote:
> --- a/SUPPORT.md
> +++ b/SUPPORT.md
> @@ -9,10 +9,10 @@ for the definitions of the support status levels etc.
>
> # Release Support
>
> -Xen-Version: 4.12-rc
> -Initial-Release: n/a
> -Supported-Until: TBD
> -Security-Support-Until: Unrelease
> -Original Message-
> From: Kevin Wolf [mailto:kw...@redhat.com]
> Sent: 28 March 2019 11:56
> To: Andrew Cooper
> Cc: Anthony Perard ; Paul Durrant
> ; xen-
> de...@lists.xenproject.org; qemu-bl...@nongnu.org; qemu-de...@nongnu.org;
> Stefano Stabellini
> ; Max Reitz ; Stefan Hajnoczi
On 01/04/2019 10:56, Ian Jackson wrote:
> CC: Lars Kurth
> CC: Juergen Gross
> Signed-off-by: Ian Jackson
> ---
> SUPPORT.md | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/SUPPORT.md b/SUPPORT.md
> index 19fc8d7533..d4173d70ad 100644
> --- a/SUPPORT.md
> +++ b
On Tue, Mar 26, 2019 at 10:06:48PM +0100, Hans van Kranenburg wrote:
> On 3/26/19 7:18 PM, M A Young wrote:
> > On Tue, 26 Mar 2019, Wei Liu wrote:
> >
> >> On Tue, Mar 26, 2019 at 01:16:35PM +, Wei Liu wrote:
> >>> On Mon, Mar 25, 2019 at 10:20:05PM +, YOUNG, MICHAEL A. wrote:
>
Ping?
On Thu, Feb 28, 2019 at 01:44:43PM +, Wei Liu wrote:
> We have a requirement to make each commit buildable in xen.git. Put this
> into a test in Gitlab CI.
>
> Wei Liu (5):
> automation: allow build-test.sh to run in detached HEAD state
> automation: set ret for potential error in b
Hi,
On 3/29/19 3:08 PM, Juergen Gross wrote:
cpu_disable_scheduler() is being called from __cpu_disable() today.
There is no need to execute it on the cpu just being disabled, so use
the CPU_DEAD case of the cpu notifier chain. Moving the call out of
stop_machine() context is fine, as we just ne
Am 01.04.2019 um 11:01 hat Paul Durrant geschrieben:
> > -Original Message-
> > From: Kevin Wolf [mailto:kw...@redhat.com]
> > Sent: 28 March 2019 11:56
> > To: Andrew Cooper
> > Cc: Anthony Perard ; Paul Durrant
> > ; xen-
> > de...@lists.xenproject.org; qemu-bl...@nongnu.org; qemu-de...
On 01/04/2019 11:21, Julien Grall wrote:
> Hi,
>
> On 3/29/19 3:08 PM, Juergen Gross wrote:
>> cpu_disable_scheduler() is being called from __cpu_disable() today.
>> There is no need to execute it on the cpu just being disabled, so use
>> the CPU_DEAD case of the cpu notifier chain. Moving the cal
On Tue, Mar 26, 2019 at 10:06:48PM +0100, Hans van Kranenburg wrote:
>
> Python 3 no longer allows comparing string and int, because it doesn't
> make sense.
>
> == sorted([1,2,3,'a','b','c'])
> Traceback (most recent call last):
> File "", line 1, in
> TypeError: unorderable types: str() < in
On 01/04/2019 10:50, Andrew Cooper wrote:
> On 29/03/2019 15:09, Juergen Gross wrote:
>> Make sure the number of vcpus is always a multiple of the scheduling
>> granularity. Note that we don't support a scheduling granularity above
>> one on ARM.
>
> I'm afraid that I don't think this is a clever
> -Original Message-
[snip]
> > >
> > > The old implementation has the sector size hardcoded:
> > >
> > > #define BLOCK_SIZE 512
> > >
> > > Whereas the qdevified version uses DEFINE_BLOCK_PROPERTIES(), which
> > > includes user-visible options for logical/physical_block_size.
> > >
>
flight 134237 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134237/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-pvops
On Mon, 1 Apr 2019, Wei Liu wrote:
> On Tue, Mar 26, 2019 at 10:06:48PM +0100, Hans van Kranenburg wrote:
> >
> > Python 3 no longer allows comparing string and int, because it doesn't
> > make sense.
> >
> > == sorted([1,2,3,'a','b','c'])
> > Traceback (most recent call last):
> > File "",
On Mon, Apr 01, 2019 at 10:59:05AM +0100, M A Young wrote:
>
>
> On Mon, 1 Apr 2019, Wei Liu wrote:
>
> > On Tue, Mar 26, 2019 at 10:06:48PM +0100, Hans van Kranenburg wrote:
> > >
> > > Python 3 no longer allows comparing string and int, because it doesn't
> > > make sense.
> > >
> > > == sor
On Wed, Mar 27, 2019 at 01:36:10AM +0100, Hans van Kranenburg wrote:
> On 3/26/19 2:16 PM, Wei Liu wrote:
> > On Mon, Mar 25, 2019 at 10:20:05PM +, YOUNG, MICHAEL A. wrote:
> >> [...]
> >> --- xen-4.12.0-rc6/tools/pygrub/src/pygrub.orig2019-03-24
> >> 22:44:05.503582025 +
> >> +++ xen-
The is_pinned field is rather odd. It can only be activated with the
"dom0_vcpus_pin" command line option, and causes dom0 (or the late hwdom) to
have its vcpus identity pinned to pcpus.
Having dom0_vcpus_pin active disallows the use of vcpu_set_hard_affinity().
However, when a pcpu is hot unplug
flight 134250 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134250/
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 25/03/2019 17:08, Jan Beulich wrote:
On 25.03.19 at 12:12, wrote:
>> Currently cpu_sig struct is not updated during boot when either:
>>
>> 1. ucode_scan is set to false (e.g. no "ucode=scan" in cmdline)
>> 2. initrd does not contain a microcode blob
>
> What about "ucode="?
Yes,
Hi,
On 4/1/19 10:40 AM, Juergen Gross wrote:
On 01/04/2019 11:21, Julien Grall wrote:
Hi,
On 3/29/19 3:08 PM, Juergen Gross wrote:
cpu_disable_scheduler() is being called from __cpu_disable() today.
There is no need to execute it on the cpu just being disabled, so use
the CPU_DEAD case of the
1. Explicitly import reduce because that's required in 3.
2. Change print to function.
3. Eliminate invocations of has_key.
Signed-off-by: M A Young
Signed-off-by: Wei Liu
---
tools/ocaml/libs/xentoollog/genlevels.py | 5 -
tools/ocaml/libs/xl/genwrap.py | 17 ++---
2
The code suggests 0 is allowed. Zero is not a positive number.
Signed-off-by: Wei Liu
---
Backport candadiate.
---
tools/pygrub/src/GrubConf.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/pygrub/src/GrubConf.py b/tools/pygrub/src/GrubConf.py
index f8d3799dc0..0204d4
Wei Liu (4):
pygrub: fix message in grub parser
pygrub/grub: always use integer for default entry
pygrub: decode string in Python 3
tools/ocaml: make python scripts 2 and 3 compatible
tools/ocaml/libs/xentoollog/genlevels.py | 5 -
tools/ocaml/libs/xl/genwrap.py | 17 ++
flight 83853 distros-debian-sid real [real]
http://osstest.xensource.com/osstest/logs/83853/
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
String is unicode in 3 but bytes in 2. We need to call decode function
when using Python 3.
Reported-by: M A Young
Signed-off-by: Wei Liu
---
tools/pygrub/src/pygrub | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/tools/pygrub/src/pygrub b/tools/pygrub/src/pygrub
index d
The original code set the default to either a string or an integer
(0) and relies on a Python 2 specific behaviour to work (integer is
allowed to be compared to string in Python 2 but not 3).
Always use integer. The caller (pygrub) already has code to handle
that.
Reported-by: M A Young
Signed-o
Hi Juergen,
On 3/28/19 12:06 PM, Juergen Gross wrote:
cpu_disable_scheduler() is being called from __cpu_disable() today.
There is no need to execute it on the cpu just being disabled, so use
the CPU_DEAD case of the cpu notifier chain. Moving the call out of
stop_machine() context is fine, as w
On 01/04/2019 12:29, Julien Grall wrote:
> Hi,
>
> On 4/1/19 10:40 AM, Juergen Gross wrote:
>> On 01/04/2019 11:21, Julien Grall wrote:
>>> Hi,
>>>
>>> On 3/29/19 3:08 PM, Juergen Gross wrote:
cpu_disable_scheduler() is being called from __cpu_disable() today.
There is no need to execute
Signed-off-by: Wei Liu
---
tools/xenmon/xenmon.py | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/tools/xenmon/xenmon.py b/tools/xenmon/xenmon.py
index 2a948cd48a..175eacd2cb 100644
--- a/tools/xenmon/xenmon.py
+++ b/tools/xenmon/xenmon.py
@@ -23,6 +23,8 @@
# along
> On Apr 1, 2019, at 8:46 AM, Jan Beulich wrote:
>
> This is to accompany sanitize_input(). Just like for initial state we
> want to have state between two emulated insns sane, at least as far as
> assumptions in the main emulator go. Do minimal checking after segment
> register, CR, and MSR wr
On 01/04/2019 11:39, Wei Liu wrote:
> Signed-off-by: Wei Liu
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Hi Lukas,
You sent this patch twice. Is there any difference between the two?
On 3/27/19 7:19 AM, Lukas Juenger wrote:
Xen's vGIC implementation supports a maximum number of 992 IRQ lines.
NIT: The correct term is Interrupt Lines.
GICv2 specification allows for 1020 IRQ lines.
This is comm
>>> On 01.04.19 at 12:44, wrote:
>> On Apr 1, 2019, at 8:46 AM, Jan Beulich wrote:
>> +/*
>> + * Call this function from hooks potentially altering machine state into
>> + * something that's not architecturally valid, yet which - as per above -
>> + * the emulator relies on.
>> + */
>> +static bo
The Xen blkif protocol requires that sector based quantities should be
interpreted strictly as multiples of 512 bytes. Specifically:
"first_sect and last_sect in blkif_request_segment, as well as
sector_number in blkif_request, are always expressed in 512-byte units."
Commit fcab2b464e06 "xen: ad
>>> On 01.04.19 at 12:09, wrote:
> 3) cpumask_weight() is a surprisingly expensive function, and we use it all
>over the place. It will almost certainly benefit from the use of popcnt.
FTR this was something I was meaning to possibly do once the BMI2
alternatives patching series would have b
> On 15 Mar 2019, at 03:00, Jan Beulich wrote:
>
On 14.03.19 at 18:22, wrote:
>> Options are:
>> a) Someone steps up and does the meeting either next week or the week after
>> b) Skip the March meeting
>> c) Skip the March meeting and restart April 4 and have the meeting the 1st
>> Thu
On 01/04/2019 13:21, Jan Beulich wrote:
On 01.04.19 at 12:09, wrote:
>> 3) cpumask_weight() is a surprisingly expensive function, and we use it all
>>over the place. It will almost certainly benefit from the use of popcnt.
> FTR this was something I was meaning to possibly do once the BM
flight 134201 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134201/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-xsm
On 03/21/2019 12:03 PM, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> On 03/20/2019 09:08 PM, Gustavo A. R. Silva wrote:
>> Hi all,
>>
>> Friendly ping:
>>
>> Who can take this?
>
> I'll take this for v5.2.
Patch queued for v5.2, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D I
Hi Juergen,
On 4/1/19 11:37 AM, Juergen Gross wrote:
On 01/04/2019 12:29, Julien Grall wrote:
Hi,
On 4/1/19 10:40 AM, Juergen Gross wrote:
On 01/04/2019 11:21, Julien Grall wrote:
Hi,
On 3/29/19 3:08 PM, Juergen Gross wrote:
cpu_disable_scheduler() is being called from __cpu_disable() toda
On 01/04/2019 15:21, Julien Grall wrote:
> Hi Juergen,
>
> On 4/1/19 11:37 AM, Juergen Gross wrote:
>> On 01/04/2019 12:29, Julien Grall wrote:
>>> Hi,
>>>
>>> On 4/1/19 10:40 AM, Juergen Gross wrote:
On 01/04/2019 11:21, Julien Grall wrote:
> Hi,
>
> On 3/29/19 3:08 PM, Juergen G
On Mon, 2019-04-01 at 11:09 +0100, Andrew Cooper wrote:
> The is_pinned field is rather odd.
>
Indeed. And I'm very, very happy to see it going away.
> Signed-off-by: Andrew Cooper
>
Reviewed-by: Dario Faggioli
Regards,
Dario
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualizat
On Mon, Apr 01, 2019 at 11:19:19AM +0100, Sergey Dyasli wrote:
>On 25/03/2019 17:08, Jan Beulich wrote:
> On 25.03.19 at 12:12, wrote:
>>> Currently cpu_sig struct is not updated during boot when either:
>>>
>>> 1. ucode_scan is set to false (e.g. no "ucode=scan" in cmdline)
>>> 2. ini
flight 134261 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134261/
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 01.04.19 at 14:35, wrote:
> On 01/04/2019 13:21, Jan Beulich wrote:
> On 01.04.19 at 12:09, wrote:
>>> 3) cpumask_weight() is a surprisingly expensive function, and we use it all
>>>over the place. It will almost certainly benefit from the use of popcnt.
>> FTR this was something
Hi,
On 4/1/19 2:33 PM, Juergen Gross wrote:
On 01/04/2019 15:21, Julien Grall wrote:
Hi Juergen,
On 4/1/19 11:37 AM, Juergen Gross wrote:
On 01/04/2019 12:29, Julien Grall wrote:
Hi,
On 4/1/19 10:40 AM, Juergen Gross wrote:
On 01/04/2019 11:21, Julien Grall wrote:
Hi,
On 3/29/19 3:08 PM,
There are a number of bugs. There are no read/write hooks on the HVM side, so
guest accesses fall into the "read/write-discard" defaults, which bypass the
correct faulting behaviour and the Intel special case.
For the PV side, writes are discarded (again, bypassing proper faulting),
except for a
On 29/03/2019 09:39, Jan Beulich wrote:
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -8547,6 +8547,9 @@ x86_emulate(
> invoke_stub("", "", "+m" (mask) : "a" (&mask));
> put_stub(stub);
>
> +if ( rc != X86EMUL_OKAY )
>
On 01/04/2019 16:01, Julien Grall wrote:
> Hi,
>
> On 4/1/19 2:33 PM, Juergen Gross wrote:
>> On 01/04/2019 15:21, Julien Grall wrote:
>>> Hi Juergen,
>>>
>>> On 4/1/19 11:37 AM, Juergen Gross wrote:
On 01/04/2019 12:29, Julien Grall wrote:
> Hi,
>
> On 4/1/19 10:40 AM, Juergen Gr
On 29/03/2019 10:56, Jan Beulich wrote:
On 29.03.19 at 11:02, wrote:
>> On 29/03/2019 09:36, Jan Beulich wrote:
>>> I'd like to put up the other option then: Rather than using
>>> _get_fpu() (and in particular the read_xcr() and read_cr() hooks)
>>> we could read the real XCR0 here. After all
>>> On 01.04.19 at 16:01, wrote:
> There are a number of bugs. There are no read/write hooks on the HVM side, so
> guest accesses fall into the "read/write-discard" defaults, which bypass the
> correct faulting behaviour and the Intel special case.
>
> For the PV side, writes are discarded (agai
>>> On 01.04.19 at 16:14, wrote:
> On 29/03/2019 10:56, Jan Beulich wrote:
> On 29.03.19 at 11:02, wrote:
>>> On 29/03/2019 09:36, Jan Beulich wrote:
I'd like to put up the other option then: Rather than using
_get_fpu() (and in particular the read_xcr() and read_cr() hooks)
we
>>> On 01.04.19 at 16:04, wrote:
> On 29/03/2019 09:39, Jan Beulich wrote:
>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>> @@ -8547,6 +8547,9 @@ x86_emulate(
>> invoke_stub("", "", "+m" (mask) : "a" (&mask));
>> put_stub(stub);
>
On Mon, 2019-04-01 at 09:19 +0100, Andrew Cooper wrote:
> On 01/04/2019 08:05, Dario Faggioli wrote:
> > On Mon, 2019-04-01 at 08:06 +0200, Juergen Gross wrote:
> > > The
> > > wrappers could then call the related specific scheduler function
> > > based
> > > on the scheduler Id using a chain of if
Hi,
On 4/1/19 3:23 PM, Juergen Gross wrote:
On 01/04/2019 16:01, Julien Grall wrote:
Hi,
On 4/1/19 2:33 PM, Juergen Gross wrote:
On 01/04/2019 15:21, Julien Grall wrote:
Hi Juergen,
On 4/1/19 11:37 AM, Juergen Gross wrote:
On 01/04/2019 12:29, Julien Grall wrote:
Hi,
On 4/1/19 10:40 AM,
Dear All,
this is a quick reminder that the CfP for the developer summit is approaching.
The CfP for talks (aka morning sessions is on April 12th). We are also
considering to allocate a day dedicated to embedded and safety related topics
following last week's automotive meeting. The link for su
On 01/04/2019 15:55, Jan Beulich wrote:
>
>> Secondly, when a guest executes CPUID, this doesn't
>> typically result in Xen executing a CPUID instruction in practice.
> Wait - this is true for DomU, but used to be false for (PV) Dom0,
> until you've switched over from pv_cpuid() to guest_cpuid().
flight 134242 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134242/
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
On 01/04/2019 17:15, Julien Grall wrote:
> Hi,
>
> On 4/1/19 3:23 PM, Juergen Gross wrote:
>> On 01/04/2019 16:01, Julien Grall wrote:
>>> Hi,
>>>
>>> On 4/1/19 2:33 PM, Juergen Gross wrote:
On 01/04/2019 15:21, Julien Grall wrote:
> Hi Juergen,
>
> On 4/1/19 11:37 AM, Juergen Gro
flight 134207 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134207/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt broken
build-arm64-pvops
On 01/04/2019 16:12, Jan Beulich wrote:
On 01.04.19 at 16:04, wrote:
>> On 29/03/2019 09:39, Jan Beulich wrote:
>>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>>> @@ -8547,6 +8547,9 @@ x86_emulate(
>>> invoke_stub("", "", "+m" (mask)
On 01/04/2019 11:32, Wei Liu wrote:
> The code suggests 0 is allowed. Zero is not a positive number.
>
> Signed-off-by: Wei Liu
I suspect you are opening a can of number theory worms with that commit
message, but the overall change is an improvement.
Acked-by: Andrew Cooper
___
On 01/04/2019 11:32, Wei Liu wrote:
> String is unicode in 3 but bytes in 2. We need to call decode function
> when using Python 3.
>
> Reported-by: M A Young
> Signed-off-by: Wei Liu
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists
On 01/04/2019 11:32, Wei Liu wrote:
> The original code set the default to either a string or an integer
> (0) and relies on a Python 2 specific behaviour to work (integer is
> allowed to be compared to string in Python 2 but not 3).
>
> Always use integer. The caller (pygrub) already has code to h
On 01/04/2019 11:32, Wei Liu wrote:
> 1. Explicitly import reduce because that's required in 3.
> 2. Change print to function.
> 3. Eliminate invocations of has_key.
>
> Signed-off-by: M A Young
> Signed-off-by: Wei Liu
Reviewed-by: Andrew Cooper
___
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 submodule path
'/data/src/xen/tools/qemu-xen-dir-remote/capstone' failed
Failed to
> On 1 Apr 2019, at 11:32, Wei Liu wrote:
>
> 1. Explicitly import reduce because that's required in 3.
> 2. Change print to function.
> 3. Eliminate invocations of has_key.
>
> Signed-off-by: M A Young
> Signed-off-by: Wei Liu
Acked-by: Christian Lindig
_
flight 134266 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134266/
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 Mon, Apr 01, 2019 at 01:17:19PM +0100, Paul Durrant wrote:
> The Xen blkif protocol requires that sector based quantities should be
> interpreted strictly as multiples of 512 bytes. Specifically:
>
> "first_sect and last_sect in blkif_request_segment, as well as
> sector_number in blkif_request
On 01/04/2019 09:27, Jan Beulich wrote:
On 29.03.19 at 17:57, wrote:
>> timer_softirq_action() realloc's itself a larger timer heap whenever
>> necessary, which includes bootstrapping from the empty dummy_heap. Nothing
>> ever freed this allocation.
>>
>> CPU hot unplug and plug has the side
flight 133953 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133953/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-examine 8 reboot fail REGR. vs. 128858
test-amd64-i386-free
Hi,
On 4/1/19 5:00 PM, Juergen Gross wrote:
On 01/04/2019 17:15, Julien Grall wrote:
Hi,
On 4/1/19 3:23 PM, Juergen Gross wrote:
On 01/04/2019 16:01, Julien Grall wrote:
Hi,
On 4/1/19 2:33 PM, Juergen Gross wrote:
On 01/04/2019 15:21, Julien Grall wrote:
Hi Juergen,
On 4/1/19 11:37 AM, J
Hello.
On Mon, 1 Apr 2019, Jan Beulich wrote:
On 31.03.19 at 10:11, wrote:
There is problem in PCI device allocation algorithm (pci_setup()).
Algorithm allocates PCI BAR sorted by size and this allows
mixed allocation of prefetchable and non-prefetchable PCI MEM BAR.
This leads to wrong config
Den 01.04.2019 11:34, skrev Kevin Wolf:
Yes, for 512 accesses on native 4k disks with O_DIRECT, the QEMU block
layer performs the necessary RMW. Of course, it still comes with a
performance penalty, so you want to avoid such setups, but they do work.
I suspect that the approximately 1/10 -th
On Mon, 1 Apr 2019, Wei Liu wrote:
> Wei Liu (4):
> pygrub: fix message in grub parser
> pygrub/grub: always use integer for default entry
> pygrub: decode string in Python 3
> tools/ocaml: make python scripts 2 and 3 compatible
>
> tools/ocaml/libs/xentoollog/genlevels.py | 5 -
> tools/o
1 - 100 of 126 matches
Mail list logo
