>>> 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. ptrdiff
>>> 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 ot
>>> 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 that
>>> 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 you
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 charac
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 branc
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 s
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:
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,
>
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:
> > >
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 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
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
test-arm64-arm64-xl-
>>> 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 indication
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
test-amd64-i386-xl-qemuu-dmrestr
> 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: e
>>> 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 functio
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.
Si
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 i
>>> 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 itera
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":
> Ii
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 it
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: julien.g
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 side
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.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
>>> 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 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 s
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 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 ge
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 l
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 noth
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 phy
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:
>
> sched/cre
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 spe
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 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
> >> declar
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 have
> -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 ; Stefan
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, _et
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 M
>>> 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 808cff4c2af66af
>>> 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: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 firs
>>> 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
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 b
>>> 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 *v,
>>> 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
___
Xen-devel
>>> 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
___
Xen-deve
>>> 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 is_hv
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 w
>>> 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 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 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 t
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 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")
>
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 view.
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 boot
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. I'd
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 de
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 e
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 is
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.
> >>
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
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 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
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 bv
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 Hell
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
s
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
test-am
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 8ef3a6ec1f6a858bb14c4
71 matches
Mail list logo
