On 02.07.19 18:09, Andrew Cooper wrote:
On 28/05/2019 11:32, Juergen Gross wrote:
Instead of dynamically decide whether the previous vcpu was using full
"deciding"
or default GDT just add a percpu variable for that purpose. This at
"was using a full or default GDT, just add"
once removes
flight 138699 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138699/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-thunderx broken
build-amd64-prev 6 xen-bu
To remove a device from a domain, a qmp command is sent to qemu. But it is
handled by qemu asychronously. Even the qmp command is claimed to be done,
the actual handling in qemu side may happen later.
This behavior brings two questions:
1. Attaching a device back to a domain right after detaching t
On 19-07-03 02:29:33, Chaitanya Kulkarni wrote:
> On 7/2/19 5:23 PM, Minwoo Im wrote:
> > On 19-07-02 10:42:30, Chaitanya Kulkarni wrote:
> >> This patch updates the blkdev_reset_zones() with newly introduced
> >> helper function to read the nr_sects from block device's hd_parts with
> >> the help
On 19-07-02 10:42:28, Chaitanya Kulkarni wrote:
> This patch updates the blkdev_nr_zones() with newly introduced helper
> function to read the nr_sects from block device's hd_parts with the
> help if part_nr_sects_read().
It looks good to me.
Reviewed-by: Minwoo Im
_
On 19-07-02 10:42:29, Chaitanya Kulkarni wrote:
> This patch updates the blkdev_report_zone(s)() with newly introduced
> helper function to read the nr_sects from block device's hd_parts with
> the help of part_nr_sects_read().
It looks good to me.
Reviewed-by: Minwoo Im
___
On 19-07-02 10:42:27, Chaitanya Kulkarni wrote:
> This patch introduces helper function to read the number of sectors
> from struct block_device->bd_part member. For more details Please refer
> to the comment in the include/linux/genhd.h for part_nr_sects_read().
Without bd_mutex locked, this help
On 19-07-02 10:42:30, Chaitanya Kulkarni wrote:
> This patch updates the blkdev_reset_zones() with newly introduced
> helper function to read the nr_sects from block device's hd_parts with
> the help of part_nr_sects_read().
Chaitanya,
Are the first three patches split for a special reason? IMHO
flight 138692 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138692/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-arm64-arm64-examine 11 examine-serial/bootloader fail in 138666 pass in
138692
test-amd64-i386-libvirt-qe
On 7/2/19 5:23 PM, Minwoo Im wrote:
> On 19-07-02 10:42:30, Chaitanya Kulkarni wrote:
>> This patch updates the blkdev_reset_zones() with newly introduced
>> helper function to read the nr_sects from block device's hd_parts with
>> the help of part_nr_sects_read().
> Chaitanya,
>
> Are the first th
On 2019/7/3 2:13, Boris Ostrovsky wrote:
On 7/1/19 1:19 AM, Zhenzhong Duan wrote:
Map 'xen_nopv' to 'nopv' and mark 'xen_nopv' obsolete in
kernel-parameters.txt
I am not sure we want patch #3, why not do everything in a single patch?
Thanks for review. I'll fix all those based on your commen
flight 138695 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138695/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-qcow2 15 guest-start/debian.repeat fail REGR. vs.
138618
Tests which did not
flight 138693 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138693/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 21902410ad87aadd3a68ec7ecb4ee11594d9fcb0
baseline version:
ovmf 2603fce126507568f3ce3
flight 138689 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138689/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 6 kernel-build fail REGR. vs. 129313
Tests which did not
On Tue, 2 Jul 2019 at 15:16, Anthony PERARD wrote:
>
> Create a new section with only libxl.
>
> Signed-off-by: Anthony PERARD
>
> ---
> I've created a new section for only libxenlight but if you would
> prefer to add me into TOOLSTACK instead, that might be ok. I just
> don't have much experienc
On 7/1/19 1:19 AM, Zhenzhong Duan wrote:
> Map 'xen_nopv' to 'nopv' and mark 'xen_nopv' obsolete in
> kernel-parameters.txt
I am not sure we want patch #3, why not do everything in a single patch?
>
> Signed-off-by: Zhenzhong Duan
> Cc: Boris Ostrovsky
> Cc: Juergen Gross
> Cc: Stefano Stabel
On 7/1/19 1:19 AM, Zhenzhong Duan wrote:
> PVH guest needs PV extentions to work, so 'nopv' parameter should be
> ignored for PVH but not for HVM guest.
>
> If PVH guest boots up via the Xen-PVH boot entry, xen_pvh is set early,
> we know it's PVH guest and ignore 'nopv' parameter directly.
>
> If
On 17/06/2019 09:12, Jan Beulich wrote:
> Nothing (afaics) guarantees that the original frame's stack pointer
I'd drop the (afaics), because the answer really is nothing.
> points at readable memory. Avoid a (likely nested) crash by attaching
> exception recovery to the read (making it a single r
On 7/1/19 1:19 AM, Zhenzhong Duan wrote:
>
> There is already 'xen_nopv' parameter for XEN platform but not for
> others. 'xen_nopv' can then be removed with this change.
This is no longer true.
-boris
___
Xen-devel mailing list
Xen-devel@lists.xenpr
In the bcache when initializing the cached device we don't actually
use any sort of locking when reading the number of sectors from the
part. This patch updates the cached_dev_init() with newly introduced
helper function to read the nr_sects from block device's hd_parts with
the help of part_nr_sec
This patch updates the blk_trace_setup_lba() with newly introduced
helper function to read the nr_sects from block device's hd_parts with
the help of part_nr_sects_read().
Signed-off-by: Chaitanya Kulkarni
---
kernel/trace/blktrace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --
This patch updates the blkdev_reset_zones() with newly introduced
helper function to read the nr_sects from block device's hd_parts with
the help of part_nr_sects_read().
Signed-off-by: Chaitanya Kulkarni
---
block/blk-zoned.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
This patch updates the blkdev_nr_zones() with newly introduced helper
function to read the nr_sects from block device's hd_parts with the
help if part_nr_sects_read().
Signed-off-by: Chaitanya Kulkarni
---
block/blk-zoned.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/bloc
This patch updates the vbd_sz() macro with newly introduced helper
function to read the nr_sects from block device's hd_parts with the
help of part_nr_sects_read().
Signed-off-by: Chaitanya Kulkarni
---
drivers/block/xen-blkback/common.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
dif
This patch updates the pscsi_get_blocks() with newly introduced helper
function to read the nr_sects from block device's hd_parts with the
help of part_nr_sects_read().
Signed-off-by: Chaitanya Kulkarni
---
drivers/target/target_core_pscsi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
This patch introduces helper function to read the number of sectors
from struct block_device->bd_part member. For more details Please refer
to the comment in the include/linux/genhd.h for part_nr_sects_read().
Signed-off-by: Chaitanya Kulkarni
---
include/linux/blkdev.h | 6 ++
1 file change
Hi,
In the blk-zoned, bcache, f2fs, target-pscsi, xen and blktrace
implementation block device->hd_part->number of sectors field is
accessed directly without any appropriate locking or accessor function.
There is an existing accessor function present in the in
include/linux/genhd.h which should
This patch updates the init_blkz_info() with newly introduced helper
function to read the nr_sects from block device's hd_parts with the
help of part_nr_sects_read().
Signed-off-by: Chaitanya Kulkarni
---
fs/f2fs/super.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/f2fs
This patch updates the blkdev_report_zone(s)() with newly introduced
helper function to read the nr_sects from block device's hd_parts with
the help of part_nr_sects_read().
Signed-off-by: Chaitanya Kulkarni
---
block/blk-zoned.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff
flight 138686 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138686/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 137600
test-armhf-armhf-
branch xen-unstable
xenbranch xen-unstable
job build-amd64-xen-freebsd
testid xen-build-freebsd
Tree: freebsd git://github.com/freebsd/freebsd.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.gi
osstest service owner writes ("[xen-4.7-testing test] 138673: regressions -
trouble: blocked/broken/fail/pass"):
> flight 138673 xen-4.7-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/138673/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> includin
Alignment padding inserts a pseudo block header in front of the allocation,
sets its size field to the pad size and then ORs in 1, which is equivalent
to marking it as a free block, so that xfree() can distinguish it from a
real block header.
This patch simply replaces the magic '1' with the defin
It's not safe to add a region without holding the lock, but this is
exactly what may happen if two threads race entering xmem_pool_alloc()
before the init_region is set.
This patch instead checks for init_region under lock, drops the lock if it
needs to allocate a page, takes the lock, adds the re
This patch adds POOL_POISON to the Kconfig DEBUG options. If set, free
blocks (greater than MIN_BLOCK_SIZE) will be poisoned with 0xAA bytes
which will then be verified when memory is subsequently allocated. This
can help in spotting heap corruption, particularly use-after-free.
Signed-off-by: Pau
These are patches that stem from debugging the problem that led to commit
56ad6265 "x86/msi: fix loop termination condition in
pci_msi_conf_write_intercept()".
Paul Durrant (3):
xmalloc: stop using a magic '1' in alignment padding
xmalloc: don't evaluate ADD_REGION without holding the pool loc
flight 138680 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138680/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 133580
build-armhf-pvops
On 02/07/2019 16:01, Jan Beulich wrote:
> As to scrubbing - what gets brought into cache is, except for a very
> brief moment, the value the scrubbing routine actually stores. There's
> no knowledge to be gained from that by a guest.
Unless we scrub with instructions which have Direct Write semant
On 28/05/2019 11:32, Juergen Gross wrote:
> Instead of dynamically decide whether the previous vcpu was using full
"deciding"
> or default GDT just add a percpu variable for that purpose. This at
"was using a full or default GDT, just add"
> once removes the need for testing vcpu_ids to differ
Stefano Stabellini writes ("Re: [PATCH] MAINTAINERS: Add Anthony as libxl
maintainer"):
> On Tue, 2 Jul 2019, Anthony PERARD wrote:
> > Create a new section with only libxl.
> >
> > Signed-off-by: Anthony PERARD
>
> Acked-by: Stefano Stabellini
Acked-by: Ian Jackson
> > I've created a new s
Subject "load of the GDT"
On 28/05/2019 11:32, Juergen Gross wrote:
> In preparation for core scheduling carve out the GDT related
"for core scheduling, carve"
> functionality (writing GDT related PTEs, loading default of full GDT)
> into sub-functions.
>
> Signed-off-by: Juergen Gross
> Acked-
Am Tue, 2 Jul 2019 15:52:37 +0100
schrieb Anthony PERARD :
> As far as I can tell, this isn't true, scripts are located in /etc.
There was zero response to the other patches.
This one just depends on them.
Olaf
pgpvKOM23D4Cj.pgp
Description: Digitale Signatur von OpenPGP
__
On 27/06/2019 16:23, Jan Beulich wrote:
> While for 32-bit IRTEs I think we can safely continue to assume that the
> writes will translate to a single MOV, the use of CMPXCHG16B is more
The CMPXCHG16B here is stale.
> heavy handed than necessary for the 128-bit form, and the flushing
> didn't get
Hi,
On Fri, Jun 21, 2019 at 11:29:44AM +0200, Olaf Hering wrote:
> Now that scripts are stored in libexec, replace all hardcoded paths to
> use XEN_SCRIPT_DIR to expand the actual location.
As far as I can tell, this isn't true, scripts are located in /etc.
If you want to move the scripts from /
On Fri, Jun 21, 2019 at 11:30:05AM +0200, Olaf Hering wrote:
> xl(1) opens xl.conf in XEN_CONFIG_DIR.
> Substitute this variable also in the man page.
>
> Signed-off-by: Olaf Hering
> ---
> docs/man/xl.1.pod.in | 2 +-
> docs/man/xl.conf.5.pod.in | 2 +-
> 2 files changed, 2 insertions(+),
On 27/06/2019 16:21, Jan Beulich wrote:
> --- a/xen/drivers/passthrough/amd/iommu_intr.c
> +++ b/xen/drivers/passthrough/amd/iommu_intr.c
> @@ -40,12 +40,45 @@ union irte32 {
>
> -#define INTREMAP_TABLE_ORDER1
> +union irte_cptr {
> +const void *ptr;
> +const union irte32 *ptr32;
> +
On 27/06/2019 16:23, Jan Beulich wrote:
> In order for the CPUs to use x2APIC mode, the IOMMU(s) first need to be
> switched into suitable state.
>
> The post-AP-bringup IRQ affinity adjustment is done also for the non-
> x2APIC case.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
__
On Tue, 2 Jul 2019, Anthony PERARD wrote:
> Create a new section with only libxl.
>
> Signed-off-by: Anthony PERARD
Acked-by: Stefano Stabellini
> ---
> I've created a new section for only libxenlight but if you would
> prefer to add me into TOOLSTACK instead, that might be ok. I just
> don't
flight 138704 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138704/
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 1
>>> On 28.05.19 at 12:32, wrote:
> When running an idle vcpu in a non-idle scheduling unit use a specific
> guest idle loop not performing any tasklets, memory scrubbing and
> livepatching in order to avoid populating the cpu caches with memory
> used by other domains (as far as possible). Softirq
On Tue, Jul 02, 2019 at 02:42:33PM +0100, Anthony PERARD wrote:
>Hi,
>
>Thanks for the patch. I've got some comments.
>
>On Tue, Jul 02, 2019 at 03:46:40PM +0800, Chao Gao wrote:
>> To remove a device from a domain, a qmp command is sent to qemu. But it is
>> handled by qemu asychronously. Even the
On 02.07.2019 14:33, Andrew Cooper wrote:
> On 27/06/2019 16:20, Jan Beulich wrote:
>> At the same time restrict its scope to just the single source file
>> actually using it, and abstract accesses by introducing a union of
>> pointers. (A union of the actual table entries is not used to make it
>>
Hi,
Thanks for the patch. I've got some comments.
On Tue, Jul 02, 2019 at 03:46:40PM +0800, Chao Gao wrote:
> To remove a device from a domain, a qmp command is sent to qemu. But it is
> handled by qemu asychronously. Even the qmp command is claimed to be done,
> the actual handling in qemu side
Create a new section with only libxl.
Signed-off-by: Anthony PERARD
---
I've created a new section for only libxenlight but if you would
prefer to add me into TOOLSTACK instead, that might be ok. I just
don't have much experience with the rest of tools/.
---
MAINTAINERS | 7 +++
1 file chan
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: Tuesday, July 2, 2019 7:52 PM
> To: Zhang, Chen
> Cc: Ian Jackson ; Wei Liu ; xen-
> de...@lists.xenproject.org; Zhang Chen
> Subject: Re: [Xen-devel] [PATCH] tools/libxl: Add iothread support for COL
On 02.07.2019 14:09, Andrew Cooper wrote:
> On 27/06/2019 16:19, Jan Beulich wrote:
>> printk("AMD-Vi: IOMMU Extended Features:\n");
>>
>> -while ( feature_str[i] )
>> +#define MASK(fld) ((union amd_iommu_ext_features){ .flds.fld = ~0 }).raw
>> +#define FEAT(fld, str) do { \
>> +if
On 02.07.19 14:48, Jan Beulich wrote:
On 28.05.19 at 12:32, wrote:
In preparation for core scheduling carve out the GDT related
functionality (writing GDT related PTEs, loading default of full GDT)
into sub-functions.
Signed-off-by: Juergen Gross
Acked-by: Jan Beulich
---
RFC V2: split off n
> -Original Message-
> From: Jan Beulich
> Sent: 01 July 2019 12:58
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Paul Durrant
> ; Roger Pau Monne
> ; Wei Liu
> Subject: [PATCH 5/6] x86emul: support INVPCID
>
> Just like for INVLPGA the HVM hook only supports PCID 0 for the
>>> On 28.05.19 at 12:32, wrote:
> In preparation for core scheduling carve out the GDT related
> functionality (writing GDT related PTEs, loading default of full GDT)
> into sub-functions.
>
> Signed-off-by: Juergen Gross
> Acked-by: Jan Beulich
> ---
> RFC V2: split off non-refactoring part
>
On 27/06/2019 16:20, Jan Beulich wrote:
> At the same time restrict its scope to just the single source file
> actually using it, and abstract accesses by introducing a union of
> pointers. (A union of the actual table entries is not used to make it
> impossible to [wrongly, once the 128-bit form g
On 27/06/2019 16:20, Jan Beulich wrote:
> Also introduce a field in struct amd_iommu caching the most recently
> written control register. All writes should now happen exclusively from
> that cached value, such that it is guaranteed to be up to date.
>
> Take the opportunity and add further fields.
On 27/06/2019 16:19, Jan Beulich wrote:
> printk("AMD-Vi: IOMMU Extended Features:\n");
>
> -while ( feature_str[i] )
> +#define MASK(fld) ((union amd_iommu_ext_features){ .flds.fld = ~0 }).raw
> +#define FEAT(fld, str) do { \
> +if ( MASK(fld) & (MASK(fld) - 1) ) \
> +printk
flight 138679 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138679/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-thunderx broken
build-amd64-prev 6 xen-bu
Hi,
Thanks for the patch, I've got plenty of question.
On Mon, Jun 10, 2019 at 04:33:36PM +0800, Zhang Chen wrote:
> From: Zhang Chen
>
> Xen COLO and KVM COLO shared lots of code in Qemu.
> KVM COLO has added the iothread support, so we add it on Xen.
>
> Detail:
> https://wiki.qemu.org/Featu
> -Original Message-
> From: Jan Beulich
> Sent: 02 July 2019 11:50
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Roger Pau Monne
> ; Wei Liu
>
> Subject: Re: [PATCH 1/6] x86emul: generalize wbinvd() hook
>
> On 02.07.2019 12:22, Paul Durrant wrote:
> >> From
On 02.07.2019 12:22, Paul Durrant wrote:
>> From: Jan Beulich
>> Sent: 01 July 2019 12:56
>>
>> @@ -2149,10 +2147,65 @@ static int hvmemul_write_msr(
>>return rc;
>>}
>>
>> -static int hvmemul_wbinvd(
>> +static int hvmemul_cache_op(
>> +enum x86emul_cache_op op,
>> +enum x86_s
> -Original Message-
> From: Jan Beulich
> Sent: 01 July 2019 12:57
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Paul Durrant
> ; Roger Pau Monne
> ; Wei Liu
> Subject: [PATCH 4/6] x86: move INVPCID_TYPE_* to x86-defns.h
>
> This way the insn emulator can then too use the
> -Original Message-
> From: Jan Beulich
> Sent: 01 July 2019 12:57
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Paul Durrant
> ; Roger Pau Monne
> ; Wei Liu
> Subject: [PATCH 3/6] x86emul: generalize invlpg() hook
>
> The hook is already in use for INVLPGA as well. Rename
> -Original Message-
> From: Jan Beulich
> Sent: 01 July 2019 12:57
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Paul Durrant
> ; Roger Pau Monne
> ; Wei Liu
> Subject: [PATCH 2/6] x86emul: support WBNOINVD
>
> Rev 035 of Intel's ISA extensions document does not state inte
On 02/07/2019 11:31, Paul Durrant wrote:
>> -Original Message-
>> From: Andrew Cooper
>> Sent: 02 July 2019 11:29
>> To: Paul Durrant ; xen-devel@lists.xenproject.org
>> Cc: Igor Druzhinin ; Wei Liu ; Jan
>> Beulich ;
>> Roger Pau Monne
>> Subject: Re: [Xen-devel] [PATCH] x86/msi: fix lo
> -Original Message-
> From: Andrew Cooper
> Sent: 02 July 2019 11:29
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Igor Druzhinin ; Wei Liu ; Jan
> Beulich ;
> Roger Pau Monne
> Subject: Re: [Xen-devel] [PATCH] x86/msi: fix loop termination condition in
> pci_msi_conf_write_
On 02/07/2019 10:47, Andrew Cooper wrote:
> On 02/07/2019 10:34, Paul Durrant wrote:
>> The for loop that deals with MSI masking is coded as follows:
>>
>> for ( pos = 0; pos < entry->msi.nvec; ++pos, ++entry )
>>
>> Thus the loop termination condition is dereferencing a struct pointer that
>> is b
On 02.07.19 12:01, Jan Beulich wrote:
On 02.07.2019 11:40, Dario Faggioli wrote:
On Tue, 2019-07-02 at 08:29 +, Jan Beulich wrote:
On 02.07.2019 10:21, Dario Faggioli wrote:
On Tue, 2019-07-02 at 07:54 +, Jan Beulich wrote:
And again - if someone pins every vCPU to a single pCPU, tha
> -Original Message-
> From: Jan Beulich
> Sent: 01 July 2019 12:56
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Paul Durrant
> ; Roger Pau Monne
> ; Wei Liu
> Subject: [PATCH 1/6] x86emul: generalize wbinvd() hook
>
> The hook is already in use for other purposes, and emu
On 02.07.2019 11:40, Dario Faggioli wrote:
> On Tue, 2019-07-02 at 08:29 +, Jan Beulich wrote:
>> On 02.07.2019 10:21, Dario Faggioli wrote:
>>> On Tue, 2019-07-02 at 07:54 +, Jan Beulich wrote:
And again - if someone pins every vCPU to a single pCPU, that
last
such pinn
On 02/07/2019 10:34, Paul Durrant wrote:
> The for loop that deals with MSI masking is coded as follows:
>
> for ( pos = 0; pos < entry->msi.nvec; ++pos, ++entry )
>
> Thus the loop termination condition is dereferencing a struct pointer that
> is being incremented by the loop. However, it is clear
On Tue, 2019-07-02 at 08:29 +, Jan Beulich wrote:
> On 02.07.2019 10:21, Dario Faggioli wrote:
> > On Tue, 2019-07-02 at 07:54 +, Jan Beulich wrote:
> > >
> > > And again - if someone pins every vCPU to a single pCPU, that
> > > last
> > > such pinning operation will be what takes long ter
The for loop that deals with MSI masking is coded as follows:
for ( pos = 0; pos < entry->msi.nvec; ++pos, ++entry )
Thus the loop termination condition is dereferencing a struct pointer that
is being incremented by the loop. However, it is clear from following code
paths in msi_capability_init()
On 02.07.19 11:05, Jan Beulich wrote:
On 02.07.2019 10:44, Juergen Gross wrote:
On 02.07.19 10:27, Jan Beulich wrote:
On 02.07.2019 10:14, Juergen Gross wrote:
On 02.07.19 09:54, Jan Beulich wrote:
And again - if someone pins every vCPU to a single pCPU, that last
such pinning operation will
On 02.07.2019 10:44, Juergen Gross wrote:
> On 02.07.19 10:27, Jan Beulich wrote:
>> On 02.07.2019 10:14, Juergen Gross wrote:
>>> On 02.07.19 09:54, Jan Beulich wrote:
And again - if someone pins every vCPU to a single pCPU, that last
such pinning operation will be what takes long term e
On 02.07.19 10:42, Jan Beulich wrote:
On 28.05.19 at 12:32, wrote:
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -253,7 +253,7 @@ static void sched_spin_unlock_double(spinlock_t *lock1,
spinlock_t *lock2,
static void sched_free_unit(struct sched_unit *unit)
{
struct sche
On 02.07.19 10:55, Jan Beulich wrote:
On 28.05.19 at 12:32, wrote:
Today there are two distinct scenarios for vcpu_create(): either for
creation of idle-domain vcpus (vcpuid == processor) or for creation of
"normal" domain vcpus (including dom0), where the caller selects the
initial processor o
>>> On 28.05.19 at 12:32, wrote:
> Today there are two distinct scenarios for vcpu_create(): either for
> creation of idle-domain vcpus (vcpuid == processor) or for creation of
> "normal" domain vcpus (including dom0), where the caller selects the
> initial processor on a round-robin scheme of the
flight 138678 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138678/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-thunderx broken
build-amd64-prev 6 xen-bu
>>> On 28.05.19 at 12:32, wrote:
> --- a/xen/common/schedule.c
> +++ b/xen/common/schedule.c
> @@ -253,7 +253,7 @@ static void sched_spin_unlock_double(spinlock_t *lock1,
> spinlock_t *lock2,
> static void sched_free_unit(struct sched_unit *unit)
> {
> struct sched_unit *prev_unit;
> -
On 02.07.19 10:27, Jan Beulich wrote:
On 02.07.2019 10:14, Juergen Gross wrote:
On 02.07.19 09:54, Jan Beulich wrote:
And again - if someone pins every vCPU to a single pCPU, that last
such pinning operation will be what takes long term effect. Aiui all
vCPU-s in the unit will then be pinned to
On 02.07.2019 10:14, Juergen Gross wrote:
> On 02.07.19 09:54, Jan Beulich wrote:
>> And again - if someone pins every vCPU to a single pCPU, that last
>> such pinning operation will be what takes long term effect. Aiui all
>> vCPU-s in the unit will then be pinned to that one pCPU, i.e.
>> they'll
On 02.07.2019 10:21, Dario Faggioli wrote:
> On Tue, 2019-07-02 at 07:54 +, Jan Beulich wrote:
>> On 02.07.2019 08:30, Juergen Gross wrote:
>>> On 01.07.19 17:46, Jan Beulich wrote:
Hmm, that's indeed what I was deducing, but how will we sell this
to people actually fiddling with
On Tue, 2019-07-02 at 07:54 +, Jan Beulich wrote:
> On 02.07.2019 08:30, Juergen Gross wrote:
> > On 01.07.19 17:46, Jan Beulich wrote:
> > >
> > > Hmm, that's indeed what I was deducing, but how will we sell this
> > > to people actually fiddling with vCPU affinities? I foresee
> > > getting
On 02.07.19 09:54, Jan Beulich wrote:
On 02.07.2019 08:30, Juergen Gross wrote:
On 01.07.19 17:46, Jan Beulich wrote:
On 01.07.2019 17:10, Juergen Gross wrote:
On 01.07.19 16:08, Jan Beulich wrote:
On 28.05.19 at 12:32, wrote:
@@ -155,8 +156,8 @@ static void nmi_mce_softirq(void)
*
On 02.07.2019 11:01, Jan Beulich wrote:
> On 02.07.2019 09:58, Alexandru Stefan ISAILA wrote:
>>
>>
>> On 01.07.2019 18:53, Jan Beulich wrote:
>>> On 01.07.2019 17:36, Alexandru Stefan ISAILA wrote:
On 01.07.2019 17:55, Jan Beulich wrote:
> On 01.07.2019 16:45, Alexandru Stefan ISAILA wr
On 02.07.2019 09:58, Alexandru Stefan ISAILA wrote:
>
>
> On 01.07.2019 18:53, Jan Beulich wrote:
>> On 01.07.2019 17:36, Alexandru Stefan ISAILA wrote:
>>> On 01.07.2019 17:55, Jan Beulich wrote:
On 01.07.2019 16:45, Alexandru Stefan ISAILA wrote:
> On 01.07.2019 16:13, Jan Beulich wrot
On 01.07.2019 18:53, Jan Beulich wrote:
> On 01.07.2019 17:36, Alexandru Stefan ISAILA wrote:
>> On 01.07.2019 17:55, Jan Beulich wrote:
>>> On 01.07.2019 16:45, Alexandru Stefan ISAILA wrote:
On 01.07.2019 16:13, Jan Beulich wrote:
On 04.06.19 at 13:49, wrote:
>> +if ( !re
On 02.07.2019 08:30, Juergen Gross wrote:
> On 01.07.19 17:46, Jan Beulich wrote:
>> On 01.07.2019 17:10, Juergen Gross wrote:
>>> On 01.07.19 16:08, Jan Beulich wrote:
>>> On 28.05.19 at 12:32, wrote:
> @@ -155,8 +156,8 @@ static void nmi_mce_softirq(void)
> * Set the tmp valu
To remove a device from a domain, a qmp command is sent to qemu. But it is
handled by qemu asychronously. Even the qmp command is claimed to be done,
the actual handling in qemu side may happen later.
This behavior brings two questions:
1. Attaching a device back to a domain right after detaching t
95 matches
Mail list logo
