flight 133640 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133640/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 219e560c20034843ac9917146c60db99bd01b6f4
baseline version:
ovmf
flight 133628 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133628/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-pair 22 guest-migrate/src_host/dst_host fail REGR. vs.
132889
Hi,
Now the whole IO stack is capable of handling multi-page bvec, and it has
been enabled in the normal FS IO path. However, it isn't done for
passthrough IO.
Without enabling multi-bvec for passthough IO, we won't go ahead for
optimizing related IO paths, such as bvec merging, bio_add_pc_page
xen_biovec_phys_mergeable() only needs .bv_page of the 2nd bio bvec
for checking if the two bvecs can be merged, so pass page to
xen_biovec_phys_mergeable() directly.
No function change.
Cc: ris Ostrovsky
Cc: Juergen Gross
Cc: xen-devel@lists.xenproject.org
Cc: Omar Sandoval
Cc: Christoph
For normal filesystem IO, each page is added via blk_add_page(),
in which bvec(page) merge has been handled already, and basically
not possible to merge two adjacent bvecs in one bio.
So not try to merge two adjacent bvecs in blk_queue_split(), also add
check if one page is mergeable to current
flight 133624 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133624/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-arndale 5 host-ping-check-native fail in 133601 pass in
133624
test-armhf-armhf-libvirt-raw
Since the introduction of linear_{read,write}() helpers in 3bdec530a5
(x86/HVM: split page straddling emulated accesses in more cases) the
completion path for IOREQs has been broken: if there is an IOREQ in
progress but hvm_copy_{to,from}_guest_linear() returns HVMTRANS_okay
(e.g. when P2M type of
flight 133622 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133622/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-pair 22 guest-migrate/src_host/dst_host fail REGR.
vs. 130965
Tests
On Fri, 8 Mar 2019, Jan Beulich wrote:
> >>> On 08.03.19 at 16:26, wrote:
> > On 05/03/2019 22:38, Stefano Stabellini wrote:
> >> Hi all,
> >>
> >> This version of the series makes use of the macro suggested by Jan with
> >> few modifications. See each patch for a description of the changes.
> >>
Am Fri, 8 Mar 2019 20:20:59 +0100
schrieb Olaf Hering :
> To reiterate the second paragraph: if a domU uses TSC as primary clock
> source, it is expected that it runs NTP to cover for the resulting
> drift. Therefore this change does no need a knob to turn it on or off.
One interesting aspect
Improve decision when vTSC emulation will be activated for a domU with
tsc_mode=default. The current approach is to compare the cpu_khz value
from two physical hosts. Since this value is not accurate, it can not be
used verbatim to decide if vTSC emulation needs to be enabled. Without
this change
On 2/20/19 11:53 AM, Cornelia Huck wrote:
> On Wed, 20 Feb 2019 02:02:27 +0100
> Philippe Mathieu-Daudé wrote:
>
>> We will reuse this variable in the next patch.
>>
>> Signed-off-by: Philippe Mathieu-Daudé
>> ---
>> hw/char/sclpconsole-lm.c | 7 ---
>> 1 file changed, 4 insertions(+), 3
On 08/03/2019 16:14, Jan Beulich wrote:
On 08.03.19 at 16:18, wrote:
>> On 08/03/2019 14:58, Jan Beulich wrote:
>> On 08.03.19 at 15:25, wrote:
On 08/03/2019 11:55, Jan Beulich wrote:
I like the latter suggestion more. Seems less invasive and prone to
regressions.
Hi,
> It might be possible to rework Dom0 memory allocation to limit the
> damage or even re-order the binary in memory. Amit, could you post the
> full Xen log with earlyprintk enabled?
Please find XEN logs :
[ 229.769854] Starting kernel ...
[ 229.773120]
- UART enabled -
- CPU
Hi Christoph,
On 08/03/2019 15:23, Christoph Hellwig wrote:
On Tue, Mar 05, 2019 at 09:41:46AM +, Julien Grall wrote:
On Xen, dma_addr_t will always be 64-bit while the phys_addr_t will depend
on the MMU type. So we may have phys_addr_t smaller than dma_addr_t from
the kernel point of
On 07/03/2019 06:41, Dan Carpenter wrote:
> The "cpu" variable comes from the sscanf() so Smatch marks it as
> untrusted data. We can't pass a higher value than "nr_cpu_ids" to
> cpu_possible() or it results in an out of bounds access.
>
> Fixes: d68d82afd4c8 ("xen: implement CPU hotplugging")
>
On 08/03/2019 16:58, Jan Beulich wrote:
On 07.01.19 at 13:02, wrote:
>> @@ -202,13 +201,10 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t
>> *val)
>> */
>> #ifdef CONFIG_HVM
>> if ( v == current && is_hvm_domain(d) && v->arch.hvm.flag_dr_dirty )
>> -
>>> On 08.03.19 at 17:49, wrote:
> On Fri, Mar 08, 2019 at 11:26:28AM +0100, Roger Pau Monné wrote:
>> On Thu, Mar 07, 2019 at 11:28:25PM +0100, Marek Marczykowski-Górecki wrote:
>> > Can one HVM domain have multiple stubdomains? If so, it should a be
>> > list, not a single field.
>>
>> Yes, I
>>> On 07.01.19 at 13:02, wrote:
> @@ -202,13 +201,10 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t
> *val)
> */
> #ifdef CONFIG_HVM
> if ( v == current && is_hvm_domain(d) && v->arch.hvm.flag_dr_dirty )
> -rdmsrl(msr, *val);
> -else
> +
>>> On 07.01.19 at 13:02, wrote:
> @@ -1472,10 +1468,7 @@ static int hvm_load_cpu_msrs(struct domain *d,
> hvm_domain_context_t *h)
> return -EOPNOTSUPP;
> /* Checking finished */
>
> -if ( hvm_funcs.load_msr )
> -err = hvm_funcs.load_msr(v, ctxt);
> -
> -for
On Fri, Mar 08, 2019 at 11:26:28AM +0100, Roger Pau Monné wrote:
> On Thu, Mar 07, 2019 at 11:28:25PM +0100, Marek Marczykowski-Górecki wrote:
> > On Thu, Mar 07, 2019 at 03:48:01PM +0100, Roger Pau Monné wrote:
> > > Another option would be to store which domains are given permissions
> > > over
>>> On 07.01.19 at 13:02, wrote:
> --- a/xen/arch/x86/msr.c
> +++ b/xen/arch/x86/msr.c
> @@ -164,6 +164,13 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t
> *val)
>
> break;
>
> +case MSR_IA32_XSS:
> +if ( !is_hvm_domain(d) || !cp->xstate.xsaves )
Why the
>>> On 07.01.19 at 13:02, wrote:
> Currently the value is saved directly in struct hvm_vcpu. This patch simply
> co-locates it with other saved MSR values. No functional change.
>
> Signed-off-by: Paul Durrant
Reviewed-by: Jan Beulich
___
>>> On 07.01.19 at 13:02, wrote:
> ...to avoid the need for a VMCS reload when the value of MSR_IA32_BNDCFGS is
> read by the tool-stack.
Is this a good trade-off? I.e. are tool stack reads at least as frequent as
context switches?
Jan
___
>>> On 07.01.19 at 13:02, wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -308,11 +308,16 @@ int hvm_set_guest_pat(struct vcpu *v, u64 guest_pat)
> return 1;
> }
>
> -bool hvm_set_guest_bndcfgs(struct vcpu *v, u64 val)
> +bool hvm_set_guest_bndcfgs(struct vcpu
Hi,
On 3/8/19 10:10 AM, Amit Tomer wrote:
Yes, you are right. I made a couple of quick fixes for this issue and
another issue raised by Julien during review (the usage of p2m_ram_t).
Amit, if you would like to give it a try I have a work-in-progress
branch with the fixes here:
We did try new
>>> On 08.03.19 at 16:18, wrote:
> On 08/03/2019 14:58, Jan Beulich wrote:
> On 08.03.19 at 15:25, wrote:
>>> On 08/03/2019 11:55, Jan Beulich wrote:
>>>
>>> I like the latter suggestion more. Seems less invasive and prone to
>>> regressions. I'd like to try to implement it. Although I think
>>> On 08.03.19 at 16:36, wrote:
> Jan Beulich writes ("Re: [PATCH v11 5/9] xen/x86: use DECLARE_BOUNDS as
> required"):
>> Ian Jackson 03/07/19 3:44 PM >>>
>> >Jan Beulich writes ("Re: [PATCH v11 5/9] xen/x86: use DECLARE_BOUNDS as
>> >required"):
>> >> I'd like to note though that in the
>>> On 08.03.19 at 16:43, wrote:
> Stefano Stabellini writes ("[PATCH v11 5/9] xen/x86: use DECLARE_BOUNDS as
> required"):
>> free_xenheap_pages(p, PERCPU_ORDER);
>
> JOOI, why does free_xenheap_pages not take a void* ?
It does. It's the const that gets in the way here, not the char. And
>>> On 08.03.19 at 16:26, wrote:
> On 05/03/2019 22:38, Stefano Stabellini wrote:
>> Hi all,
>>
>> This version of the series makes use of the macro suggested by Jan with
>> few modifications. See each patch for a description of the changes.
>>
>> The following changes since commit
Andrew Cooper writes ("Re: SRSL People... [PATCH v11 0/9] misc safety
certification fixes"):
> The rational for this series is to satisfy MISRA. MISRA have said in no
> uncertain terms that all of these tricks are unacceptable, and have
> identified the one acceptable option. By not doing what
Stefano Stabellini writes ("[PATCH v11 5/9] xen/x86: use DECLARE_BOUNDS as
required"):
> Use DECLARE_BOUNDS and the two static inline functions that come with it
> for comparisons and subtractions of:
>
> __2M_rwdata_start, __2M_rwdata_end, __end_vpci_array,
> __start_vpci_array, _stextentry,
> -Original Message-
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: 07 March 2019 14:09
> To: xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; Wei Liu ;
> Ian Jackson
> ; Andrew Cooper ; George
> Dunlap
> ; Jan Beulich ; Julien Grall
> ;
> Konrad Rzeszutek Wilk ;
Jan Beulich writes ("Re: [PATCH v11 9/9] xen: explicit casts when
DECLARE_BOUNDS cannot be used [and 1 more messages]"):
> Ian Jackson 03/07/19 4:26 PM >>>
> >Jan, I'm not sure exactly what you are suggesting. Currently the
> >array has one pointer per element. Are you suggesting it should
Jan Beulich writes ("Re: [PATCH v11 5/9] xen/x86: use DECLARE_BOUNDS as
required"):
> Ian Jackson 03/07/19 3:44 PM >>>
> >Jan Beulich writes ("Re: [PATCH v11 5/9] xen/x86: use DECLARE_BOUNDS as
> >required"):
> >> I'd like to note though that in the first two cases we don't alter the
> >>
Jan Beulich writes ("Re: [PATCH v11 5/9] xen/x86: use DECLARE_BOUNDS as
required"):
> Ian Jackson 03/07/19 3:02 PM
> >Jan, it is quite unfortunate that you are replying to Stefano to
> >disagree with things that Stefano did because I suggested them, rather
> >than replying to my patch comments.
Jan Beulich writes ("Re: [PATCH v11 3/9] xen: introduce DECLARE_BOUNDS"):
> >No. This is not fine. Signed integer subtraction sometimes has UB.
...
> I've spent an hour trying to find the relevant parts of the spec, but I'm
> afraid I've once again failed at finding all necessary pieces.
The
On 05/03/2019 22:38, Stefano Stabellini wrote:
> Hi all,
>
> This version of the series makes use of the macro suggested by Jan with
> few modifications. See each patch for a description of the changes.
>
> The following changes since commit 808cff4c2af66afd61973451aeb7e708732abf90:
>
>
On Tue, Mar 05, 2019 at 09:41:46AM +, Julien Grall wrote:
> On Xen, dma_addr_t will always be 64-bit while the phys_addr_t will depend
> on the MMU type. So we may have phys_addr_t smaller than dma_addr_t from
> the kernel point of view.
How can dma_addr_t on arm have value > 32-bit when
Olaf Hering writes ("Re: [PATCH v2] libxl: prepare environment for
domcreate_stream_done"):
> Am Fri, 8 Mar 2019 14:08:10 +
> schrieb Ian Jackson :
>
> > In fact this is OK because domcreate_stream_done only reads srs->dcs
> > and then does everything with the obtained dcs. But there is
Andrew Cooper writes ("Re: [PATCH v11 1/9] xen: use __UINTPTR_TYPE__ for
uintptr_t"):
> NACK.
>
> Stop messing around with GCC-isms and use the spec-compliant way of
> getting uintptr_t (and others).
>
> #include
If everything is working correctly, stdint.h is provided by the
compiler (eg by
On 08/03/2019 14:58, Jan Beulich wrote:
On 08.03.19 at 15:25, wrote:
>> On 08/03/2019 11:55, Jan Beulich wrote:
>>
>> I like the latter suggestion more. Seems less invasive and prone to
>> regressions. I'd like to try to implement it. Although I think the
>> hypervisor check should be more
flight 133619 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133619/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-xsm broken
Tests which are
On Fri, Mar 08, 2019 at 03:43:18PM +0100, Olaf Hering wrote:
> Am Fri, 8 Mar 2019 14:08:10 +
> schrieb Ian Jackson :
>
> > In fact this is OK because domcreate_stream_done only reads srs->dcs
> > and then does everything with the obtained dcs. But there is nothing
> > there to indicate that
>>> On 08.03.19 at 15:25, wrote:
> On 08/03/2019 11:55, Jan Beulich wrote:
>> Assuming the p2m type change arrives via XEN_DMOP_set_mem_type,
>> I think what we need to do is delay the actual change until no ioreq
>> is pending anymore, kind of like the VM event subsystem delays
>> certain CR and
>>> On 08.03.19 at 14:37, wrote:
> On 08/03/2019 11:55, Jan Beulich wrote:
> On 07.03.19 at 13:46, wrote:
>>> We've noticed that there is still a regression with p2m_ioreq_server P2M
>>> type on master. Since the commit 940faf0279 (x86/HVM: split page
>>> straddling emulated accesses in more
Am Fri, 8 Mar 2019 14:08:10 +
schrieb Ian Jackson :
> In fact this is OK because domcreate_stream_done only reads srs->dcs
> and then does everything with the obtained dcs. But there is nothing
> there to indicate that srs might be mostly uninitialised. Maybe we
> could add a comment there,
On 08/03/2019 11:55, Jan Beulich wrote:
> If so, my first reaction is to blame the kernel module:
> Machine state (of the VM) may not change while processing
> a write, other than to carry out the _direct_ effects of the write. I
> don't think a p2m type change is supposed to be occurring as a
On 05/03/2019 22:38, Stefano Stabellini wrote:
> Use __UINTPTR_TYPE__ to define uintptr_t. A later patch will make use of
> __PTRDIFF_TYPE__ to define ptrdiff_t.
>
> Signed-off-by: Stefano Stabellini
> Reviewed-by: Ian Jackson
> CC: jbeul...@suse.com
> CC: andrew.coop...@citrix.com
> CC:
Olaf Hering writes ("[PATCH v2] libxl: prepare environment for
domcreate_stream_done"):
> The function domcreate_bootloader_done may branch early to
> domcreate_stream_done, in case some error occoured. Here srs->dcs will be
> NULL, which leads to a crash.
Thanks. I think this is OK as far as
On 08/03/2019 11:55, Jan Beulich wrote:
On 07.03.19 at 13:46, wrote:
>> We've noticed that there is still a regression with p2m_ioreq_server P2M
>> type on master. Since the commit 940faf0279 (x86/HVM: split page
> Afaics it's 3bdec530a5. I'm also slightly confused by the use of "still":
>
>>> On 07.03.19 at 23:28, wrote:
> On Thu, Mar 07, 2019 at 03:48:01PM +0100, Roger Pau Monné wrote:
>> Hm, albeit I agree with your analysis, I feel like this proposed
>> solution is kind of a workaround. Given the context, I think the best
>> way to deal with this issue in destroy_irq is to
On Fri, Mar 08, 2019 at 01:24:15PM +0100, Olaf Hering wrote:
> The function domcreate_bootloader_done may branch early to
> domcreate_stream_done, in case some error occoured. Here srs->dcs will be
> NULL, which leads to a crash.
>
> It is unclear what the purpose of that backpointer is. Perhaps
The function domcreate_bootloader_done may branch early to
domcreate_stream_done, in case some error occoured. Here srs->dcs will be
NULL, which leads to a crash.
It is unclear what the purpose of that backpointer is. Perhaps it can be
removed, and domcreate_stream_done could use CONTAINER_OF.
>>> On 08.03.19 at 12:58, wrote:
>
>> On Mar 8, 2019, at 7:11 AM, Jan Beulich wrote:
>>
> George Dunlap 03/07/19 1:02 PM >>>
>>> On 3/7/19 10:34 AM, Jan Beulich wrote:
While I've not observed this myself, gcc 9 (imo validly) reportedly may
complain
trace.c: In
> On Mar 8, 2019, at 7:11 AM, Jan Beulich wrote:
>
George Dunlap 03/07/19 1:02 PM >>>
>> On 3/7/19 10:34 AM, Jan Beulich wrote:
>>> While I've not observed this myself, gcc 9 (imo validly) reportedly may
>>> complain
>>>
>>> trace.c: In function '__trace_hypercall':
>>> trace.c:826:19:
flight 133617 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133617/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 133487
>>> On 07.03.19 at 13:46, wrote:
> We've noticed that there is still a regression with p2m_ioreq_server P2M
> type on master. Since the commit 940faf0279 (x86/HVM: split page
Afaics it's 3bdec530a5. I'm also slightly confused by the use of "still":
Iirc so far I've had only an informal
flight 133614 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133614/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-pair 10 xen-boot/src_host fail REGR. vs. 133580
On Fri, Mar 08, 2019 at 10:22:18AM +0100, Olaf Hering wrote:
> Am Thu, 7 Mar 2019 12:18:20 +
> schrieb Wei Liu :
>
> > That code has been changed quite a bit with migration v2 and COLO. I
> > wouldn't be surprised if some code becomes stale.
>
> Are you ok with just moving that assignment up
Hi Juergen,
On 3/8/19 10:18 AM, Juergen Gross wrote:
On 08/03/2019 11:15, Julien Grall wrote:
Hi Juergen,
On 3/8/19 6:28 AM, Juergen Gross wrote:
On 07/03/2019 19:00, Julien Grall wrote:
Hi Roger,
On 07/03/2019 17:15, Roger Pau Monné wrote:
On Thu, Mar 07, 2019 at 04:36:59PM +, Julien
On Thu, Mar 07, 2019 at 11:28:25PM +0100, Marek Marczykowski-Górecki wrote:
> On Thu, Mar 07, 2019 at 03:48:01PM +0100, Roger Pau Monné wrote:
> > On Thu, Mar 07, 2019 at 01:50:04AM +0100, Marek Marczykowski-Górecki wrote:
> > > On Fri, Feb 22, 2019 at 11:42:22AM +0100, Roger Pau Monné wrote:
> >
On 08/03/2019 11:15, Julien Grall wrote:
> Hi Juergen,
>
> On 3/8/19 6:28 AM, Juergen Gross wrote:
>> On 07/03/2019 19:00, Julien Grall wrote:
>>> Hi Roger,
>>>
>>> On 07/03/2019 17:15, Roger Pau Monné wrote:
On Thu, Mar 07, 2019 at 04:36:59PM +, Julien Grall wrote:
> Hi Roger,
>
Hi Juergen,
On 3/8/19 6:28 AM, Juergen Gross wrote:
On 07/03/2019 19:00, Julien Grall wrote:
Hi Roger,
On 07/03/2019 17:15, Roger Pau Monné wrote:
On Thu, Mar 07, 2019 at 04:36:59PM +, Julien Grall wrote:
Hi Roger,
Thank you for the answer.
On 07/03/2019 16:16, Roger Pau Monné wrote:
Hi,
> Yes, you are right. I made a couple of quick fixes for this issue and
> another issue raised by Julien during review (the usage of p2m_ram_t).
> Amit, if you would like to give it a try I have a work-in-progress
> branch with the fixes here:
We did try new branch with new fixes but we see
Am Thu, 7 Mar 2019 12:18:20 +
schrieb Wei Liu :
> That code has been changed quite a bit with migration v2 and COLO. I
> wouldn't be surprised if some code becomes stale.
Are you ok with just moving that assignment up to avoid the crash?
This should be backported to at least 4.10, older
On 08/03/2019 09:46, Jan Beulich wrote:
Ian Jackson 03/07/19 3:02 PM >>>
>> Stefano Stabellini writes ("Re: [PATCH v11 5/9] xen/x86: use DECLARE_BOUNDS
>> as required"):
>>> On Wed, 6 Mar 2019, Jan Beulich wrote:
Is the line wrapping really needed here?
>>>
>>> It would end at 80
>>> Ian Jackson 03/07/19 3:02 PM >>>
>Stefano Stabellini writes ("Re: [PATCH v11 5/9] xen/x86: use DECLARE_BOUNDS as
>required"):
>> On Wed, 6 Mar 2019, Jan Beulich wrote:
>> > Is the line wrapping really needed here?
>>
>> It would end at 80 characters exactly otherwise. I am happy to do as
>>> Ian Jackson 03/07/19 4:26 PM >>>
>Jan writes:
>
>> I disagree with the comment,
>
>I also disagree with the wording of the comment. It is seriously
>misleading. These symbols do in fact refer to the same object!
>The problem is that the compiler thinks otherwise. You need wording
>like
>>> Ian Jackson 03/07/19 3:44 PM >>>
>Jan Beulich writes ("Re: [PATCH v11 5/9] xen/x86: use DECLARE_BOUNDS as
>required"):
>> I'd like to note though that in the first two cases we don't alter the
>> declared object anyway, but instead a derived one; the declaration
>> should not use const for
>>> Ian Jackson 03/07/19 3:16 PM >>>
>Jan Beulich writes ("Re: [PATCH v11 3/9] xen: introduce DECLARE_BOUNDS"):
>> On 06.03.19 at 21:55, wrote:
>> > On Wed, 6 Mar 2019, Jan Beulich wrote:
>> > uintptr_t is the integer type corresponding to a pointer, so we should
>> > use uintptr_t first.
71 matches
Mail list logo
