On 17/04/18 01:13, Maran Wilson wrote:
> For certain applications it is desirable to rapidly boot a KVM virtual
> machine. In cases where legacy hardware and software support within the
> guest is not needed, Qemu should be able to boot directly into the
> uncompressed Linux kernel binary without t
On 17/04/18 01:13, Maran Wilson wrote:
> The start info structure that is defined as part of the x86/HVM direct boot
> ABI and used for starting Xen PVH guests would be more versatile if it also
> included a way to pass information about the memory map to the guest. This
> would allow KVM guests to
On 17/04/18 01:12, Maran Wilson wrote:
> We need to refactor PVH entry code so that support for other hypervisors
> like Qemu/KVM can be added more easily.
>
> The first step in that direction is to create a new file that will
> eventually hold the Xen specific routines.
>
> Signed-off-by: Maran
On 17/04/18 01:11, Maran Wilson wrote:
> Once hypervisors other than Xen start using the PVH entry point for
> starting VMs, we would like the option of being able to compile PVH entry
> capable kernels without enabling CONFIG_XEN and all the code that comes
> along with that. To allow that, we are
On 17/04/18 01:11, Maran Wilson wrote:
> In order to pave the way for hypervisors other than Xen to use the PVH
> entry point for VMs, we need to factor the PVH entry code into Xen specific
> and hypervisor agnostic components. The first step in doing that, is to
> create a new config option for PV
flight 122337 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122337/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 5e0e476a9542a1f769fd5325c0be2d16d3ad1d42
baseline version:
ovmf d4ee449d1dabee20fc366
Hi Jan
Thank you for pointing out my problem. I will revise that.
Answer the following.
发件人: Jan Beulich
发送时间: 2018年4月16日 19:48
收件人: David Wang
抄送: xen-devel; Fiona Li(BJ-RD)
主题: Re: [PATCH] x86/hpet: add a lock when cpu clear cpumask in
hpet_broadcast_exit();
>>> On 16
> Upstream commit 36104cb9012a82e73c32a3b709257766b16bcd1d fixed that. It
> needs to be added to stable as well.
Thanks for the ptr!
Daniel
signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
flight 122332 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122332/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 122315
test-armhf-armhf-libvirt 14 save
This run is configured for baseline tests only.
flight 74627 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74627/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf d4ee449d1dabee20fc36650545143a5430fa718f
baseline v
For certain applications it is desirable to rapidly boot a KVM virtual
machine. In cases where legacy hardware and software support within the
guest is not needed, Qemu should be able to boot directly into the
uncompressed Linux kernel binary without the need to run firmware.
There already exists
We need to refactor PVH entry code so that support for other hypervisors
like Qemu/KVM can be added more easily.
The first step in that direction is to create a new file that will
eventually hold the Xen specific routines.
Signed-off-by: Maran Wilson
---
arch/x86/platform/pvh/enlighten.c | 5 ++
The start info structure that is defined as part of the x86/HVM direct boot
ABI and used for starting Xen PVH guests would be more versatile if it also
included a way to pass information about the memory map to the guest. This
would allow KVM guests to share the same entry point.
Signed-off-by: Ma
We need to refactor PVH entry code so that support for other hypervisors
like Qemu/KVM can be added more easily.
This patch moves the small block of code used for initializing Xen PVH
virtual machines into the Xen specific file. This initialization is not
going to be needed for Qemu/KVM guests. Mo
We need to refactor PVH entry code so that support for other hypervisors
like Qemu/KVM can be added more easily.
The original design for PVH entry in Xen guests relies on being able to
obtain the memory map from the hypervisor using a hypercall. When we
extend the PVH entry ABI to support other hy
Once hypervisors other than Xen start using the PVH entry point for
starting VMs, we would like the option of being able to compile PVH entry
capable kernels without enabling CONFIG_XEN and all the code that comes
along with that. To allow that, we are moving the PVH code out of Xen and
into files
In order to pave the way for hypervisors other than Xen to use the PVH
entry point for VMs, we need to factor the PVH entry code into Xen specific
and hypervisor agnostic components. The first step in doing that, is to
create a new config option for PVH entry that can be enabled
independently from
For certain applications it is desirable to rapidly boot a KVM virtual
machine. In cases where legacy hardware and software support within the
guest is not needed, Qemu should be able to boot directly into the
uncompressed Linux kernel binary without the need to run firmware.
There already exists
flight 122328 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122328/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 16 guest-start/debian.repeat fail REGR. vs. 122212
Tests which did n
flight 122329 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122329/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf d4ee449d1dabee20fc36650545143a5430fa718f
baseline version:
ovmf 665bfd41ac32b364201c0
flight 122327 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122327/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-debianhvm-amd64 15 guest-saverestore.2 fail REGR. vs.
122317
test-armhf-a
On Sun, Apr 15, 2018 at 4:42 PM, Philippe Mathieu-Daudé wrote:
> It eases code review, unit is explicit.
>
> Patch generated using:
>
> $ git grep -E '(1024|2048|4096|8192|(<<|>>).?(10|20|30))' hw/ include/hw/
>
> and modified manually.
>
> Signed-off-by: Philippe Mathieu-Daudé
> Reviewed-by: G
On Mon, Apr 16, 2018 at 7:46 PM, Razvan Cojocaru
wrote:
> On 04/16/2018 08:47 PM, George Dunlap wrote:
>> On 04/13/2018 03:44 PM, Razvan Cojocaru wrote:
>>> On 04/11/2018 11:04 AM, Razvan Cojocaru wrote:
Debugging continues.
>>>
>>> Finally, the attached patch seems to get the display unstuck
flight 122325 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122325/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 118324
test-armhf-armhf-xl
Yeah, I definitely agree on the idea of expanding the use case to the
general domain where dmabuf sharing is used. However, what you are
targetting with proposed changes is identical to the core design of
hyper_dmabuf.
On top of this basic functionalities, hyper_dmabuf has driver level
inter-doma
On 04/16/2018 08:47 PM, George Dunlap wrote:
> On 04/13/2018 03:44 PM, Razvan Cojocaru wrote:
>> On 04/11/2018 11:04 AM, Razvan Cojocaru wrote:
>>> Debugging continues.
>>
>> Finally, the attached patch seems to get the display unstuck in my
>> scenario, although for one guest I get:
>>
>> (XEN) d2
On 16/04/18 17:34, Tim Deegan wrote:
> Hi,
>
> At 02:43 -0600 on 13 Apr (1523587395), Jan Beulich wrote:
> On 12.04.18 at 20:09, wrote:
>>> For mitigation of Meltdown the current L4 page table is copied to the
>>> cpu local root page table each time a 64 bit pv guest is entered.
>>>
>>> Copyi
On Mon, Apr 16, 2018 at 06:32:26PM +0100, Anthony PERARD wrote:
> -add-fd, to create a fdset which is use later.
> -chardev 'file,path=/dev/fdset/1,append=true', this open a char device
> on the write-end of the pipe, tell qemu that the FD is write-only, and
> not to run truncate on it.
> -mon, jus
Ian Jackson writes:
> Markus Armbruster writes ("Re: [Qemu-devel] [PATCH 08/12] os-posix: Provide
> new -runas : facility"):
>> Ian Jackson writes:
>> > That would defer the getpwnam from argument parsing to os_setup_post.
>> > I think that's undesriable.
>>
>> No argument. But why can't os_p
On 04/13/2018 03:44 PM, Razvan Cojocaru wrote:
> On 04/11/2018 11:04 AM, Razvan Cojocaru wrote:
>> Debugging continues.
>
> Finally, the attached patch seems to get the display unstuck in my
> scenario, although for one guest I get:
>
> (XEN) d2v0 Unexpected vmexit: reason 49
> (XEN) domain_crash
... even if it is not the case for the current code.
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_qmp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 83bd804219..3b167f24dd 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/li
Patches 1 and 3 fix debug build.
Patch 2 add some documentation to libxl_qmp.c.
Patch 4 fix an issue with qmp_next().
Patches 5 and 6 fix save of a VM with a restricted QEMU.
And the last two patchs try to fix the restore path, but it is still WIP.
Checkout the last patch comments for more inform
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_event.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 484f9bab4d..0370b6acdd 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -248,
It check via QMP if QEMU as reach the intended status.
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_internal.h | 3 +++
tools/libxl/libxl_qmp.c | 39
2 files changed, 42 insertions(+)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_qmp.c | 36
1 file changed, 36 insertions(+)
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index d03cb51668..be23ffea6a 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@
In case QEMU have restricted access to the system, open the file for it,
and QEMU will save its state to this file descritor.
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_qmp.c | 38 +-
1 file changed, 37 insertions(+), 1 deletion(-)
diff --git a/tools
Adding the ability to send a file descriptor from libxl to QEMU via the
QMP interface. This will be use with the "add-fd" QMP command.
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_qmp.c | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/tools/libxl/lib
When QEMU is restricted, the qemu on the receiving side cann't write
anything to xenstore once the migration is started. So it cann't tell
libxl that it is ready to continue running the guest.
In order to find out if QEMU is ready, we can issue QMP commands and
check if it respond.
But there is n
In qmp_next(), the inner loop should only try to parse messages from
QMP, if there is more than one.
The handling of the receive buffer ('incomplete'), should be done at the
same scope level as read(). It doesn't need to be handle more that once
after a read.
Before this patch, when on message wh
This patch fix complilation error with #define DEBUG_RECEIVED of the
macro DEBUG_REPORT_RECEIVED.
error: field precision specifier ‘.*’ expects argument of type ‘int’, but
argument 9 has type ‘ssize_t {aka long int}’
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_qmp.c | 2 +-
1 file ch
On 16/04/18 17:52, Mirela Simonovic wrote:
On Mon, Apr 16, 2018 at 4:26 PM, Julien Grall wrote:
Hi Mirela,
On 16/04/18 11:02, Mirela Simonovic wrote:
On Thu, Apr 12, 2018 at 3:31 PM, Julien Grall
wrote:
On 12/04/18 12:33, Mirela Simonovic wrote:
On Wed, Apr 11, 2018 at 4:46 PM, Julien
Markus Armbruster writes ("Re: [Qemu-devel] [PATCH 08/12] os-posix: Provide new
-runas : facility"):
> Ian Jackson writes:
> > That would defer the getpwnam from argument parsing to os_setup_post.
> > I think that's undesriable.
>
> No argument. But why can't os_parse_cmd_args() call getpwnam()
Hi Julien,
On Mon, Apr 16, 2018 at 4:26 PM, Julien Grall wrote:
> Hi Mirela,
>
>
> On 16/04/18 11:02, Mirela Simonovic wrote:
>>
>> On Thu, Apr 12, 2018 at 3:31 PM, Julien Grall
>> wrote:
>>>
>>>
>>>
>>> On 12/04/18 12:33, Mirela Simonovic wrote:
On Wed, Apr 11, 2018 at 4:46 PM, J
On 16/04/18 13:32, Jan Beulich wrote:
On 16.04.18 at 14:18, wrote:
>> On 13/04/18 12:39, Jan Beulich wrote:
>> On 13.04.18 at 13:17, wrote:
On 13/04/18 09:31, Jan Beulich wrote:
On 12.04.18 at 18:55, wrote:
>> do_get_debugreg() has several bugs:
>>
>> * The %c
Ian Jackson writes:
> Thanks for the review. Taking your comments out of order slightly:
>
> Markus Armbruster writes ("Re: [Qemu-devel] [PATCH 08/12] os-posix: Provide
> new -runas : facility"):
>> [change_process_uid] is the only user of @user_pwd, @user_uid, @user_gid.
>>
>> Have you consid
On Mon, Apr 16, 2018 at 09:55:20AM -0600, Jan Beulich wrote:
> >>> On 04.04.18 at 01:01, wrote:
> > From: Suravee Suthikulpanit
> > +/*
> > + * Note: Current max index allowed for physical APIC ID table is 255.
> > + */
>
> This is a single line comment.
>
> > +#define AVIC_PHY_APIC_ID_MAX0
On Tue, Mar 27, 2018 at 11:29:35AM +0100, Ian Jackson wrote:
> (George, CC'ing you wrt your depriv doc patch - see below.)
>
> Anthony PERARD writes ("[RFC 1/4] libxl: Learned to send FD through QMP to
> QEMU"):
> > +/* File descriptor to send to QEMU on the next command */
> > +int fd_to
>>> On 04.04.18 at 01:01, wrote:
> From: Suravee Suthikulpanit
>
> Introduce AVIC base initialization code. This includes:
> * Setting up per-VM data structures.
> * Setting up per-vCPU data structure.
> * Initializing AVIC-related VMCB bit fields.
>
> This patch also introduces a n
Hi,
At 02:43 -0600 on 13 Apr (1523587395), Jan Beulich wrote:
> >>> On 12.04.18 at 20:09, wrote:
> > For mitigation of Meltdown the current L4 page table is copied to the
> > cpu local root page table each time a 64 bit pv guest is entered.
> >
> > Copying can be avoided in cases where the guest
At 09:29 +0100 on 16 Apr (1523870989), Wei Liu wrote:
> Cc Tim
> On Thu, Apr 12, 2018 at 06:04:49AM -0600, Jan Beulich wrote:
> > Older gcc doesn't like "#pragma GCC diagnostic" inside functions.
> >
> > Signed-off-by: Jan Beulich
> >
> > --- a/tools/debugger/kdd/kdd.c
> > +++ b/tools/debugger
On 16/04/18 14:41, Mirela Simonovic wrote:
On Mon, Apr 16, 2018 at 3:14 PM, Julien Grall wrote:
On 12/04/18 22:31, Stefano Stabellini wrote:
On Thu, 12 Apr 2018, Julien Grall wrote:
On 12/04/18 00:46, Stefano Stabellini wrote:
On Wed, 11 Apr 2018, Julien Grall wrote:
On 11/04/18 14:19, Mi
flight 122331 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122331/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
Hi,
I' trying to boot Linux PVH on Xen, which is running inside KVM on AMD
hardware. As soon as secondary CPU is starting, domain crashes.
Strangely, without printing any related messages on the console. The
last message is "x86: Booting SMP configuration:".
This happens for both PVH and HVM with
Hi Mirela,
On 16/04/18 15:06, Mirela Simonovic wrote:
On Mon, Apr 16, 2018 at 1:33 PM, Julien Grall wrote:
On 13/04/18 11:19, Mirela Simonovic wrote:
On Thu, Apr 12, 2018 at 10:43 AM, Julien Grall
On 11/04/18 17:37, Mirela Simonovic wrote:
On Wed, Apr 11, 2018 at 6:02 PM, Julien Grall mail
Hi Oleksandr,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on sound/for-next]
[also build test ERROR on v4.17-rc1 next-20180416]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci
Hello, all!
After discussing xen-zcopy and hyper-dmabuf [1] approaches
it seems that xen-zcopy can be made not depend on DRM core any more
and be dma-buf centric (which it in fact is).
The DRM code was mostly there for dma-buf's FD import/export
with DRM PRIME UAPI and with DRM use-cases in m
Hi Mirela,
On 16/04/18 11:02, Mirela Simonovic wrote:
On Thu, Apr 12, 2018 at 3:31 PM, Julien Grall wrote:
On 12/04/18 12:33, Mirela Simonovic wrote:
On Wed, Apr 11, 2018 at 4:46 PM, Julien Grall
wrote:
On 11/04/18 14:19, Mirela Simonovic wrote:
local_irq_disable();
cp
On 16/04/18 08:24, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Implement essential initialization of the sound driver:
> - introduce required data structures
> - handle driver registration
> - handle sound card registration
> - register sound driver on backend conne
Thanks for the review. Taking your comments out of order slightly:
Markus Armbruster writes ("Re: [Qemu-devel] [PATCH 08/12] os-posix: Provide new
-runas : facility"):
> [change_process_uid] is the only user of @user_pwd, @user_uid, @user_gid.
>
> Have you considered replacing global @user_pwd
Hi Julien,
On Mon, Apr 16, 2018 at 1:33 PM, Julien Grall wrote:
> Hi,
>
>
> On 13/04/18 11:19, Mirela Simonovic wrote:
>>
>> On Thu, Apr 12, 2018 at 10:43 AM, Julien Grall
>> wrote:
>>>
>>>
>>>
>>> On 11/04/18 17:37, Mirela Simonovic wrote:
Hi Julien,
>>>
>>>
>>>
>>> Hi,
>>>
>>> M
This run is configured for baseline tests only.
flight 74626 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74626/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 665bfd41ac32b364201c07dc1c5434432730c034
baseline v
Hi Oleksandr,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on sound/for-next]
[also build test ERROR on v4.17-rc1 next-20180416]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci
Hi Julien, Stefano,
Thanks for the feedback and suggestions.
On Mon, Apr 16, 2018 at 3:14 PM, Julien Grall wrote:
> Hi,
>
>
> On 12/04/18 22:31, Stefano Stabellini wrote:
>>
>> On Thu, 12 Apr 2018, Julien Grall wrote:
>>>
>>> On 12/04/18 00:46, Stefano Stabellini wrote:
On Wed, 11 Apr
On 16/04/18 08:24, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Implement shared buffer handling according to the
> para-virtualized sound device protocol at xen/interface/io/sndif.h:
> - manage buffer memory
> - handle granted references
> - handle page directories
>
flight 122322 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122322/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-win7-amd64 broken in 122315
Tests whi
Jan Beulich writes ("Re: [PATCH] tools/kdd: silence gcc 8 warning a different
way"):
> And I'm not overly happy about it, but couldn't think of a better way
> without disabling said warning (or -Werror) altogether for the CU. If
> Ian's sketched out approach worked, I'd be quite happy to drop the
On 04/13/2018 06:11 PM, Laura Abbott wrote:
> There's an ongoing effort to remove VLAs[1] from the kernel to eventually
> turn on -Wvla. The few VLAs in use have an upper bound based on a size
> of 64K. This doesn't produce an excessively large stack so just switch
> the upper bound.
>
> [1] https:
>>> On 03.04.18 at 17:54, wrote:
> Commit 0d31d16 (x86/setup: do not relocate Xen over current Xen image
> placement) disallowed src/dst images overlaps when relocating Xen image.
> Though it deliberately allowed destination region between __image_base__
> and (__image_base__ + XEN_IMG_OFFSET) ove
On Wed, 2018-04-11 at 13:25 +0100, George Dunlap wrote:
> There are a lot of places which release a lock before calling
> vcpu_sleep_nosync(), which then just grabs the lock again. This is
> not only a waste of time, but leads to more code duplication (since
> you have to copy-and-paste recipes ra
Hi,
On 12/04/18 22:31, Stefano Stabellini wrote:
On Thu, 12 Apr 2018, Julien Grall wrote:
On 12/04/18 00:46, Stefano Stabellini wrote:
On Wed, 11 Apr 2018, Julien Grall wrote:
On 11/04/18 14:19, Mirela Simonovic wrote:
Freeing percpu area is done when a non-boot CPU is disabled upon
suspend.
On 16/04/18 08:24, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Handle Xen event channels:
> - create for all configured streams and publish
> corresponding ring references and event channels in Xen store,
> so backend can connect
> - implement event channels int
>>> On 15.04.18 at 22:15, wrote:
> (XEN) *** DOUBLE FAULT ***
> (XEN) [ Xen-4.11-unstable x86_64 debug=y Not tainted ]
> (XEN) CPU:0
> (XEN) RIP:e008:[] search_pre_exception_table+0/0x54
> (XEN) RFLAGS: 00010046 CONTEXT: hypervisor
> (XEN) rax: rbx:
On 16/04/18 08:24, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Read configuration values from Xen store according
> to xen/interface/io/sndif.h protocol:
> - introduce configuration structures for different
> components, e.g. sound card, device, stream
> - read PCM
On Mon, Apr 16, 2018 at 06:00:37AM -0600, Jan Beulich wrote:
> >>> On 16.04.18 at 12:33, wrote:
> > On Thu, Apr 12, 2018 at 06:04:49AM -0600, Jan Beulich wrote:
> >> Older gcc doesn't like "#pragma GCC diagnostic" inside functions.
> >>
> >> Signed-off-by: Jan Beulich
> >>
> >> --- a/tools/debu
On Fri, 2018-04-13 at 12:11 +0200, Mirela Simonovic wrote:
> Hi Dario,
>
Hi,
> On Thu, Apr 12, 2018 at 6:49 PM, Dario Faggioli
> wrote:
> No worries, my commit message should be more understandable and your
> answer helps me identify what's unclear. I'll try to explain below.
>
> This is about
>>> On 16.04.18 at 14:18, wrote:
> On 13/04/18 12:39, Jan Beulich wrote:
> On 13.04.18 at 13:17, wrote:
>>> On 13/04/18 09:31, Jan Beulich wrote:
>>> On 12.04.18 at 18:55, wrote:
> do_get_debugreg() has several bugs:
>
> * The %cr4.de condition is inverted. %dr4/5 should be
On 16/04/18 08:24, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Introduce skeleton of the para-virtualized Xen sound
> frontend driver.
>
> Initial handling for Xen bus states: implement
> Xen bus state machine for the frontend driver according to
> the state diagram and re
On Mon, Apr 16, 2018 at 2:56 PM, Juergen Gross wrote:
> On 16/04/18 13:54, Jan Beulich wrote:
> On 16.04.18 at 13:52, wrote:
>> On 16.04.18 at 13:29, wrote:
From: Oleksandr Tyshchenko
The "end" address must be rounded down before shifting,
otherwise we will insert wr
On 13/04/18 12:39, Jan Beulich wrote:
On 13.04.18 at 13:17, wrote:
>> On 13/04/18 09:31, Jan Beulich wrote:
>> On 12.04.18 at 18:55, wrote:
do_get_debugreg() has several bugs:
* The %cr4.de condition is inverted. %dr4/5 should be accessible only
when
%cr4.d
flight 74625 distros-debian-sid real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74625/
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-
>>> On 16.04.18 at 12:33, wrote:
> On Thu, Apr 12, 2018 at 06:04:49AM -0600, Jan Beulich wrote:
>> Older gcc doesn't like "#pragma GCC diagnostic" inside functions.
>>
>> Signed-off-by: Jan Beulich
>>
>> --- a/tools/debugger/kdd/kdd.c
>> +++ b/tools/debugger/kdd/kdd.c
>> @@ -695,10 +695,10 @@ s
On 13/04/18 14:01, Andrew Cooper wrote:
> On 13/04/18 12:49, Jan Beulich wrote:
>> 1: correct ordering of operations during S3 resume
>> 2: suppress BTI mitigations around S3 suspend/resume
>> 3: check feature flags after resume
>>
>> Signed-off-by: Jan Beulich
>
> Acked-by: Andrew Cooper
>
Re
On 16/04/18 13:54, Jan Beulich wrote:
On 16.04.18 at 13:52, wrote:
> On 16.04.18 at 13:29, wrote:
>>> From: Oleksandr Tyshchenko
>>>
>>> The "end" address must be rounded down before shifting,
>>> otherwise we will insert wrong page range to a heap if address isn't
>>> page aligned.
>>>
>>> On 16.04.18 at 13:52, wrote:
On 16.04.18 at 13:29, wrote:
>> From: Oleksandr Tyshchenko
>>
>> The "end" address must be rounded down before shifting,
>> otherwise we will insert wrong page range to a heap if address isn't
>> page aligned.
>>
>> It seems that a copy-paste mistake took
>>> On 16.04.18 at 13:29, wrote:
> From: Oleksandr Tyshchenko
>
> The "end" address must be rounded down before shifting,
> otherwise we will insert wrong page range to a heap if address isn't
> page aligned.
>
> It seems that a copy-paste mistake took place in the following commit:
> 0c12972e3
>>> On 16.04.18 at 10:00, wrote:
> By the hpet_get_channel(), cpus share an in-use channel somtime.
> So, core shouldn't clear cpumask while others are getting first
> cpumask. If core zero and core one share an channel, the cpumask
> is 0x3. Core zero clear cpumask between core one executing
> cp
On 12/04/18 18:55, Andrew Cooper wrote:
> At this point, I think these patches are plausible candidates for inclusion
> into 4.11. Whether they want backporting is a slightly harder matter, as
> these patches necesserily alter some error values for the get/set_debug_reg()
> hypercalls.
>
> If how
On 16/04/18 12:56, Andrew Cooper wrote:
> The behaviour of reserved bits in MSR_PRED_CMD changed between beta and
> production microcode, and now raises a #GP fault for set reserved bits. The
> AMD spec for future hardware also specifies this behaviour.
>
> Signed-off-by: Andrew Cooper
Release-a
flight 122324 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122324/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 665bfd41ac32b364201c07dc1c5434432730c034
baseline version:
ovmf b85b20fba42e25ff658ed
Hi,
On 13/04/18 11:19, Mirela Simonovic wrote:
On Thu, Apr 12, 2018 at 10:43 AM, Julien Grall wrote:
On 11/04/18 17:37, Mirela Simonovic wrote:
Hi Julien,
Hi,
May I ask you to configure your mail client to use > for quoting and use
plain text? Otherwise, this is going to be really diff
From: Oleksandr Tyshchenko
The "end" address must be rounded down before shifting,
otherwise we will insert wrong page range to a heap if address isn't
page aligned.
It seems that a copy-paste mistake took place in the following commit:
0c12972e34b20a26f2b42044b98bf12db7ed62b6
xen/mm: Switch som
>>> On 16.04.18 at 13:19, wrote:
> On 16/04/18 12:12, Jan Beulich wrote:
> On 16.04.18 at 12:56, wrote:
>>> The behaviour of reserved bits in MSR_PRED_CMD changed between beta and
>>> production microcode, and now raises a #GP fault for set reserved bits.
>> Interesting - quite unfortunate a
On 16/04/18 12:12, Jan Beulich wrote:
On 16.04.18 at 12:56, wrote:
>> The behaviour of reserved bits in MSR_PRED_CMD changed between beta and
>> production microcode, and now raises a #GP fault for set reserved bits.
> Interesting - quite unfortunate a change. Plus - I can't find where this i
Wei Liu writes ("Re: [PATCH] tools/kdd: silence gcc 8 warning a different way"):
> On Thu, Apr 12, 2018 at 06:04:49AM -0600, Jan Beulich wrote:
> > Older gcc doesn't like "#pragma GCC diagnostic" inside functions.
Surely this commit message should refer to the previous commit ?
I reviewed the pr
>>> On 16.04.18 at 12:56, wrote:
> The behaviour of reserved bits in MSR_PRED_CMD changed between beta and
> production microcode, and now raises a #GP fault for set reserved bits.
Interesting - quite unfortunate a change. Plus - I can't find where this is
being
said.
> The AMD spec for future
The behaviour of reserved bits in MSR_PRED_CMD changed between beta and
production microcode, and now raises a #GP fault for set reserved bits. The
AMD spec for future hardware also specifies this behaviour.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Juergen Gross
This wants backport
On Thu, Apr 12, 2018 at 06:04:49AM -0600, Jan Beulich wrote:
> Older gcc doesn't like "#pragma GCC diagnostic" inside functions.
>
> Signed-off-by: Jan Beulich
>
> --- a/tools/debugger/kdd/kdd.c
> +++ b/tools/debugger/kdd/kdd.c
> @@ -695,10 +695,10 @@ static void kdd_handle_read_ctrl(kdd_sta
>
>>> On 13.04.18 at 19:57, wrote:
> On Fri, Apr 13, 2018 at 09:57:25AM -0600, Jan Beulich wrote:
>> >>> On 30.03.18 at 08:59, wrote:
>> > This patch is to backport the patch below from linux kernel.
>> >
>> > commit 30ec26da9967d0d785abc24073129a34c3211777
>> > Author: Ashok Raj
>> >
Ian Jackson writes ("Re: osstest planned outage consultation"):
> We are now planning to do this work on April 19th-21st. osstest will
> be shut down some time on the 17th/18th to let it drain its queue.
Reminder: I will stop it staring on new flights, some time tomorrow.
Ian.
_
>>> On 16.04.18 at 08:20, wrote:
> On Fri, Apr 13, 2018 at 09:49:17AM -0600, Jan Beulich wrote:
> On 30.03.18 at 08:59, wrote:
>>> +static int do_microcode_update(void *_info)
>>> +{
>>> +struct microcode_info *info = _info;
>>> +int error, ret = 0;
>>> +
>>> +error = __wait_for_c
1 - 100 of 113 matches
Mail list logo
