Variable err is initialized with 0. As a result, the return value may
be 0 even if get_zeroed_page() fails to allocate memory. This patch fixes
the bug, initializing err with "-ENOMEM".
v1 is reviewed by: Juergen Gross
Signed-off-by: Pan Bian
---
drivers/xen/xenbus/xenbus_probe.c | 2 +-
1 fi
Variable rc is reset in the loop, and its value will be non-negative
during the second and after repeat of the loop. If it fails to allocate
memory then, it may return a non-negative integer, which indicates no
error. This patch fixes the bug, assigning "-ENOMEM" to rc when
kzalloc() or alloc_page(
>>> On 05.12.16 at 08:48, wrote:
> @@ -1304,12 +1275,51 @@ static void do_debug(struct connection *conn, struct
> buffered_data *in)
> send_ack(conn, XS_DEBUG);
> }
>
> +static struct {
> + char *str;
> + void (*func)(struct connection *conn, struct buffered_data *in);
> +} wire_
On 05/12/16 09:23, Pan Bian wrote:
> Variable rc is reset in the loop, and its value will be non-negative
> during the second and after repeat of the loop. If it fails to allocate
> memory then, it may return a non-negative integer, which indicates no
> error. This patch fixes the bug, assigning "-
On 05/12/16 09:22, Pan Bian wrote:
> Variable err is initialized with 0. As a result, the return value may
> be 0 even if get_zeroed_page() fails to allocate memory. This patch fixes
> the bug, initializing err with "-ENOMEM".
>
> v1 is reviewed by: Juergen Gross
I didn't say so.
> Signed-off-
On Mon, Dec 05, 2016 at 01:43:40AM -0700, Jan Beulich wrote:
> >>> On 05.12.16 at 08:48, wrote:
> > @@ -1304,12 +1275,51 @@ static void do_debug(struct connection *conn,
> > struct buffered_data *in)
> > send_ack(conn, XS_DEBUG);
> > }
> >
> > +static struct {
> > + char *str;
> > + vo
On Mon, Dec 05, 2016 at 08:48:43AM +0100, Juergen Gross wrote:
> Instead of calling add_change_node() at places where write_node() is
> called, do that inside write_node().
>
> Note that there is one case where add_change_node() is called now when
> a later failure will prohibit the changed node t
When tracing a difference between two runs, it can be useful to reset the
trace count to help identify where the two traces diverge.
Move the count outside debugtrace_printk() it can be reset. Inline
debugtrace_toggle() into its single caller, so its prologue and epilogue can
be reused. Register
On Mon, Dec 05, 2016 at 08:48:50AM +0100, Juergen Gross wrote:
> Move functions used in only one source to the file where they are used
> and make them static.
>
> Remove some prototypes from headers which are no longer in use.
>
> Signed-off-by: Juergen Gross
Acked-by: Wei Liu
__
On Mon, Dec 05, 2016 at 08:48:53AM +0100, Juergen Gross wrote:
> Check for failures when allocating new memory in xenstored.
>
> Signed-off-by: Juergen Gross
I acked v3 of this patch already.
Assuming only the stale paragraph in commit message is deleted:
Acked-by: Wei Liu
__
print_gw() has no callers, meaning that it only gets used as part of manual
debugging. As such, the FILE/LINE references are of no practical use, and
voluminous in the log. Additionally, the function becoming empty in a
non-debug build is unhelpful. Switch from gdprintk() to gprintk().
Print th
Mandatory barriers are only for use with reduced-cacheability MMIO mappings.
All of these uses are just to deal with shared memory between multiple
processors, so use the smp_*() which are the correct barriers for the purpose.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Stefano Stabell
None of these barriers serve any purpose, as they are not synchronising with
any anything on remote CPUs.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Stefano Stabellini
CC: Julien Grall
Restricting to just the $ARCH maintainers, as this is a project-wide sweep.
Julien/Stefano: I thi
Andrew Cooper (4):
xen/common: Replace incorrect mandatory barriers with SMP barriers
xen/x86: Drop erronious barriers
xen/x86: Replace incorrect mandatory barriers with SMP barriers
xen/x86: Correct mandatory and SMP barrier definitions
xen/arch/x86/acpi/cpu_idle.c | 10 -
Mandatory barriers are only for use with reduced-cacheability memory mappings.
All of these uses are just to deal with shared memory between multiple
processors, so use the smp_*() which are the correct barriers for the purpose.
This is no functional change, because Xen currently assigns the smp_
Barriers are a complicated topic, a common source of confusion in submitted
code, and their incorrect use is a common cause of bugs. It *really* doesn't
help when Xen's API is the same as Linux, but its ABI different.
Bring the two back in line, so programmers stand a chance of actually getting
t
Note that unlike most privilege restricted instructions, STAC and CLAC are
documented to raise #UD rather than #GP[0], and indeed do so.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/arch/x86/x86_emulate/x86_emulate.c | 24
1 file changed, 20 insertions(+), 4
Disable stdout buffering, so logging gets out even if the harness crashes.
Add a verbose option (compile time disabled) which dumps all read/write calls
the harness makes
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
tools/tests/x86_emulator/test_x86_emulator.c | 17 +
1
Update the read_msr() hook to take an additional parameter, indicating that
there should be no side effects of the read.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Paul Durrant
---
xen/arch/x86/hvm/emulate.c | 3 ++-
xen/arch/x86/x86_emulate/x86_em
The current hvm_msr_{read,write}_intercept() infrastructure calls
hvm_inject_hw_exception() directly to latch a fault, and returns
X86EMUL_EXCEPTION to its caller.
This behaviour is problematic for the hvmemul_{read,write}_msr() paths, as the
fault is raised behind the back of the x86 emulator.
A
Check that event->error_code is appropriate for the type/vector combination.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/arch/x86/hvm/hvm.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index e0f936b..ac207e4 100644
---
Use the new speculative read support to query MSR_INTEL_MISC_FEATURES for
active CPUID faulting, without raising #GP as a side effect.
This removes the need for every cpuid() emulation hook to individually support
CPUID faulting.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Paul Durrant
This series prevents the MSR path from raising faults behind the back of the
emulator.
Andrew Cooper (8):
x86/shadow: Drop stale adjustment in the PAE second-half search
x86/emul: Debugging improvements to the test harness
x86/hvm: Assert some expectations in hvm_inject_event()
x86/emul: D
This shouldn't have been present in c/s 29a57c992 "x86/emul: Rework emulator
event injection". It was a leftover from a previous version of the series.
This conditional has no effect on the behaviour following it, as both
X86EMUL_EXCEPTION and X86EMUL_UNHANDLEABLE fall into the same "return back
And drop the compatibility typedef from the userspace harness
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
tools/tests/x86_emulator/x86_emulate.c | 2 --
xen/arch/x86/x86_emulate/x86_emulate.c | 43 ++
2 files changed, 23 insertions(+), 22 deletions(-)
On 05/12/16 11:05, Andrew Cooper wrote:
> Barriers are a complicated topic, a common source of confusion in submitted
> code, and their incorrect use is a common cause of bugs. It *really* doesn't
> help when Xen's API is the same as Linux, but its ABI different.
>
> Bring the two back in line, s
On 05/12/16 11:03, Wei Liu wrote:
> On Mon, Dec 05, 2016 at 08:48:53AM +0100, Juergen Gross wrote:
>> Check for failures when allocating new memory in xenstored.
>>
>> Signed-off-by: Juergen Gross
>
> I acked v3 of this patch already.
>
> Assuming only the stale paragraph in commit message is de
On Mon, Dec 05, 2016 at 11:15:03AM +0100, Juergen Gross wrote:
> On 05/12/16 11:03, Wei Liu wrote:
> > On Mon, Dec 05, 2016 at 08:48:53AM +0100, Juergen Gross wrote:
> >> Check for failures when allocating new memory in xenstored.
> >>
> >> Signed-off-by: Juergen Gross
> >
> > I acked v3 of this
At 10:09 + on 05 Dec (1480932564), Andrew Cooper wrote:
> This shouldn't have been present in c/s 29a57c992 "x86/emul: Rework emulator
> event injection". It was a leftover from a previous version of the series.
IMO this hunk was correct in 29a57c992, but it's fine to remove it now.
Acked-by
At 10:02 + on 05 Dec (1480932154), Andrew Cooper wrote:
> print_gw() has no callers, meaning that it only gets used as part of manual
> debugging. As such, the FILE/LINE references are of no practical use, and
> voluminous in the log. Additionally, the function becoming empty in a
> non-debug
On Mon, Dec 05, 2016 at 10:16:39AM +, Wei Liu wrote:
> On Mon, Dec 05, 2016 at 11:15:03AM +0100, Juergen Gross wrote:
> > On 05/12/16 11:03, Wei Liu wrote:
> > > On Mon, Dec 05, 2016 at 08:48:53AM +0100, Juergen Gross wrote:
> > >> Check for failures when allocating new memory in xenstored.
> >
>>> On 05.12.16 at 11:02, wrote:
> When tracing a difference between two runs, it can be useful to reset the
> trace count to help identify where the two traces diverge.
>
> Move the count outside debugtrace_printk() it can be reset. Inline
> debugtrace_toggle() into its single caller, so its pr
>>> On 05.12.16 at 11:05, wrote:
> Mandatory barriers are only for use with reduced-cacheability MMIO mappings.
>
> All of these uses are just to deal with shared memory between multiple
> processors, so use the smp_*() which are the correct barriers for the
> purpose.
>
> Signed-off-by: Andrew
branch xen-4.5-testing
xenbranch xen-4.5-testing
job test-xtf-amd64-amd64-1
testid leak-check/check
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xen
flight 68160 distros-debian-sid real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68160/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-amd64-sid-netboot-pygrub 9 debian-di-install fail like 68113
test-amd64-i386-i38
Dear community members,
I'm pleased to announce that Julien Grall will be
the Release Manager for the next Xen release.
The appointment was voted by the Committers and the vote passed.
Julien has done excellent jobs in many aspects. He has been an active
developer for the past few years and con
>>> On 05.12.16 at 11:05, wrote:
As to the title - don't you rather mean "pointless" or some such? It's
not really an error to have them where they are.
> --- a/xen/arch/x86/crash.c
> +++ b/xen/arch/x86/crash.c
> @@ -146,9 +146,6 @@ static void nmi_shootdown_cpus(void)
> write_atomic((unsig
On 05/12/16 11:18, Jan Beulich wrote:
On 05.12.16 at 11:05, wrote:
> As to the title - don't you rather mean "pointless" or some such? It's
> not really an error to have them where they are.
True. I will update.
>
>> --- a/xen/arch/x86/crash.c
>> +++ b/xen/arch/x86/crash.c
>> @@ -146,9 +14
>>> On 05.12.16 at 11:05, wrote:
> --- a/xen/arch/x86/acpi/cpu_idle.c
> +++ b/xen/arch/x86/acpi/cpu_idle.c
> @@ -391,9 +391,9 @@ void mwait_idle_with_hints(unsigned int eax, unsigned int
> ecx)
>
> if ( boot_cpu_has(X86_FEATURE_CLFLUSH_MONITOR) )
> {
> -mb();
> +smp_mb
On 05/12/16 10:52, Jan Beulich wrote:
On 05.12.16 at 11:02, wrote:
>> When tracing a difference between two runs, it can be useful to reset the
>> trace count to help identify where the two traces diverge.
>>
>> Move the count outside debugtrace_printk() it can be reset. Inline
>> debugtrace
>>> On 05.12.16 at 11:05, wrote:
> Barriers are a complicated topic, a common source of confusion in submitted
> code, and their incorrect use is a common cause of bugs. It *really* doesn't
> help when Xen's API is the same as Linux, but its ABI different.
>
> Bring the two back in line, so prog
>>> On 05.12.16 at 11:09, wrote:
> @@ -47,6 +49,9 @@ static int read(
> unsigned int bytes,
> struct x86_emulate_ctxt *ctxt)
> {
> +if ( verbose )
> +printf("** %s(%u, %p,, %u,)\n", __func__, seg, (void *)offset,
> bytes);
There appear to be two stray commas here, or do th
On 05/12/16 10:05, Andrew Cooper wrote:
>
> + * Loads may be reordered ahead of an unaliasing store.
It might be useful to summarize what an "unaliasing store" is.
David
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-dev
On Mon, Dec 05, 2016 at 08:48:41AM +0100, Juergen Gross wrote:
[...]
> Juergen Gross (12):
> xenstore: modify add_change_node() parameter types
> xenstore: call add_change_node() directly when writing node
> xenstore: use common tdb record header in xenstore
> xenstore: add per-node generat
On Sat, Dec 03, 2016 at 04:03:01PM +, Wei Liu wrote:
> On Fri, Dec 02, 2016 at 04:08:06PM +0100, Cédric Bosdonnat wrote:
> > Hey all,
> >
> > Here is v2 addressing Wei's comments on patch #1. The 3 libxl.c
> > patches haven't been merged, but the commit message of the first
> > one has been sl
>>> On 05.12.16 at 11:09, wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -1679,6 +1679,15 @@ void hvm_triple_fault(void)
> void hvm_inject_event(const struct x86_event *event)
> {
> struct vcpu *curr = current;
> +const uint8_t vector = event->vector;
> +c
>>> On 05.12.16 at 11:09, wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -509,7 +509,11 @@ void hvm_do_resume(struct vcpu *v)
>
> if ( w->do_write.msr )
> {
> -hvm_msr_write_intercept(w->msr, w->value, 0);
> +int rc = hvm_msr_w
Hi all
I'm pleased to announce that Xen 4.8.0 is released.
Please find tarball and its signature at:
https://downloads.xenproject.org/release/xen/4.8.0/
You can also check out the tag in xen.git:
git://xenbits.xen.org/xen.git RELEASE-4.8.0
Thanks everyone who contributed to this release.
>>> On 05.12.16 at 12:25, wrote:
> On 05/12/16 11:18, Jan Beulich wrote:
> On 05.12.16 at 11:05, wrote:
>>> --- a/xen/arch/x86/crash.c
>>> +++ b/xen/arch/x86/crash.c
>>> @@ -146,9 +146,6 @@ static void nmi_shootdown_cpus(void)
>>> write_atomic((unsigned long *)__va(__pa(&exception_table[
>>> On 05.12.16 at 11:09, wrote:
> And drop the compatibility typedef from the userspace harness
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
flight 102897 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102897/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 102843
test-amd64-i386-xl-qemuu-wi
>>> On 05.12.16 at 12:50, wrote:
> On 05/12/16 10:52, Jan Beulich wrote:
> On 05.12.16 at 11:02, wrote:
>>> When tracing a difference between two runs, it can be useful to reset the
>>> trace count to help identify where the two traces diverge.
>>>
>>> Move the count outside debugtrace_printk
This checklist is what we use when releasing, branching, and making
tarballs. Right I want to commit an exact copy of the live copy kept
on xenbits outside version control. I am fed up of maintaining this
outside version control, and probably xen.git is the best place to put
it.
I have reviewed
>>> On 05.12.16 at 13:36, wrote:
> This checklist is what we use when releasing, branching, and making
> tarballs. Right I want to commit an exact copy of the live copy kept
> on xenbits outside version control. I am fed up of maintaining this
> outside version control, and probably xen.git is t
> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: 05 December 2016 10:09
> To: Xen-devel
> Cc: Andrew Cooper ; Jan Beulich
> ; Paul Durrant
> Subject: [PATCH 6/8] x86/emul: Support speculative MSR reads
>
> Update the read_msr() hook to take an additio
From: Oleksandr Andrushchenko
Hi, all!
Please find the next version of the ABI for the PV sound
after addressing review comments.
Thank you,
Oleksandr Andrushchenko
Oleksandr Grytsov
Oleksandr Andrushchenko (1):
This is the ABI for the two halves of a para-virtualized sound
driver to
From: Oleksandr Andrushchenko
Signed-off-by: Oleksandr Andrushchenko
Signed-off-by: Oleksandr Grytsov
Signed-off-by: Oleksandr Dmytryshyn
Signed-off-by: Iurii Konovalenko
---
Changes since v1:
* removed __attribute__((__packed__)) from all structures definitions
Changes since v2:
* remove
> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: 05 December 2016 10:10
> To: Xen-devel
> Cc: Andrew Cooper ; Jan Beulich
> ; Paul Durrant
> Subject: [PATCH 7/8] x86/emul: Support CPUID fauilting via a speculative
> MSR read
>
> Use the new speculativ
On 05/12/16 10:16, Tim Deegan wrote:
> At 10:09 + on 05 Dec (1480932564), Andrew Cooper wrote:
>> This shouldn't have been present in c/s 29a57c992 "x86/emul: Rework emulator
>> event injection". It was a leftover from a previous version of the series.
> IMO this hunk was correct in 29a57c992,
On 05/12/16 12:00, Jan Beulich wrote:
On 05.12.16 at 11:09, wrote:
>> @@ -47,6 +49,9 @@ static int read(
>> unsigned int bytes,
>> struct x86_emulate_ctxt *ctxt)
>> {
>> +if ( verbose )
>> +printf("** %s(%u, %p,, %u,)\n", __func__, seg, (void *)offset,
>> bytes);
> The
>>> On 05.12.16 at 11:09, wrote:
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -1319,7 +1319,7 @@ in_longmode(
> uint64_t efer;
>
> if ( !ops->read_msr ||
> - unlikely(ops->read_msr(MSR_EFER, &efer, ctxt) != X86EMUL_OKAY) )
>
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-pvh-intel
testid xen-boot
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
On 05/12/16 11:47, Jan Beulich wrote:
On 05.12.16 at 11:05, wrote:
>> --- a/xen/arch/x86/acpi/cpu_idle.c
>> +++ b/xen/arch/x86/acpi/cpu_idle.c
>> @@ -391,9 +391,9 @@ void mwait_idle_with_hints(unsigned int eax, unsigned
>> int ecx)
>>
>> if ( boot_cpu_has(X86_FEATURE_CLFLUSH_MONITOR)
This run is configured for baseline tests only.
flight 68159 seabios real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68159/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop
On Mon, Dec 05, 2016 at 12:36:12PM +, Ian Jackson wrote:
> This checklist is what we use when releasing, branching, and making
> tarballs. Right I want to commit an exact copy of the live copy kept
> on xenbits outside version control. I am fed up of maintaining this
> outside version control
Hi Stefano,
On 03/12/16 00:46, Stefano Stabellini wrote:
On Fri, 2 Dec 2016, Andre Przywara wrote:
When we receive the maintenance interrupt and we clear the LR of the
vLPI, Xen should re-enable the pLPI.
Given that the state of the LRs is sync'ed before calling gic_interrupt,
we can be sure to
>>> On 05.12.16 at 11:09, wrote:
> Jan: Probably worth waiting to rebase over your changes moving the
> architectrual defines elsewhere
I have no such changes yet; I only recall us discussing this would be
a good thing at some point.
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/em
On 05/12/16 12:28, Jan Beulich wrote:
On 05.12.16 at 12:25, wrote:
>> On 05/12/16 11:18, Jan Beulich wrote:
>> On 05.12.16 at 11:05, wrote:
--- a/xen/arch/x86/crash.c
+++ b/xen/arch/x86/crash.c
@@ -146,9 +146,6 @@ static void nmi_shootdown_cpus(void)
write_atomic
On 05/12/16 10:11, Juergen Gross wrote:
> On 05/12/16 11:05, Andrew Cooper wrote:
>> Barriers are a complicated topic, a common source of confusion in submitted
>> code, and their incorrect use is a common cause of bugs. It *really* doesn't
>> help when Xen's API is the same as Linux, but its ABI
>>> On 05.12.16 at 11:09, wrote:
> @@ -4362,11 +4363,27 @@ x86_emulate(
>
> switch( modrm )
> {
> -#ifdef __XEN__
> -case 0xd1: /* xsetbv */
> -{
> unsigned long cr4;
>
> +case 0xca: /* clac */
> +case 0xcb: /* stac */
> +
On 05/12/16 12:01, David Vrabel wrote:
> On 05/12/16 10:05, Andrew Cooper wrote:
>> + * Loads may be reordered ahead of an unaliasing store.
> It might be useful to summarize what an "unaliasing store" is.
"... ahead of stores, so long as the addresses don't alias" ?
~Andrew
___
Travis discovered arm32 gcov code failed to build because __init was not
defined.
Include init.h explicitly to fix the issue.
Signed-off-by: Wei Liu
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc:
Signed-off-by: Wei Liu
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
---
xen/common/gdbstub.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/xen/common/gdbstub.c b/xen/common/gdbstub.
Hi Oleksandr,
On 02/12/16 16:38, Oleksandr Tyshchenko wrote:
Call irq_get_domain for the IRQ we are interested in
only after making sure that it is the guest IRQ to avoid
ASSERT(test_bit(_IRQ_GUEST, &desc->status)) triggering.
Signed-off-by: Oleksandr Tyshchenko
Signed-off-by: Andrii Anisov
-
On 05/12/16 13:49, Wei Liu wrote:
> Travis discovered arm32 gcov code failed to build because __init was not
> defined.
>
> Include init.h explicitly to fix the issue.
>
> Signed-off-by: Wei Liu
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xe
Hi Oleksandr,
On 02/12/16 16:38, Oleksandr Tyshchenko wrote:
Call irq_get_domain for the IRQ we are interested in
only after making sure that it is the guest IRQ to avoid
ASSERT(test_bit(_IRQ_GUEST, &desc->status)) triggering.
Signed-off-by: Oleksandr Tyshchenko
I forgot to mention that your
On 05/12/16 13:49, Wei Liu wrote:
> Signed-off-by: Wei Liu
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
>>> On 05.12.16 at 14:43, wrote:
> On 05/12/16 12:28, Jan Beulich wrote:
> On 05.12.16 at 12:25, wrote:
>>> On 05/12/16 11:18, Jan Beulich wrote:
>>> On 05.12.16 at 11:05, wrote:
> --- a/xen/arch/x86/smpboot.c
> +++ b/xen/arch/x86/smpboot.c
> @@ -346,7 +346,6 @@ void start_se
On 05/12/16 13:50, Jan Beulich wrote:
On 05.12.16 at 14:43, wrote:
>> On 05/12/16 12:28, Jan Beulich wrote:
>> On 05.12.16 at 12:25, wrote:
On 05/12/16 11:18, Jan Beulich wrote:
On 05.12.16 at 11:05, wrote:
>> --- a/xen/arch/x86/smpboot.c
>> +++ b/xen/arch/x86/smpb
>>> On 05.12.16 at 14:29, wrote:
> On 05/12/16 11:47, Jan Beulich wrote:
> On 05.12.16 at 11:05, wrote:
>>> --- a/xen/arch/x86/acpi/cpu_idle.c
>>> +++ b/xen/arch/x86/acpi/cpu_idle.c
>>> @@ -391,9 +391,9 @@ void mwait_idle_with_hints(unsigned int eax, unsigned
>>> int ecx)
>>>
>>> if (
On Mon, Dec 5, 2016 at 3:50 PM, Julien Grall wrote:
> Hi Oleksandr,
Hi Julien
>
>
> On 02/12/16 16:38, Oleksandr Tyshchenko wrote:
>
>> Call irq_get_domain for the IRQ we are interested in
>> only after making sure that it is the guest IRQ to avoid
>> ASSERT(test_bit(_IRQ_GUEST, &desc->status)
>>> On 05.12.16 at 14:59, wrote:
> On 05/12/16 13:50, Jan Beulich wrote:
> On 05.12.16 at 14:43, wrote:
>>> On 05/12/16 12:28, Jan Beulich wrote:
>>> On 05.12.16 at 12:25, wrote:
> On 05/12/16 11:18, Jan Beulich wrote:
> On 05.12.16 at 11:05, wrote:
>>> --- a/xen/arch/x8
On 05/12/16 11:51, Jan Beulich wrote:
On 05.12.16 at 11:05, wrote:
>> Barriers are a complicated topic, a common source of confusion in submitted
>> code, and their incorrect use is a common cause of bugs. It *really* doesn't
>> help when Xen's API is the same as Linux, but its ABI different
Hi Stefano,
On 01/12/16 21:33, Stefano Stabellini wrote:
On Thu, 1 Dec 2016, Julien Grall wrote:
On 01/12/16 02:07, Stefano Stabellini wrote:
On Fri, 25 Nov 2016, Julien Grall wrote:
Hi Stefano,
Hi,
On 23/11/16 19:55, Stefano Stabellini wrote:
Actually I am thinking that the default valu
On Mon, Dec 5, 2016 at 3:52 PM, Julien Grall wrote:
> Hi Oleksandr,
>
Hi Julien,
>
> On 02/12/16 16:38, Oleksandr Tyshchenko wrote:
>
>> Call irq_get_domain for the IRQ we are interested in
>> only after making sure that it is the guest IRQ to avoid
>> ASSERT(test_bit(_IRQ_GUEST, &desc->status)
According to https://xenbits.xen.org/xsa/ we are in the middle of
4 consecutive Tuesdays of security announcements: XSA-19[1-8]
on Nov. 22, XSA-201 Nov. 29, XSA-199 Dec. 6 and XSA-200 Dec. 13.
The present security policy does not encourage batching of XSAs and
I would like us to consider refining
On 05/12/16 14:03, Jan Beulich wrote:
On 05.12.16 at 14:29, wrote:
>> On 05/12/16 11:47, Jan Beulich wrote:
>> On 05.12.16 at 11:05, wrote:
--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -391,9 +391,9 @@ void mwait_idle_with_hints(unsigned int eax
>>> On 05.12.16 at 15:24, wrote:
> On 05/12/16 14:03, Jan Beulich wrote:
> On 05.12.16 at 14:29, wrote:
>>> On 05/12/16 11:47, Jan Beulich wrote:
>>> On 05.12.16 at 11:05, wrote:
> --- a/xen/arch/x86/acpi/cpu_idle.c
> +++ b/xen/arch/x86/acpi/cpu_idle.c
> @@ -391,9 +391,9 @@ v
From: Oleksandr Tyshchenko
Call irq_get_domain for the IRQ we are interested in
only after making sure that it is the guest IRQ to avoid
ASSERT(test_bit(_IRQ_GUEST, &desc->status)) triggering.
Signed-off-by: Oleksandr Tyshchenko
Signed-off-by: Andrii Anisov
Reviewed-by: Stefano Stabellini
CC:
Introduce CONFIG_LTO in Kconfig. Since this is the last option to be
converted to Kconfig, delete the preceding comment in Rules.mk as well.
Make it depend on BROKEN because it doesn't work at the moment.
Signed-off-by: Wei Liu
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan B
flight 102944 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102944/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 6 xen-boot fail REGR. vs. 102812
Tests which
>>> On 05.12.16 at 15:17, wrote:
> From a security purist point of view, any delay in publication could
> increase the possibility of vulnerabilities being exploited in the
> wild. However, given the significant frequency of publication of XSAs,
> I’d suggest that users failing to keep up with t
>>> On 05.12.16 at 15:39, wrote:
> Introduce CONFIG_LTO in Kconfig. Since this is the last option to be
> converted to Kconfig, delete the preceding comment in Rules.mk as well.
>
> Make it depend on BROKEN because it doesn't work at the moment.
Looks fine except for this one aspect: Is that bro
At the moment this flag is unconditionally set for PVHv2 domains. Note that
using this boot flag requires that the FADT table revision is at least 5 (or any
later version), so bump the current FADT version from 4 to 5 and add two new
fields that will be unused.
Reported-by: Jan Beulich
Signed-off
Hello,
There are a couple of boot flags that should be passed to PVHv2 guests, that
report the lack of VGA and CMOS RTC, and we shouldn't also pass the 8042 flag,
because PVHv2 guests don't have access to such controller. The no CMOS RTC flags
requires that the FADT table is bumped to version 5 at
Update the structure of the FADT table to version 5, and use that version for
PVHv2 guests. Note that HVM guests will continue to use FADT 4.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Ian Jackson
Cc: Wei Liu
Cc: boris.ostrov...@oracle.com
Cc: konrad.w...@oracle.
On 05/12/16 15:04, Roger Pau Monne wrote:
> Signed-off-by: Roger Pau Monné
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Ian Jackson
Cc: Wei Liu
Cc: boris.ostrov...@oracle.com
Cc: konrad.w...@oracle.com
---
Changes since v2:
- Fix usage of ACPI_8042 in the static boot tables.
---
tools/libacpi/acpi2_0.h | 4 ++--
tools/libacpi/stati
PVHv2 guests don't have any VGA card, and as so it must be notified in the FADT.
Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
Reviewed-by: Andrew Cooper
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Ian Jackson
Cc: Wei Liu
Cc: boris.ostrov...@oracle.com
Cc: konrad.w...@oracle.com
---
There's no such controler available for PVHv2 guests.
Signed-off-by: Roger Pau Monné
Reviewed-by: Andrew Cooper
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Ian Jackson
Cc: Wei Liu
Cc: boris.ostrov...@oracle.com
Cc: konrad.w...@oracle.com
---
tools/firmware/hvmloader/util.c | 2 +-
tools/libac
1 - 100 of 195 matches
Mail list logo
