flight 127372 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127372/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64 7 xen-boot fail REGR. vs. 127344
This run is configured for baseline tests only.
flight 75175 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75175/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm
flight 127390 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127390/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 40a7b235e4359b4e2eb4d379d1c543b9cae11346
baseline version:
ovmf
flight 127369 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127369/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-examine 6 xen-installfail pass in 127350
Tests which did not succeed,
This run is configured for baseline tests only.
flight 75173 linux-3.18 real [real]
http://osstest.xensource.com/osstest/logs/75173/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64
Anybody would like to help review this patch?
Thanks,
Joe
On 09/05/2018 02:16 AM, Joe Jin wrote
> xen_swiotlb_{alloc,free}_coherent() actually allocate/free size by order
> but used the required size to check if address is physical contiguous,
On Tue, Sep 4, 2018, 10:29 AM Wei Liu wrote:
> Going through the code, HAP, EPT, PoD and ALTP2M depend on HVM code.
> Put these components under CONFIG_HVM. This further requires putting
> one of the vm event under CONFIG_HVM.
>
> Altp2m requires a bit more attention because its code is embedded
On 07/09/18 11:15, Jan Beulich wrote:
On 06.09.18 at 21:25, wrote:
>> While v0 must be the first allocated vcpu for for_each_vcpu() to work, it
>> isn't a requirement for the threading the vcpu into the linked list, so
>> update
>> the threading code to be more generic, and add a comment
flight 127378 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127378/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf c4709260f62f531eed83673104c7ecd7b6e665b7
baseline version:
ovmf
flight 127364 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127364/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install
fail REGR. vs. 125898
On 07/09/18 09:55, Jan Beulich wrote:
On 06.09.18 at 17:21, wrote:
>> On 06/09/18 09:56, Paul Durrant wrote:
@@ -4390,9 +4411,6 @@ static int hvmop_get_param(
if ( copy_from_guest(, arg, 1) )
return -EFAULT;
-if ( a.index >= HVM_NR_PARAMS )
-
On 07/09/18 17:01, Roger Pau Monné wrote:
> On Wed, Sep 05, 2018 at 07:12:01PM +0100, Andrew Cooper wrote:
>> There are holes in the HVM_PARAM space, some of which are from deprecated
>> parameters, but toolstack and device models currently has (almost) blanket
>> write access.
>>
>> Rearrange
flight 127384 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127384/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
Hello Roger,
in August 2017, I reported a problem with PCI passthrough and MSI
interrupts
(https://lists.xenproject.org/archives/html/xen-devel/2017-08/msg01433.html).
That report lead to some patches for Xen and qemu.
Some weeks ago I tried a quite new version of Xen 4.10.2-pre
On Fri, Sep 07, 2018 at 06:45:00PM +0200, Valentin Vidic wrote:
> Adding a dump_stack in drbd_release gives two possible code paths,
> both from xen_blkback and the first one from workqueue being the
> problematic one:
In fact the first one is the original code path before I modified
blkback.
On 01/08/18 15:31, Jan Beulich wrote:
> In order to be able to wake parked CPUs from default_dead_idle(), the
> function must not itself loop. Move the loop into play_dead(), and use
> play_dead() as well on the AP boot error path.
>
> Furthermore, not the least considering the comment in
> -Original Message-
> From: Stefano Stabellini [mailto:sstabell...@kernel.org]
> Sent: 07 September 2018 17:58
> To: Paul Durrant
> Cc: 'Stefano Stabellini' ; xen-
> de...@lists.xenproject.org; Andrew Cooper ;
> George Dunlap ; Ian Jackson
> ; Jan Beulich ; Julien Grall
> ; Konrad
On Fri, 7 Sep 2018, Paul Durrant wrote:
> > -Original Message-
> > From: Stefano Stabellini [mailto:sstabell...@kernel.org]
> > Sent: 06 September 2018 19:12
> > To: Paul Durrant
> > Cc: xen-devel@lists.xenproject.org; Andrew Cooper
> > ; George Dunlap
> > ; Ian Jackson ; Jan
> > Beulich
On Fri, 7 Sep 2018, Paul Durrant wrote:
> > -Original Message-
> > From: George Dunlap [mailto:george.dun...@citrix.com]
> > Sent: 07 September 2018 16:26
> > To: Roger Pau Monne ; Paul Durrant
> >
> > Cc: 'Stefano Stabellini' ; Wei Liu
> > ; Konrad Rzeszutek Wilk ;
> > Andrew Cooper ;
On 09/07/2018 10:31 AM, Olaf Hering wrote:
> The command 'xl vcpu-set 0 0', issued in dom0, will crash dom0:
>
> BUG: unable to handle kernel NULL pointer dereference at 02d8
> PGD 0 P4D 0
> Oops: [#1] PREEMPT SMP NOPTI
> CPU: 7 PID: 65 Comm: xenwatch Not tainted
Scrubbing pages on initial balloon down can take some time, especially
in nested virtualization case (nested EPT is slow). When HVM/PVH guest is
started with memory= significantly lower than maxmem=, all the extra
pages will be scrubbed before returning to Xen. But since most of them
weren't used
On Fri, Sep 07, 2018 at 03:28:28PM +0200, Lars Ellenberg wrote:
> We don't expose that, no.
> But even if we did, that would not be racefree :-)
>
> The last (or even: any?) "close" of a block device that used to be open
> for WRITE triggeres a udev "change" event, thus a udev run,
> and the
On 31/08/18 07:33, Jan Beulich wrote:
On 30.08.18 at 19:08, wrote:
>> On 30/08/18 15:07, Jan Beulich wrote:
>> On 30.08.18 at 14:31, wrote:
The observant amongst you might realise that this reverts parts of c/s
51ad90aea21c - What can I say? Several years of hindsight is very
On Wed, Sep 05, 2018 at 07:12:03PM +0100, Andrew Cooper wrote:
> The parameter marshalling and xsm checks are common to both the set and get
> paths. Lift all of the common code out into do_hvm_op() and let
> hvmop_{get,set}_param() operate on struct xen_hvm_param directly.
>
> This is somewhat
Juergen Gross writes ("[PATCH] tools: correct tools/tests/depriv/Makefile"):
> tools/tests/depriv/Makefile directly builds the target program from
> its C-source.
Oh. That was not my intent.
> This is problematic when an incremental build is needed
> after a header the program is depending on
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@citrix.com]
> Sent: 07 September 2018 17:19
> To: Paul Durrant
> Cc: George Dunlap ; Roger Pau Monne
> ; 'Stefano Stabellini' ; Wei
> Liu ; Konrad Rzeszutek Wilk
> ; Andrew Cooper
> ; Tim (Xen.org) ; Julien Grall
> ; Jan Beulich
> -Original Message-
> From: Julien Grall [mailto:julien.gr...@arm.com]
> Sent: 06 September 2018 18:28
> To: Andrew Cooper ; Paul Durrant
> ; Xen-devel
> Cc: Jan Beulich ; Wei Liu ; Roger
> Pau Monne ; Stefano Stabellini
>
> Subject: Re: [PATCH 3/5] x86/hvm: Make
>
Paul Durrant writes ("RE: [Xen-devel] [PATCH] tools: specifically enable VirtFS
in Linux QEMU builds"):
> George Dunlap [mailto:george.dun...@citrix.com]
> > Not the least because the dependencies may change. I think adding an
> > "--enable-9pfs" option which will pass on the requisite
On 17/08/18 10:38, Jan Beulich wrote:
On 17.08.18 at 10:59, wrote:
>> On 17/08/2018 08:21, Jan Beulich wrote:
>>> --- a/xen/include/asm-x86/asm_defns.h
>>> +++ b/xen/include/asm-x86/asm_defns.h
>>> @@ -186,6 +186,20 @@ void ret_from_intr(void);
>>> UNLIKELY_END_SECTION "\n"
On 07/09/18 16:53, Jan Beulich wrote:
On 07.09.18 at 17:35, wrote:
>> On 09/07/2018 04:17 PM, Jan Beulich wrote:
>> On 07.09.18 at 15:56, wrote:
On 07/09/18 09:03, Jan Beulich wrote:
On 06.09.18 at 14:08, wrote:
>> @@ -2059,11 +2058,10 @@ csched_dump_pcpu(const struct
On Wed, Sep 05, 2018 at 07:12:02PM +0100, Andrew Cooper wrote:
> These values are set by the toolstack for each create/restore operation, and
> bound by xen{store,console}d before the the guest starts running.
>
> A guest has no reason to modify them at all, and the matching *_PFN parameters
>
On Wed, Sep 05, 2018 at 07:12:01PM +0100, Andrew Cooper wrote:
> There are holes in the HVM_PARAM space, some of which are from deprecated
> parameters, but toolstack and device models currently has (almost) blanket
> write access.
>
> Rearrange hvm_allow_get_param() to have a whitelist of
On 07/09/18 16:47, Jan Beulich wrote:
>>
>> On 07.03.18 at 19:58, wrote:
> Wow, resuming a discussion after a full half year.
What can I say? "Guess roughly when I was told about L1TF?"
As you can see, I did quite literally drop everything and start working
on speculative side-channel
On 25/08/18 01:35, Dario Faggioli wrote:
> Hello,
>
> As anticipated here:
> https://lists.xenproject.org/archives/html/xen-devel/2018-08/msg02052.html
>
> Here's a preliminary version of my work, trying to implement
> core-scheduling in Xen.
>
> First of all, this deals with Credit1 only. I
>>> On 07.09.18 at 17:31, wrote:
> --- a/drivers/xen/mem-reservation.c
> +++ b/drivers/xen/mem-reservation.c
> @@ -14,6 +14,14 @@
>
> #include
> #include
> +#include
> +
> +#ifdef CONFIG_XEN_SCRUB_PAGES_DEFAULT
> +bool __read_mostly xen_scrub_pages = true;
> +#else
> +bool __read_mostly
>>> On 07.09.18 at 17:35, wrote:
> On 09/07/2018 04:17 PM, Jan Beulich wrote:
> On 07.09.18 at 15:56, wrote:
>>> On 07/09/18 09:03, Jan Beulich wrote:
>>> On 06.09.18 at 14:08, wrote:
> @@ -2059,11 +2058,10 @@ csched_dump_pcpu(const struct scheduler *ops, int
> cpu)
> spc
>>> On 07.09.18 at 17:24, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 07 September 2018 15:56
>>
>> >>> On 07.09.18 at 14:36, wrote:
>> >> From: Jan Beulich [mailto:jbeul...@suse.com]
>> >> Sent: 07 September 2018 12:11
>> >>
>> >> >>> On 23.08.18 at 11:47, wrote:
>> >> >
>>> On 07.09.18 at 16:17, wrote:
> On 05/03/18 09:27, Jan Beulich wrote:
> On 27.02.18 at 15:50, wrote:
>>> -compat_create_bounce_frame:
>>> -ASSERT_INTERRUPTS_ENABLED
>>> -mov %fs,%edi
>>> -ASM_STAC
>>> -testb $2,UREGS_cs+8(%rsp)
>>> -jz1f
>>> -
>>> On 07.09.18 at 16:30, wrote:
> On 13/03/18 15:04, Jan Beulich wrote:
> On 07.03.18 at 19:58, wrote:
Wow, resuming a discussion after a full half year.
>>> --- a/xen/arch/x86/msr.c
>>> +++ b/xen/arch/x86/msr.c
>>> @@ -185,6 +185,10 @@ int guest_rdmsr(const struct vcpu *v, uint32_t msr,
On 09/07/2018 04:17 PM, Jan Beulich wrote:
On 07.09.18 at 15:56, wrote:
>> On 07/09/18 09:03, Jan Beulich wrote:
>> On 06.09.18 at 14:08, wrote:
@@ -2059,11 +2058,10 @@ csched_dump_pcpu(const struct scheduler *ops, int
cpu)
spc = CSCHED_PCPU(cpu);
runq =
Scrubbing pages on initial balloon down can take some time, especially
in nested virtualization case (nested EPT is slow). When HVM/PVH guest is
started with memory= significantly lower than maxmem=, all the extra
pages will be scrubbed before returning to Xen. But since most of them
weren't used
When starting QEMU with dm_restrict=1, pre-open the QMP socket before
exec QEMU. That socket will be usefull to findout if QEMU is ready, and
pre-opening it means that libxl can connect to it without waiting for
QEMU to create it.
The pre-openning is conditionnal, based on the use of dm_restrict
The re-implementation is done because we want to be able to send the
file description that QEMU can use to save its state. When QEMU is
restricted, it would not be able to write to a path.
This replace both libxl__qmp_stop() and libxl__qmp_save().
qmp_qemu_check_version() was only used by
This function can be used by user of libxl__spawn_* when they setup a
notification other than xenstore. The parent can already report success
via libxl__spawn_initiate_detach(), this new function can be used for
failure instead of waiting for the timeout.
Signed-off-by: Anthony PERARD
This will be used in a later patch.
Signed-off-by: Anthony PERARD
---
Notes:
v5:
initialise qemu_version struct in libxl__ev_qmp_init
tools/libxl/libxl_internal.h | 7 +++
tools/libxl/libxl_qmp.c | 20
2 files changed, 27 insertions(+)
diff --git
This create an extra step for the two call sites of the function.
Signed-off-by: Anthony PERARD
Reviewed-by: Roger Pau Monné
---
libxl_domain_soft_reset() haven't been tested, as it doesn't appear to
possible to call the function from xl.
---
tools/libxl/libxl_create.c | 30
This is only activated when dm_restrict=1, as explained in the previous
patch "libxl_dm: Pre-open QMP socket for QEMU"
Signed-off-by: Anthony PERARD
Reviewed-by: Roger Pau Monné
---
Notes:
v5:
removed empty success branch in device_model_qmp_cb()
call libxl__ev_qmp_init()
> -Original Message-
> From: George Dunlap [mailto:george.dun...@citrix.com]
> Sent: 07 September 2018 16:26
> To: Roger Pau Monne ; Paul Durrant
>
> Cc: 'Stefano Stabellini' ; Wei Liu
> ; Konrad Rzeszutek Wilk ;
> Andrew Cooper ; Tim (Xen.org)
> ; Julien Grall ; Jan Beulich
> ; Ian
On 09/07/2018 03:57 PM, Roger Pau Monné wrote:
> On Fri, Sep 07, 2018 at 08:35:11AM +, Paul Durrant wrote:
>>> -Original Message-
>>> From: Stefano Stabellini [mailto:sstabell...@kernel.org]
>>> Sent: 06 September 2018 19:12
>>> To: Paul Durrant
>>> Cc: xen-devel@lists.xenproject.org;
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 07 September 2018 15:56
> To: Paul Durrant
> Cc: George Dunlap ; Kevin Tian
> ; xen-devel
> Subject: RE: [PATCH v6 08/14] vtd: add lookup_page method to iommu_ops
>
> >>> On 07.09.18 at 14:36, wrote:
> >>
flight 127373 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127373/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd 7b6d891a9f0e73952e081c2c41469cdeba34eea8
baseline version:
freebsd
>>> On 07.09.18 at 15:56, wrote:
> On 07/09/18 09:03, Jan Beulich wrote:
> On 06.09.18 at 14:08, wrote:
>>> @@ -2059,11 +2058,10 @@ csched_dump_pcpu(const struct scheduler *ops, int
>>> cpu)
>>> spc = CSCHED_PCPU(cpu);
>>> runq = >runq;
>>>
>>> -cpumask_scnprintf(cpustr,
>>> On 07.09.18 at 15:01, wrote:
> On 07/09/18 08:41, Jan Beulich wrote:
> On 06.09.18 at 14:08, wrote:
>>> The format identifier is consistent with Linux. The code is adapted from
>>> bitmap_scn{,list}printf() but cleaned up.
>> Irrespective of this I'm somewhat worried by ...
>>
>>> ---
First step into taking care of the input from QEMU's QMP socket. For
now, we read data and store them in a buffer.
Parsing of the data will be done in the following patches.
Signed-off-by: Anthony PERARD
---
Notes:
v5:
some cleanup
remove read loop that only handled EINTR,
All the functions will be implemented in later patches.
This patch includes the API that libxl can use to send QMP commands to
QEMU.
Signed-off-by: Anthony PERARD
---
Notes:
v5:
some changes in the comment
tools/libxl/libxl_internal.h | 72 +++-
1
Changes in v5:
Plenty of patch have been applied.
Other changes mostly are coding style and other typos.
Some bug fixes.
Details can be found in patch notes.
I have left aside the change to cdrom_insert until I can found what to do
with the userdata lock.
Changes in v4:
This patch will handle messages received, and calls callbacks associated
with the libxl__ev_qmp when the expected response is received.
This also print error messages from QMP on behalf of the callback.
Signed-off-by: Anthony PERARD
---
Notes:
v5:
Adding default:abort() in
The actual sent will be done in a separate patch.
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_internal.h | 3 +++
tools/libxl/libxl_qmp.c | 40 +++-
2 files changed, 42 insertions(+), 1 deletion(-)
diff --git a/tools/libxl/libxl_internal.h
To be able to re-use qmp_prepare_qmp_cmd with libxl__ev_qmp.
Also, add the QMP end of command '\r\n' into the generated string.
Signed-off-by: Anthony PERARD
---
Notes:
v5:
rename qmp_prepare_qmp_cmd to qmp_prepare_cmd
fix coding style
tools/libxl/libxl_qmp.c | 56
The libxl__ev_qmp_* will now send the command to QEMU when the socket is
ready for writes.
Signed-off-by: Anthony PERARD
Reviewed-by: Roger Pau Monné
---
Notes:
v5:
rename buf_fd to send_fd
tools/libxl/libxl_qmp.c | 44 +
1 file changed, 44
This is a first patch to implement libxl__ev_qmp, it only connects to
the QMP socket of QEMU and registers a fd callback that does nothing.
Callback functions will be implemented in following patches.
Signed-off-by: Anthony PERARD
---
Notes:
v5:
nits
use a define instead of
Signed-off-by: Anthony PERARD
---
Notes:
v5:
initialize len and s at declaration time
remove old comment
v4:
simplification of the patch due to use of a single allocated space for
the
receive buffer.
tools/libxl/libxl_qmp.c | 52
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_qmp.c | 41 ++---
1 file changed, 34 insertions(+), 7 deletions(-)
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index ffbc055110..90308b1598 100644
--- a/tools/libxl/libxl_qmp.c
+++
>>> On 07.09.18 at 16:47, wrote:
> On 28/06/18 14:56, Jan Beulich wrote:
> On 28.06.18 at 15:36, wrote:
>>> On 28/06/18 14:00, Jan Beulich wrote:
>>> On 26.06.18 at 15:18, wrote:
> @@ -49,6 +28,18 @@
> #define ARCH_CAPS_RSBA (_AC(1, ULL) << 2)
> #define
On Fri, Sep 07, 2018 at 08:35:11AM +, Paul Durrant wrote:
> > -Original Message-
> > From: Stefano Stabellini [mailto:sstabell...@kernel.org]
> > Sent: 06 September 2018 19:12
> > To: Paul Durrant
> > Cc: xen-devel@lists.xenproject.org; Andrew Cooper
> > ; George Dunlap
> > ; Ian
>>> On 07.09.18 at 14:36, wrote:
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 07 September 2018 12:11
>> To: Paul Durrant
>> Cc: George Dunlap ; Kevin Tian
>> ; xen-devel
>> Subject: Re: [PATCH v6 08/14] vtd: add lookup_page method to iommu_ops
>>
>>
>>> On 07.09.18 at 14:02, wrote:
> On Fri, 2018-09-07 at 03:43 -0600, Jan Beulich wrote:
>> > > > On 03.09.18 at 15:14, wrote:
>> >
>> > This patch removes the redundant save functions and renames the
>> > save_one* to save. It then changes the domain param to vcpu in the
>> > save funcs and
On 28/06/18 14:56, Jan Beulich wrote:
On 28.06.18 at 15:36, wrote:
>> On 28/06/18 14:00, Jan Beulich wrote:
>> On 26.06.18 at 15:18, wrote:
@@ -49,6 +28,18 @@
#define ARCH_CAPS_RSBA(_AC(1, ULL) << 2)
#define ARCH_CAPS_SSB_NO (_AC(1, ULL) <<
On 09/06/2018 01:08 PM, Andrew Cooper wrote:
> This removes all use of keyhandler_scratch as a bounce-buffer for the rendered
> string. In some cases, collapse combine adjacent printk()'s which are writing
> parts of the same line.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
On 09/07/2018 02:56 PM, Andrew Cooper wrote:
>> Then again I wonder whether a special
>> case for CPU masks wouldn't be warranted, making it unnecessary for
>> callers to pass in nr_cpu_ids explicitly.
>
> The only way of special casing is to have a different custom %p
> formatter. All printing
On 07/09/18 16:31, Olaf Hering wrote:
> The command 'xl vcpu-set 0 0', issued in dom0, will crash dom0:
>
> BUG: unable to handle kernel NULL pointer dereference at 02d8
> PGD 0 P4D 0
> Oops: [#1] PREEMPT SMP NOPTI
> CPU: 7 PID: 65 Comm: xenwatch Not tainted
On 13/03/18 15:04, Jan Beulich wrote:
On 07.03.18 at 19:58, wrote:
>> --- a/xen/arch/x86/msr.c
>> +++ b/xen/arch/x86/msr.c
>> @@ -185,6 +185,10 @@ int guest_rdmsr(const struct vcpu *v, uint32_t msr,
>> uint64_t *val)
>> }
>>
>> /* Fallthrough. */
>> +case
On 05/03/18 09:27, Jan Beulich wrote:
On 27.02.18 at 15:50, wrote:
>> -compat_create_bounce_frame:
>> -ASSERT_INTERRUPTS_ENABLED
>> -mov %fs,%edi
>> -ASM_STAC
>> -testb $2,UREGS_cs+8(%rsp)
>> -jz1f
>> -/* Push new frame at registered
On 07/09/18 09:12, Jan Beulich wrote:
On 06.09.18 at 14:08, wrote:
>> --- a/xen/arch/x86/cpu/mcheck/mce.c
>> +++ b/xen/arch/x86/cpu/mcheck/mce.c
>> @@ -535,9 +535,12 @@ void mcheck_cmn_handler(const struct cpu_user_regs
>> *regs)
>> mc_panic("MCE: No CPU found valid MCE, need
On 07/09/18 09:03, Jan Beulich wrote:
On 06.09.18 at 14:08, wrote:
>> @@ -2059,11 +2058,10 @@ csched_dump_pcpu(const struct scheduler *ops, int
>> cpu)
>> spc = CSCHED_PCPU(cpu);
>> runq = >runq;
>>
>> -cpumask_scnprintf(cpustr, sizeof(cpustr), per_cpu(cpu_sibling_mask,
>>
On 09/07/2018 08:21 AM, Juergen Gross wrote:
> Commit 822fb18a82aba ("xen-netfront: wait xenbus state change when load
> module manually") added a new wait queue to wait on for a state change
> when the module is loaded manually. Unfortunately there is no wakeup
> anywhere to stop that waiting.
>
Wei Liu writes ("[PATCH] mkdeb: use compression level 0"):
> This requires calling dpkg-deb directly and pass it -z0.
>
> It reduces the time to run the mkdeb script from 14 seconds to 3
> seconds on my workstation with SSD, from 87s to 15s on a machine
> with HDD. The deb file grows from 49M to
Wei Liu writes ("[PATCH v3 06/16] libxl: don't set PoD target for PV guests"):
> Previously PoD target was unconditionally set for both PV and HVM
> guests, but in fact PoD has always been an HVM (now PVH as well) only
> feature.
Acked-by: Ian Jackson
Am Fri, 7 Sep 2018 09:33:20 -0400
schrieb Boris Ostrovsky :
> what is the purpose of 'xl vcpu-set 0'?
Likely just a script that went wrong. But that command should not break the
dom0.
Olaf
pgpf7yM3gq1fu.pgp
Description: Digitale Signatur von OpenPGP
On 09/07/2018 02:30 AM, Olaf Hering wrote:
> The command 'xl vcpu-set 0 0', issued in dom0, will crash dom0:
>
> BUG: unable to handle kernel NULL pointer dereference at 02d8
> PGD 0 P4D 0
> Oops: [#1] PREEMPT SMP NOPTI
> CPU: 7 PID: 65 Comm: xenwatch Not tainted
On Fri, Sep 07, 2018 at 02:13:48PM +0200, Valentin Vidic wrote:
> On Fri, Sep 07, 2018 at 02:03:37PM +0200, Lars Ellenberg wrote:
> > Very frequently it is *NOT* the "original user", that "still" holds it
> > open, but udev, or something triggered-by-udev.
> >
> > So double-checking the udev
On 07/09/18 08:51, Jan Beulich wrote:
On 06.09.18 at 17:33, wrote:
>> --- a/include/xen/mem-reservation.h
>> +++ b/include/xen/mem-reservation.h
>> @@ -17,12 +17,17 @@
>>
>> #include
>>
>> +#ifdef CONFIG_XEN_SCRUB_PAGES
>> +extern bool xen_scrub_pages;
>> +
>> static inline void
On 07/09/18 08:41, Jan Beulich wrote:
On 06.09.18 at 14:08, wrote:
>> The format identifier is consistent with Linux. The code is adapted from
>> bitmap_scn{,list}printf() but cleaned up.
> Irrespective of this I'm somewhat worried by ...
>
>> --- a/docs/misc/printk-formats.txt
>> +++
On 07/09/18 13:37, George Dunlap wrote:
> On 09/07/2018 11:59 AM, Andrew Cooper wrote:
>> On 07/09/18 11:21, Jan Beulich wrote:
>> On 07.09.18 at 11:57, wrote:
On 07/09/18 09:48, Jan Beulich wrote:
> Rather than blindly dropping the logic, I'd have expected
> for it to be fixed:
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 07 September 2018 12:11
> To: Paul Durrant
> Cc: George Dunlap ; Kevin Tian
> ; xen-devel
> Subject: Re: [PATCH v6 08/14] vtd: add lookup_page method to iommu_ops
>
> >>> On 23.08.18 at 11:47, wrote:
> > This
On 09/07/2018 11:59 AM, Andrew Cooper wrote:
> On 07/09/18 11:21, Jan Beulich wrote:
> On 07.09.18 at 11:57, wrote:
>>> On 07/09/18 09:48, Jan Beulich wrote:
Rather than blindly dropping the logic, I'd have expected
for it to be fixed: Despite the movement into
Commit 822fb18a82aba ("xen-netfront: wait xenbus state change when load
module manually") added a new wait queue to wait on for a state change
when the module is loaded manually. Unfortunately there is no wakeup
anywhere to stop that waiting.
Instead of introducing a new wait queue rename the
On Fri, Sep 07, 2018 at 02:03:37PM +0200, Lars Ellenberg wrote:
> Very frequently it is *NOT* the "original user", that "still" holds it
> open, but udev, or something triggered-by-udev.
>
> So double-checking the udev rules,
> or the "lvm global_filter" settings may help.
> You could instrument
On Wed, Sep 05, 2018 at 06:27:56PM +0200, Valentin Vidic wrote:
> On Wed, Sep 05, 2018 at 12:36:49PM +0200, Roger Pau Monné wrote:
> > On Wed, Aug 29, 2018 at 08:52:14AM +0200, Valentin Vidic wrote:
> > > Switching to closed state earlier can cause the block-drbd
> > > script to fail with 'Device
On Fri, 2018-09-07 at 03:43 -0600, Jan Beulich wrote:
> > > > On 03.09.18 at 15:14, wrote:
> >
> > This patch removes the redundant save functions and renames the
> > save_one* to save. It then changes the domain param to vcpu in the
> > save funcs and adapts print messages in order to match the
>>> On 07.09.18 at 13:15, wrote:
> On Fri, 2018-09-07 at 03:48 -0600, Jan Beulich wrote:
>> > > > On 03.09.18 at 15:14, wrote:
>> >
>> > This patch series addresses the ideea of saving data from a single
>> > vcpu instance.
>> > First it starts by adding *save_one functions, then it introduces
On 07/09/18 13:06, Jiri Slaby wrote:
> On 08/24/2018, 04:26 PM, Boris Ostrovsky wrote:
>> On 08/24/2018 07:26 AM, Juergen Gross wrote:
>>> On 24/08/18 13:12, Jiri Slaby wrote:
On 07/30/2018, 10:18 AM, Xiao Liang wrote:
> On 07/29/2018 11:30 PM, David Miller wrote:
>> From: Xiao Liang
>>> On 23.08.18 at 11:47, wrote:
> The name 'iommu_use_hap_pt' suggests that that P2M table is in use as the
> domain's IOMMU pagetable which, prior to this patch, is not strictly true
> since the macro did not test whether the domain actually has IOMMU
> mappings.
Hmm, I would never have
On Fri, 2018-09-07 at 03:48 -0600, Jan Beulich wrote:
> > > > On 03.09.18 at 15:14, wrote:
> >
> > This patch series addresses the ideea of saving data from a single
> > vcpu instance.
> > First it starts by adding *save_one functions, then it introduces a
> > handler for the
> > new save_one*
On Fri, Sep 07, 2018 at 12:43:09PM +0200, Roger Pau Monné wrote:
> I would prefer if you could avoid open-coding this here, and instead
> use xen_vbd_create or similar. I would also prefer that the call to
> xen_vbd_create in backend_changed was removed and we had a single call
> to xen_vbd_create
On 30/08/18 15:18, Jan Beulich wrote:
On 30.08.18 at 15:06, wrote:
>> This allows all system domids to be printed by name, rather than special
>> casing the idle vcpus alone.
>>
>> Signed-off-by: Andrew Cooper
>> ---
>> CC: George Dunlap
>> CC: Jan Beulich
>> CC: Konrad Rzeszutek Wilk
>>
On 08/24/2018, 04:26 PM, Boris Ostrovsky wrote:
> On 08/24/2018 07:26 AM, Juergen Gross wrote:
>> On 24/08/18 13:12, Jiri Slaby wrote:
>>> On 07/30/2018, 10:18 AM, Xiao Liang wrote:
On 07/29/2018 11:30 PM, David Miller wrote:
> From: Xiao Liang
> Date: Fri, 27 Jul 2018 17:56:08 +0800
flight 127368 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127368/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
>>> On 23.08.18 at 11:47, wrote:
> This patch adds an iommu_op to allow the domain IOMMU reserved ranges to be
> queried by the guest.
>
> NOTE: The number of reserved ranges is determined by system firmware, in
> conjunction with Xen command line options, and is expected to be
>
On 07/09/18 11:21, Jan Beulich wrote:
On 07.09.18 at 11:57, wrote:
>> On 07/09/18 09:48, Jan Beulich wrote:
>>> Rather than blindly dropping the logic, I'd have expected
>>> for it to be fixed: Despite the movement into XEN_DOMCTL_createdomain
>>> there's still a race between ucode updates
1 - 100 of 160 matches
Mail list logo
