flight 157018 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157018/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf e9d62effa37ea13fe04fc89b21d2de7776f183a2
baseline version:
ovmf 388f9a9355ae7ab95a34a
flight 156996 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156996/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
On 25/11/2020 00:32, Miguel Ojeda wrote:
> I have said *authoring* lines of *this* kind takes a minute per line.
> Specifically: lines fixing the fallthrough warning mechanically and
> repeatedly where the compiler tells you to, and doing so full-time for
> a month.
> It is useful since it makes i
On 24/11/2020 21:25, Kees Cook wrote:
> I still think this isn't right -- it's a case statement that runs off
> the end without an explicit flow control determination.
Proves too much — for instance
case foo:
case bar:
thing;
break;
doesn't require a fallthrough; after cas
On Wed, Nov 25, 2020 at 10:57:31AM -0800, Stefano Stabellini wrote:
> On Tue, 24 Nov 2020, Elliott Mitchell wrote:
> > My testing section for Xen is:
> > xen_hypervisor /boot/xen-4.14-arm64.efi
> > xen_module /boot/vmlinuz-5.8.10-2rp4-6.1.7
> > root=UUID=01234567-dead-beef-d13d-456789abcde
flight 156994 qemu-mainline real [real]
flight 157019 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/156994/
http://logs.test-lab.xenproject.org/osstest/logs/157019/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
Hi Stefano,
> -Original Message-
> From: Stefano Stabellini
> Sent: 2020年11月26日 8:00
> To: Wei Chen
> Cc: Julien Grall ; Penny Zheng ; xen-
> de...@lists.xenproject.org; sstabell...@kernel.org; Andre Przywara
> ; Bertrand Marquis ;
> Kaly Xin ; nd
> Subject: RE: [PATCH] xen/arm: Add Cor
On Mon, Nov 16, 2020 at 03:57:52PM +0100, Christoph Hellwig wrote:
> set_blocksize is used by file systems to use their preferred buffer cache
> block size. Block drivers should not set it.
>
> Signed-off-by: Christoph Hellwig
Acked-by: Minchan Kim
Thanks.
> ---
> drivers/block/zram/zram_drv
On Mon, Nov 16, 2020 at 03:57:51PM +0100, Christoph Hellwig wrote:
> The zram claim mechanism was added to ensure no new opens come in
> during teardown. But the proper way to archive that is to call
> del_gendisk first, which takes care of all that. Once del_gendisk
> is called in the right plac
On Wed, 25 Nov 2020, Nick Desaulniers wrote:
> On Wed, Nov 25, 2020 at 1:33 PM Finn Thain wrote:
> >
> > Or do you think that a codebase can somehow satisfy multiple checkers
> > and their divergent interpretations of the language spec?
>
> Have we found any cases yet that are divergent? I d
On Tue, 24 Nov 2020, Stefano Stabellini wrote:
> Allow failure for these jobs. Currently they fail because hvmloader
> doesn't build with musl. The failures don't block the pipeline.
>
> Signed-off-by: Stefano Stabellini
> ---
> This patch is probably required:
> https://github.com/alpinelinux/a
Resuming this old thread.
On Fri, 13 Nov 2020, Wei Chen wrote:
> > Hi,
> >
> > On 09/11/2020 08:21, Penny Zheng wrote:
> > > CNTVCT_EL0 or CNTPCT_EL0 counter read in Cortex-A73 (all versions)
> > > might return a wrong value when the counter crosses a 32bit boundary.
> > >
> > > Until now, there
flight 156992 xen-unstable real [real]
flight 157014 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/156992/
http://logs.test-lab.xenproject.org/osstest/logs/157014/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
On Wed, 25 Nov 2020, Nick Desaulniers wrote:
> On Wed, Nov 25, 2020 at 1:33 PM Finn Thain
> wrote:
> >
> > Or do you think that a codebase can somehow satisfy multiple checkers
> > and their divergent interpretations of the language spec?
>
> Have we found any cases yet that are divergent? I d
flight 157012 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157012/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 388f9a9355ae7ab95a34ac2e9a3c608caf11b74a
baseline version:
ovmf e7bd0dd26db7e56aa8ca7
flight 157000 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157000/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
On Wed, Nov 25, 2020 at 1:33 PM Finn Thain wrote:
>
> Or do you think that a codebase can somehow satisfy multiple checkers and
> their divergent interpretations of the language spec?
Have we found any cases yet that are divergent? I don't think so. It
sounds to me like GCC's cases it warns for
On Wed, Nov 25, 2020 at 8:24 AM Jakub Kicinski wrote:
>
> Applying a real patch set and then getting a few follow ups the next day
> for trivial coding things like fallthrough missing or static missing,
> just because I didn't have the full range of compilers to check with
> before applying makes
On Wed, 25 Nov 2020, Nick Desaulniers wrote:
> So developers and distributions using Clang can't have
> -Wimplicit-fallthrough enabled because GCC is less strict (which has
> been shown in this thread to lead to bugs)? We'd like to have nice
> things too, you know.
>
Apparently the GCC devel
On Wed, 25 Nov 2020, Rahul Singh wrote:
> The NS16550 driver is assuming that NS16550 PCI card are usable if the
> architecture supports PCI (i.e. CONFIG_HAS_PCI=y). However, the code is
> very x86 focus and will fail to build on Arm (/!\ it is not all the
> errors):
>
> ns16550.c: In function ‘ns
On Wed, 25 Nov 2020, Rahul Singh wrote:
> If mem-sharing, mem-paging, or log-dirty functionality is not enabled
> for architecture when HAS_PCI is enabled, the compiler will throw an
> error.
>
> Move code to x86 specific file to fix compilation error.
>
> Also, modify the code to use likely() in
On Wed, 25 Nov 2020, Rahul Singh wrote:
> passthrough/pci.c file is common for all architecture, but there is x86
> specific code in this file.
>
> Move x86 specific code to the drivers/passthrough/io.c file to avoid
> compilation error for other architecture.
>
> As drivers/passthrough/io.c is c
On Tue, Nov 24, 2020 at 11:05:35PM -0800, James Bottomley wrote:
> Now, what we have seems to be about 6 cases (at least what's been shown
> in this thread) where a missing break would cause potentially user
> visible issues. That means the value of this isn't zero, but it's not
> a no-brainer mas
The function can be replaced with accel_available("xen").
Signed-off-by: Eduardo Habkost
---
Cc: Paolo Bonzini
Cc: qemu-de...@nongnu.org
Cc: Stefano Stabellini
Cc: Anthony Perard
Cc: Paul Durrant
Cc: xen-devel@lists.xenproject.org
Cc: Richard Henderson
Cc: Claudio Fontana
Cc: Roman Bolshako
Hello,
On Wed, Nov 25, 2020 at 05:45:15PM +0100, Christoph Hellwig wrote:
> On Tue, Nov 24, 2020 at 04:18:49PM -0500, Tejun Heo wrote:
> > Hello,
> >
> > Please see lkml.kernel.org/r/x708btj5njtbc...@mtj.duckdns.org for a few nits
> > on the previous version.
>
> Thanks, I've addressed the mappi
Hello,
On Wed, Nov 25, 2020 at 05:29:26PM +0100, Christoph Hellwig wrote:
> > I was wondering whether losing the stale bdev flushing in bd_acquire() would
> > cause user-visible behavior changes but can't see how it would given that
> > userland has no way of holding onto a specific instance of bl
On Wed, 25 Nov 2020, Jan Beulich wrote:
> On 25.11.2020 13:15, Julien Grall wrote:
> > On 23/11/2020 14:23, Jan Beulich wrote:
> >> All of the array allocations in grant_table_init() can exceed a page's
> >> worth of memory, which xmalloc()-based interfaces aren't really suitable
> >> for after boo
On Tue, Nov 24, 2020 at 9:17 PM Elliott Mitchell wrote:
>
> On Tue, Nov 24, 2020 at 08:45:32PM -0800, Roman Shaposhnik wrote:
> > On Tue, Nov 24, 2020 at 8:41 PM Elliott Mitchell wrote:
> > >
> > > On Tue, Nov 24, 2020 at 08:01:32PM -0800, Roman Shaposhnik wrote:
> > > > On Tue, Nov 24, 2020 at 7
flight 157009 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157009/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On Tue, 24 Nov 2020, Elliott Mitchell wrote:
> On Tue, Nov 24, 2020 at 08:45:32PM -0800, Roman Shaposhnik wrote:
> > On Tue, Nov 24, 2020 at 8:41 PM Elliott Mitchell wrote:
> > >
> > > On Tue, Nov 24, 2020 at 08:01:32PM -0800, Roman Shaposhnik wrote:
> > > > On Tue, Nov 24, 2020 at 7:37 PM Elliott
Hello Julien,
> On 25 Nov 2020, at 6:16 pm, Rahul Singh wrote:
>
> The NS16550 driver is assuming that NS16550 PCI card are usable if the
> architecture supports PCI (i.e. CONFIG_HAS_PCI=y). However, the code is
> very x86 focus and will fail to build on Arm (/!\ it is not all the
> errors):
>
The NS16550 driver is assuming that NS16550 PCI card are usable if the
architecture supports PCI (i.e. CONFIG_HAS_PCI=y). However, the code is
very x86 focus and will fail to build on Arm (/!\ it is not all the
errors):
ns16550.c: In function ‘ns16550_init_irq’:
ns16550.c:726:21: error: implicit d
If mem-sharing, mem-paging, or log-dirty functionality is not enabled
for architecture when HAS_PCI is enabled, the compiler will throw an
error.
Move code to x86 specific file to fix compilation error.
Also, modify the code to use likely() in place of unlikley() for each
condition to make code m
passthrough/pci.c file is common for all architecture, but there is x86
specific code in this file.
Move x86 specific code to the drivers/passthrough/io.c file to avoid
compilation error for other architecture.
As drivers/passthrough/io.c is compiled only for x86 move it to
x86 directory and rena
This patch series is v4 of preparatory work to make PCI passthrough code
non-x86 specific.
Rahul Singh (3):
xen/pci: Move x86 specific code to x86 directory.
xen/pci: solve compilation error on ARM with HAS_PCI enabled.
ns16550: Gate all PCI code with CONFIG_X86
xen/drivers/char/ns16550.c
On 24/11/2020 18:13, Bertrand Marquis wrote:
Hi Julien,
Hi Bertrand,
On 19 Nov 2020, at 19:07, Julien Grall wrote:
From: Julien Grall
At the moment, xen_pt_update_entry() only supports mapping at level 3
(i.e 4KB mapping). While this is fine for most of the runtime helper,
the boot cod
On Wed, Nov 25, 2020 at 5:24 PM Jakub Kicinski wrote:
>
> And just to spell it out,
>
> case ENUM_VALUE1:
> bla();
> break;
> case ENUM_VALUE2:
> bla();
> default:
> break;
>
> is a fairly idiomatic way of indicating that not all values of the enum
> are expected to
On 25/11/2020 14:49, Andrew Cooper wrote:
> diff --git a/tools/Rules.mk b/tools/Rules.mk
> index f61da81f4a..5d92ff0699 100644
> --- a/tools/Rules.mk
> +++ b/tools/Rules.mk
> @@ -184,7 +184,7 @@ $(PKG_CONFIG_DIR)/%.pc: Makefile
> $(XEN_ROOT)/tools/Rules.mk $(PKG_CONFIG_DIR)
> echo "Descripti
flight 156989 xen-4.14-testing real [real]
flight 157010 xen-4.14-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/156989/
http://logs.test-lab.xenproject.org/osstest/logs/157010/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
t
On Tue, Nov 24, 2020 at 02:37:05PM -0500, Tejun Heo wrote:
> On Tue, Nov 24, 2020 at 02:27:29PM +0100, Christoph Hellwig wrote:
> > Switch the block device lookup interfaces to directly work with a dev_t
> > so that struct block_device references are only acquired by the
> > blkdev_get variants (an
Hi Andrew,
> On 25 Nov 2020, at 14:49, Andrew Cooper wrote:
>
> The internal package config file for libxenlight reads (reformatted to avoid
> exceeding the SMTP 998-character line length):
>
> Libs: -L${libdir}
>
> -Wl,-rpath-link=/local/security/xen.git/tools/libs/light/../../../tools/libs
From: Brian Masney
[ Upstream commit 65cae18882f943215d0505ddc7e70495877308e6 ]
When booting a hyperthreaded system with the kernel parameter
'mitigations=auto,nosmt', the following warning occurs:
WARNING: CPU: 0 PID: 1 at drivers/xen/events/events_base.c:1112
unbind_from_irqhandler+0x4e/
From: Brian Masney
[ Upstream commit 65cae18882f943215d0505ddc7e70495877308e6 ]
When booting a hyperthreaded system with the kernel parameter
'mitigations=auto,nosmt', the following warning occurs:
WARNING: CPU: 0 PID: 1 at drivers/xen/events/events_base.c:1112
unbind_from_irqhandler+0x4e/
From: Brian Masney
[ Upstream commit 65cae18882f943215d0505ddc7e70495877308e6 ]
When booting a hyperthreaded system with the kernel parameter
'mitigations=auto,nosmt', the following warning occurs:
WARNING: CPU: 0 PID: 1 at drivers/xen/events/events_base.c:1112
unbind_from_irqhandler+0x4e/
From: Brian Masney
[ Upstream commit 65cae18882f943215d0505ddc7e70495877308e6 ]
When booting a hyperthreaded system with the kernel parameter
'mitigations=auto,nosmt', the following warning occurs:
WARNING: CPU: 0 PID: 1 at drivers/xen/events/events_base.c:1112
unbind_from_irqhandler+0x4e/
From: Brian Masney
[ Upstream commit 65cae18882f943215d0505ddc7e70495877308e6 ]
When booting a hyperthreaded system with the kernel parameter
'mitigations=auto,nosmt', the following warning occurs:
WARNING: CPU: 0 PID: 1 at drivers/xen/events/events_base.c:1112
unbind_from_irqhandler+0x4e/
From: Brian Masney
[ Upstream commit 65cae18882f943215d0505ddc7e70495877308e6 ]
When booting a hyperthreaded system with the kernel parameter
'mitigations=auto,nosmt', the following warning occurs:
WARNING: CPU: 0 PID: 1 at drivers/xen/events/events_base.c:1112
unbind_from_irqhandler+0x4e/
The internal package config file for libxenlight reads (reformatted to avoid
exceeding the SMTP 998-character line length):
Libs: -L${libdir}
-Wl,-rpath-link=/local/security/xen.git/tools/libs/light/../../../tools/libs/toollog
-Wl,-rpath-link=/local/security/xen.git/tools/libs/light/../../
flight 157006 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157006/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 25.11.20 14:48, Ian Jackson wrote:
Andrew Cooper ,
George Dunlap ,
Jan Beulich ,
Julien Grall ,
Stefano Stabellini ,
=?iso-8859-1?Q?J=FCrgen_Gro=DF?= ,
Paul Durrant ,
Wei Liu
FCC: ~/mail/Outbound
--text follows this line--
Hi. I've done a little bit of
(resending because the first one had corrupted email headers;
please reply to this one and not the previous one)
Hi. I've done a little bit of consultation with previous release
managers, and reviewed various list archives and calendars. These
consultations seemed to suggest some folklore that
Andrew Cooper ,
George Dunlap ,
Jan Beulich ,
Julien Grall ,
Stefano Stabellini ,
=?iso-8859-1?Q?J=FCrgen_Gro=DF?= ,
Paul Durrant ,
Wei Liu
FCC: ~/mail/Outbound
--text follows this line--
Hi. I've done a little bit of consultation with previous release
managers, an
On Tue 24-11-20 14:27:18, Christoph Hellwig wrote:
> sector_t is now always a u64, so this check is not needed.
>
> Signed-off-by: Christoph Hellwig
Looks good. You can add:
Reviewed-by: Jan Kara
Honza
> ---
> block/ioctl.c | 9
On Tue 24-11-20 14:27:14, Christoph Hellwig wrote:
> set_blocksize is used by file systems to use their preferred buffer cache
> block size. Block drivers should not set it.
>
> Signed-off-by: Christoph Hellwig
Looks good to me. You can add:
Reviewed-by: Jan Kara
On 25.11.2020 13:15, Julien Grall wrote:
> On 23/11/2020 14:23, Jan Beulich wrote:
>> All of the array allocations in grant_table_init() can exceed a page's
>> worth of memory, which xmalloc()-based interfaces aren't really suitable
>> for after boot. We also don't need any of these allocations to
flight 156988 xen-4.13-testing real [real]
flight 157005 xen-4.13-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/156988/
http://logs.test-lab.xenproject.org/osstest/logs/157005/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
t
On Tue 24-11-20 14:27:12, Christoph Hellwig wrote:
> The zram claim mechanism was added to ensure no new opens come in
> during teardown. But the proper way to archive that is to call
^^^ achieve
> del_gendisk first, which takes care of all that. Once de
On Tue 24-11-20 14:27:11, Christoph Hellwig wrote:
> del_gendisk already calls fsync_bdev for every partition, no need
> to do this twice.
>
> Signed-off-by: Christoph Hellwig
Makes sense to me. You can add:
Reviewed-by: Jan Kara
On Tue 24-11-20 14:27:10, Christoph Hellwig wrote:
> Store the frozen superblock in struct block_device to avoid the awkward
> interface that can return a sb only used a cookie, an ERR_PTR or NULL.
>
> Signed-off-by: Christoph Hellwig
Some comments below...
> diff --git a/fs/block_dev.c b/fs/bl
On Tue, Nov 24, 2020 at 11:05 PM James Bottomley
wrote:
>
> On Tue, 2020-11-24 at 13:32 -0800, Kees Cook wrote:
> > We already enable -Wimplicit-fallthrough globally, so that's not the
> > discussion. The issue is that Clang is (correctly) even more strict
> > than GCC for this, so these are the r
On Tue 24-11-20 14:27:09, Christoph Hellwig wrote:
> Just open code the wait in the only caller of both functions.
>
> Signed-off-by: Christoph Hellwig
Fine by me. You can add:
Reviewed-by: Jan Kara
Honza
> ---
> fs/internal.h
On Tue 24-11-20 14:27:08, Christoph Hellwig wrote:
> Use file->f_mapping in all remaining places that have a struct file
> available to properly handle the case where inode->i_mapping !=
> file_inode(file)->i_mapping.
>
> Signed-off-by: Christoph Hellwig
Looks good to me. You can add:
Reviewed-
Hi Jan,
On 23/11/2020 14:23, Jan Beulich wrote:
All of the array allocations in grant_table_init() can exceed a page's
worth of memory, which xmalloc()-based interfaces aren't really suitable
for after boot. We also don't need any of these allocations to be
physically contiguous.. Introduce inte
> -Original Message-
> From: Jan Beulich
> Sent: 25 November 2020 11:51
> To: p...@xen.org
> Cc: Durrant, Paul ; Elnikety, Eslam
> ; 'Christian Lindig'
> ; 'David Scott' ; 'Ian Jackson'
> ;
> 'Wei Liu' ; 'Andrew Cooper' ;
> 'George Dunlap'
> ; 'Julien Grall' ; 'Stefano
> Stabellini'
>
Hey, Jan,
On Wed, Nov 25, 2020 at 12:40:44PM +0100, Jan Kara wrote:
> > I don't think this is necessary now that the bdev and inode lifetimes are
> > one. Before, punching out the association early was necessary because we
> > could be in a situation where we can successfully look up a part from i
> On 25 Nov 2020, at 11:26, Julien Grall wrote:
>
>
>
> On 24/11/2020 17:44, Stefano Stabellini wrote:
>> On Tue, 24 Nov 2020, Rahul Singh wrote:
On 24 Nov 2020, at 11:12 am, Bertrand Marquis
wrote:
On the Cortex A55, TLB entries can be allocated by a speculative AT
>>
On 23/11/2020 14:23, Jan Beulich wrote:
While it's currently implied from the checking xmalloc_array() does,
let's make this more explicit in the function itself. As a result both
involved local variables don't need to have size_t type anymore. This
brings them in line with the rest of the cod
On 25.11.2020 12:10, Paul Durrant wrote:
>> From: Jan Beulich
>> Sent: 25 November 2020 09:20
>>
>> On 24.11.2020 20:17, Paul Durrant wrote:
>>> From: Paul Durrant
>>>
>>> ...to control the visibility of the FIFO event channel operations
>>> (EVTCHNOP_init_control, EVTCHNOP_expand_array, and EVTC
> -Original Message-
> From: Andrew Cooper
> Sent: 25 November 2020 11:31
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Durrant, Paul ; Elnikety, Eslam
> ; Christian Lindig
> ; David Scott ; Ian Jackson
> ; Wei
> Liu ; George Dunlap ; Jan Beulich
> ; Julien
> Grall ; Stefano
Hello!
On Tue 24-11-20 11:59:49, Tejun Heo wrote:
> > diff --git a/block/partitions/core.c b/block/partitions/core.c
> > index a02e224115943d..0ba0bf44b88af3 100644
> > --- a/block/partitions/core.c
> > +++ b/block/partitions/core.c
> > @@ -340,12 +340,11 @@ void delete_partition(struct hd_struc
On 24/11/2020 19:17, Paul Durrant wrote:
> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
> index 666aeb71bf1b..70701c59d053 100644
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -70,9 +70,11 @@ struct xen_domctl_createdomain {
> #define XEN_DO
On 24/11/2020 17:44, Stefano Stabellini wrote:
On Tue, 24 Nov 2020, Rahul Singh wrote:
On 24 Nov 2020, at 11:12 am, Bertrand Marquis wrote:
On the Cortex A55, TLB entries can be allocated by a speculative AT
instruction. If this is happening during a guest context switch with an
inconsisten
Hi Jan,
On 24/11/2020 17:03, Jan Beulich wrote:
Inter-domain channels can't possibly be bound to themselves, there's
always a 2nd channel involved, even when this is a loopback into the
same domain. As a result we can drop one conditional each from the two
involved functions.
With this, the num
> -Original Message-
> From: Jan Beulich
> Sent: 25 November 2020 09:20
> To: Paul Durrant
> Cc: Paul Durrant ; Eslam Elnikety ;
> Christian Lindig
> ; David Scott ; Ian Jackson
> ; Wei
> Liu ; Andrew Cooper ; George Dunlap
> ;
> Julien Grall ; Stefano Stabellini ;
> xen-
> de...@list
> -Original Message-
> From: Jan Beulich
> Sent: 25 November 2020 09:36
> To: Andrew Cooper
> Cc: Durrant, Paul ; Elnikety, Eslam
> ; Christian Lindig
> ; David Scott ; Ian Jackson
> ; Wei
> Liu ; George Dunlap ; Julien Grall
> ; Stefano
> Stabellini ; xen-devel@lists.xenproject.org; P
evtchn_fifo_set_pending() can be simplified a little bit.
Suggested-by: Jan Beulich
Signed-off-by: Juergen Gross
---
V8:
- new patch
---
xen/common/event_fifo.c | 34 +++---
1 file changed, 15 insertions(+), 19 deletions(-)
diff --git a/xen/common/event_fifo.c b/xen
In order to avoid latent races when updating an event channel put
xen_consumer and pending fields in different bytes. This is no problem
right now, but especially the pending indicator isn't used only when
initializing an event channel (unlike xen_consumer), so any future
addition to this byte woul
This is an add-on of my event channel locking series.
Juergen Gross (3):
xen/events: modify struct evtchn layout
xen/events: rework fifo queue locking
xen/events: do some cleanups in evtchn_fifo_set_pending()
xen/common/event_fifo.c | 152 +---
xen/inclu
Two cpus entering evtchn_fifo_set_pending() for the same event channel
can race in case the first one gets interrupted after setting
EVTCHN_FIFO_PENDING and when the other one manages to set
EVTCHN_FIFO_LINKED before the first one is testing that bit. This can
lead to evtchn_check_pollers() being c
On Mon, Nov 23, 2020 at 10:39 PM James Bottomley
wrote:
> On Mon, 2020-11-23 at 19:56 +0100, Miguel Ojeda wrote:
> > On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
> > wrote:
...
> > But if we do the math, for an author, at even 1 minute per line
> > change and assuming nothing can be automate
Hi, Is there a way to mount a vtpm 2.0 in a Windows 10 VM ? Thanks Paul
flight 157003 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157003/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 9b156bcc3ffcc7949edd4460b718a241e87ae302
baseline version:
xen b659
On 25.11.2020 10:20, Jan Beulich wrote:
> On 24.11.2020 20:17, Paul Durrant wrote:
>> --- a/xen/include/public/domctl.h
>> +++ b/xen/include/public/domctl.h
>> @@ -70,9 +70,11 @@ struct xen_domctl_createdomain {
>> #define XEN_DOMCTL_CDF_iommu (1U<<_XEN_DOMCTL_CDF_iommu)
>> #define _XEN_
On 24.11.2020 20:17, Paul Durrant wrote:
> From: Paul Durrant
>
> ...to control the visibility of the FIFO event channel operations
> (EVTCHNOP_init_control, EVTCHNOP_expand_array, and EVTCHNOP_set_priority) to
> the guest.
>
> These operations were added to the public header in commit d2d50c2f3
On Mon, Nov 23, 2020 at 07:58:06AM -0800, James Bottomley wrote:
> On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote:
> > On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
> > wrote:
> > > It's not about the risk of the changes it's about the cost of
> > > implementing them. Even if you discou
Except for the initial part of cstar_enter compat/entry.S is all dead
code in this case. Further, along the lines of the PV conditionals we
already have in entry.S, make code PV32-conditional there too (to a
fair part because this code actually references compat/entry.S).
Signed-off-by: Jan Beulic
This vector can be used as an ordinary interrupt handling one in this
case. To be sure no references are left, make the #define itself
conditional.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -436,8 +436,12 @@ int __init init_irq_data(void)
irq_to_des
This file has a long dependencies list (through asm-offsets.[cs]) and a
long list of dependents. IOW if any of the former changes, all of the
latter will be rebuilt, even if there's no actual change to the
generated file. Therefore avoid producing symbols we don't actually
need, depending on config
This file has a long dependencies list and asm-offsets.h, generated from
it, has a long list of dependents. IOW if any of the former changes, all
of the latter will be rebuilt, even if there's no actual change to the
generated file. Therefore avoid including headers we don't actually need
(generall
This file has a long dependencies list (through asm-offsets.s) and a
long list of dependents. IOW if any of the former changes, all of the
latter will be rebuilt, even if there's no actual change to the
generated file. This is the primary scenario we have the move-if-changed
macro for.
Since debug
The 2nd and 3rd patches here effectively called for the latter
two to also be created, hence why they all live together.
1: build: limit rebuilding of asm-offsets.s
2: build: limit #include-ing by asm-offsets.h
3: build: restrict contents of asm-offsets.h when !HVM / !PV
4: hypercall vector is unu
On 25.11.20 09:25, Jan Beulich wrote:
On 25.11.2020 09:08, Jürgen Groß wrote:
On 25.11.20 08:42, Jan Beulich wrote:
On 25.11.2020 06:23, Jürgen Groß wrote:
On 24.11.20 17:32, Jan Beulich wrote:
On 24.11.2020 15:49, Jürgen Groß wrote:
On 24.11.20 15:02, Jan Beulich wrote:
On 24.11.2020 08:01
On 25.11.2020 09:08, Jürgen Groß wrote:
> On 25.11.20 08:42, Jan Beulich wrote:
>> On 25.11.2020 06:23, Jürgen Groß wrote:
>>> On 24.11.20 17:32, Jan Beulich wrote:
On 24.11.2020 15:49, Jürgen Groß wrote:
> On 24.11.20 15:02, Jan Beulich wrote:
>> On 24.11.2020 08:01, Juergen Gross wro
On 25.11.20 08:42, Jan Beulich wrote:
On 25.11.2020 06:23, Jürgen Groß wrote:
On 24.11.20 17:32, Jan Beulich wrote:
On 24.11.2020 15:49, Jürgen Groß wrote:
On 24.11.20 15:02, Jan Beulich wrote:
On 24.11.2020 08:01, Juergen Gross wrote:
Two cpus entering evtchn_fifo_set_pending() for the same
94 matches
Mail list logo
