flight 156847 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156847/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-i386-libvirt
flight 156849 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156849/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 404250c8f77d09077321766602c3118cec7f6ecd
baseline version:
ovmf e6a12a0fc817e26ac05e8
On 17.11.2020 19:13, Julien Grall wrote:
> On 09/11/2020 16:38, Juergen Gross wrote:
>> Juergen Gross (3):
>>xen/events: access last_priority and last_vcpu_id together
>>xen/evtchn: rework per event channel lock
>>xen/evtchn: revert 52e1fc47abc3a0123
>
> While looking at the list of co
On 18.11.20 09:22, Jan Beulich wrote:
On 17.11.2020 19:13, Julien Grall wrote:
On 09/11/2020 16:38, Juergen Gross wrote:
Juergen Gross (3):
xen/events: access last_priority and last_vcpu_id together
xen/evtchn: rework per event channel lock
xen/evtchn: revert 52e1fc47abc3a0123
Whi
On 18.11.2020 01:50, Stefano Stabellini wrote:
> 1) It is not obvious that "Configure standard Xen features (expert
> users)" is actually the famous EXPERT we keep talking about on xen-devel
Which can be addressed by simply changing the one prompt line.
> 2) It is not obvious when we need to enab
Hi Stefano,
> On 18 Nov 2020, at 00:50, Stefano Stabellini wrote:
>
> From: Stefano Stabellini
>
> A recent thread [1] has exposed a couple of issues with our current way
> of handling EXPERT.
>
> 1) It is not obvious that "Configure standard Xen features (expert
> users)" is actually the fam
Call disk_part_iter_exit in disk_part_iter_next instead of duplicating
the functionality.
Signed-off-by: Christoph Hellwig
---
block/genhd.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/block/genhd.c b/block/genhd.c
index 4e039524f92b8f..0bd9c41dd4cb69 100644
--- a/block
Hi Jens,
this series cleans up our main per-device node data structure by merging
the block_device and hd_struct data structures that have the same scope,
but different life times. The main effect (besides removing lots of
code) is that instead of having two device sizes that need complex
synchro
disk_get_part needs to be paired with a disk_put_part.
Fixes: ef45fe470e1 ("blk-cgroup: show global disk stats in root cgroup io.stat")
Signed-off-by: Christoph Hellwig
---
block/blk-cgroup.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c
index c68bdf
Signed-off-by: Christoph Hellwig
---
include/linux/genhd.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/linux/genhd.h b/include/linux/genhd.h
index 46553d6d602563..22f5b9fd96f8bf 100644
--- a/include/linux/genhd.h
+++ b/include/linux/genhd.h
@@ -250,7 +250,6 @@ static inline dev_t p
Use put_device to put the device instead of poking into the internals
and using kobject_put.
Signed-off-by: Christoph Hellwig
---
block/genhd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block/genhd.c b/block/genhd.c
index 0bd9c41dd4cb69..f46e89226fdf91 100644
--- a/bloc
Add a little helper to find the kobject for a struct block_device.
Signed-off-by: Christoph Hellwig
---
drivers/md/bcache/super.c | 7 ++-
drivers/md/md.c | 4 +---
fs/btrfs/sysfs.c | 15 +++
include/linux/blk_types.h | 3 +++
4 files changed, 9 insertions(+
Adding the minor to the major creates tons of pointless conflicts. Just
use the dev_t itself, which is 32-bits and thus is guaranteed to fit
into ino_t.
Signed-off-by: Christoph Hellwig
---
fs/block_dev.c | 26 ++
1 file changed, 2 insertions(+), 24 deletions(-)
diff --g
Split each case into a self-contained helper.
Signed-off-by: Christoph Hellwig
---
include/linux/genhd.h | 7 +-
init/do_mounts.c | 183 +-
2 files changed, 91 insertions(+), 99 deletions(-)
diff --git a/include/linux/genhd.h b/include/linux/genhd.
The code in devt_from_partuuid is very convoluted. Refactor a bit by
sanitizing the goto and variable name usage.
Signed-off-by: Christoph Hellwig
---
init/do_mounts.c | 68 ++--
1 file changed, 31 insertions(+), 37 deletions(-)
diff --git a/init/do_
Avoid a totally pointless goto label, and use the same style of
comparism for both helpers.
Signed-off-by: Christoph Hellwig
---
init/do_mounts.c | 18 ++
1 file changed, 6 insertions(+), 12 deletions(-)
diff --git a/init/do_mounts.c b/init/do_mounts.c
index afa26a4028d25e..5879
To simplify block device lookup and a few other upcomdin areas, make sure
that we always have a struct block_device available for each disk and
each partition. The only downside of this is that each device and
partition uses a little more memories. The upside will be that a lot of
code can be sim
Now that each hd_struct has a reference to the corresponding
block_device, there is no need for the bd_contains pointer. Add
a bdev_whole() helper to look up the whole device block_device
struture instead.
Signed-off-by: Christoph Hellwig
---
drivers/scsi/scsicam.c| 2 +-
fs/block_dev.c
Reorder the code to have one big section for the last close, and to use
bdev_is_partition.
Signed-off-by: Christoph Hellwig
---
fs/block_dev.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/fs/block_dev.c b/fs/block_dev.c
index 29db12c3bb501c..4c4d6c30382c06 1
Stop passing the whole device as a separate argument given that it
can be trivially deducted.
Signed-off-by: Christoph Hellwig
---
drivers/block/loop.c | 12 +++-
fs/block_dev.c | 69 +++---
include/linux/blkdev.h | 6 ++--
3 files changed, 38 i
Now that the hd_struct always has a block device attached to it, there is
no need for having two size field that just get out of sync.
Additional the field in hd_struct did not use proper serializiation,
possibly allowing for torn writes. By only using the block_device field
this problem also get
On 11/18/20 4:47 PM, Christoph Hellwig wrote:
> Don't bother to call lookup_bdev for just a slightly different error
> message without any functional change.
>
> Signed-off-by: Christoph Hellwig ist
Hi Christoph,
NACK. This removing error message is frequently triggered and observed,
and distinc
Christoph,
On 18.11.2020 09:47, Christoph Hellwig wrote:
> Diffstat:
> block/bio.c |6
> block/blk-cgroup.c | 50 +-
> block/blk-core.c | 85 +--
> block/blk-flush.c|2
On Tue, Nov 17, 2020 at 05:40:33PM +0100, Manuel Bouyer wrote:
> On Tue, Nov 17, 2020 at 04:58:07PM +0100, Roger Pau Monné wrote:
> > [...]
> >
> > I have attached a patch below that will dump the vIO-APIC info as part
> > of the 'i' debug key output, can you paste the whole output of the 'i'
> >
On Wed, Nov 18, 2020 at 09:56:11AM +0100, Jan Beulich wrote:
> since this isn't the first series from you recently spamming
> xen-devel, may I ask that you don't Cc entire series to lists
> which are involved with perhaps just one out of the many patches?
> IMO Cc lists should be compiled on a per-
On 18.11.2020 09:45, Bertrand Marquis wrote:
>> On 18 Nov 2020, at 00:50, Stefano Stabellini wrote:
>> --- a/xen/arch/x86/Kconfig
>> +++ b/xen/arch/x86/Kconfig
>> @@ -102,8 +102,8 @@ config HVM
>>If unsure, say Y.
>>
>> config XEN_SHSTK
>> -bool "Supervisor Shadow Stacks"
>> -depen
Just open code the wait in the only caller of both functions.
Signed-off-by: Christoph Hellwig
---
fs/internal.h | 2 ++
fs/quota/quota.c | 31 +---
fs/super.c | 51 ++
include/linux/fs.h | 4 +---
4 files chang
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
---
mm/filemap.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/mm/filem
We can just dereference the point in struct gendisk instead. Also
remove the now unused export.
Signed-off-by: Christoph Hellwig
---
block/genhd.c | 1 -
drivers/block/nbd.c | 4 +---
drivers/block/xen-blkfront.c| 20 +---
drivers/block/zram/z
Don't bother to call lookup_bdev for just a slightly different error
message without any functional change.
Signed-off-by: Christoph Hellwig
---
drivers/md/bcache/super.c | 44 +--
1 file changed, 1 insertion(+), 43 deletions(-)
diff --git a/drivers/md/bcache
Instead of having two structures that represent each block device with
different lift time rules merged them into a single one. This also
greatly simplifies the reference counting rules, as we can use the inode
reference count as the main reference count for the new struct
block_device, with the d
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 (and the blk-cgroup special case). This means that
we not don't need an extra reference in the inode and can generally
simplify handling of st
On 18.11.2020 09:58, Christoph Hellwig wrote:
> On Wed, Nov 18, 2020 at 09:56:11AM +0100, Jan Beulich wrote:
>> since this isn't the first series from you recently spamming
>> xen-devel, may I ask that you don't Cc entire series to lists
>> which are involved with perhaps just one out of the many p
On Wed, Nov 18, 2020 at 10:04:04AM +0100, Jan Beulich wrote:
> That's the view of some people, but not all. Context can be easily
> established by those who care going to one of the many archives on
> which the entire series lands. Getting spammed, however, can't be
> avoided by the dozens or hundr
On Wed, Nov 18, 2020 at 10:04:04AM +0100, Jan Beulich wrote:
> On 18.11.2020 09:58, Christoph Hellwig wrote:
> > On Wed, Nov 18, 2020 at 09:56:11AM +0100, Jan Beulich wrote:
> >> since this isn't the first series from you recently spamming
> >> xen-devel, may I ask that you don't Cc entire series t
On Wed, Nov 18, 2020 at 04:54:51PM +0800, Coly Li wrote:
> On 11/18/20 4:47 PM, Christoph Hellwig wrote:
> > Don't bother to call lookup_bdev for just a slightly different error
> > message without any functional change.
> >
> > Signed-off-by: Christoph Hellwig ist
>
> Hi Christoph,
>
> NACK. Th
On Wed, Nov 18, 2020 at 09:47:40AM +0100, Christoph Hellwig wrote:
> Hi Jens,
>
> this series cleans up our main per-device node data structure by merging
> the block_device and hd_struct data structures that have the same scope,
> but different life times. The main effect (besides removing lots
On 17.11.2020 17:40, Manuel Bouyer wrote:
> On Tue, Nov 17, 2020 at 04:58:07PM +0100, Roger Pau Monné wrote:
>> [...]
>>
>> I have attached a patch below that will dump the vIO-APIC info as part
>> of the 'i' debug key output, can you paste the whole output of the 'i'
>> debug key when the system s
On Fri, Nov 13, 2020 at 10:52:58AM +0100, Jan Beulich wrote:
> On 12.11.2020 18:52, Tim Deegan wrote:
> > At 15:04 +0100 on 12 Nov (1605193496), Jan Beulich wrote:
> >> On 12.11.2020 14:07, Roger Pau Monné wrote:
> >>> On Thu, Nov 12, 2020 at 01:29:33PM +0100, Jan Beulich wrote:
> I agree with
On 18.11.2020 10:09, Greg KH wrote:
> On Wed, Nov 18, 2020 at 10:04:04AM +0100, Jan Beulich wrote:
>> On 18.11.2020 09:58, Christoph Hellwig wrote:
>>> On Wed, Nov 18, 2020 at 09:56:11AM +0100, Jan Beulich wrote:
since this isn't the first series from you recently spamming
xen-devel, may
On Wed, Nov 18, 2020 at 09:57:38AM +0100, Roger Pau Monné wrote:
> On Tue, Nov 17, 2020 at 05:40:33PM +0100, Manuel Bouyer wrote:
> > On Tue, Nov 17, 2020 at 04:58:07PM +0100, Roger Pau Monné wrote:
> > > [...]
> > >
> > > I have attached a patch below that will dump the vIO-APIC info as part
> >
On Wed, Nov 18, 2020 at 10:16:17AM +0100, Jan Beulich wrote:
> On 17.11.2020 17:40, Manuel Bouyer wrote:
> > On Tue, Nov 17, 2020 at 04:58:07PM +0100, Roger Pau Monné wrote:
> >> [...]
> >>
> >> I have attached a patch below that will dump the vIO-APIC info as part
> >> of the 'i' debug key output,
On Wed, Oct 28, 2020 at 10:24:53AM +0100, Jan Beulich wrote:
> Fair parts of the present handlers are identical; in fact
> nestedp2m_write_p2m_entry() lacks a call to p2m_entry_modify(). Move
> common parts right into write_p2m_entry(), splitting the hooks into a
> "pre" one (needed just by shadow
On Wed, Nov 18, 2020 at 10:23:51AM +0100, Jan Beulich wrote:
> On 18.11.2020 10:09, Greg KH wrote:
> > On Wed, Nov 18, 2020 at 10:04:04AM +0100, Jan Beulich wrote:
> >> On 18.11.2020 09:58, Christoph Hellwig wrote:
> >>> On Wed, Nov 18, 2020 at 09:56:11AM +0100, Jan Beulich wrote:
> since this
On 18.11.2020 10:28, Manuel Bouyer wrote:
> On Wed, Nov 18, 2020 at 10:16:17AM +0100, Jan Beulich wrote:
>> On 17.11.2020 17:40, Manuel Bouyer wrote:
>>> On Tue, Nov 17, 2020 at 04:58:07PM +0100, Roger Pau Monné wrote:
[...]
I have attached a patch below that will dump the vIO-APIC i
On Tue, Nov 10, 2020 at 02:51:11PM +0100, Jan Beulich wrote:
> On 10.11.2020 12:06, Roger Pau Monné wrote:
> > On Wed, Oct 28, 2020 at 10:22:58AM +0100, Jan Beulich wrote:
> >> @@ -1132,7 +1132,13 @@ void p2m_pt_init(struct p2m_domain *p2m)
> >> p2m->recalc = do_recalc;
> >> p2m->change_e
On 11/18/20 5:10 PM, Greg KH wrote:
> On Wed, Nov 18, 2020 at 04:54:51PM +0800, Coly Li wrote:
>> On 11/18/20 4:47 PM, Christoph Hellwig wrote:
>>> Don't bother to call lookup_bdev for just a slightly different error
>>> message without any functional change.
>>>
>>> Signed-off-by: Christoph Hellwi
On Wed, Nov 18, 2020 at 10:24:25AM +0100, Manuel Bouyer wrote:
> On Wed, Nov 18, 2020 at 09:57:38AM +0100, Roger Pau Monné wrote:
> > On Tue, Nov 17, 2020 at 05:40:33PM +0100, Manuel Bouyer wrote:
> > > On Tue, Nov 17, 2020 at 04:58:07PM +0100, Roger Pau Monné wrote:
> > > > [...]
> > > >
> > > >
On Wed, Nov 18, 2020 at 10:43:27AM +0100, Jan Beulich wrote:
> On 18.11.2020 10:28, Manuel Bouyer wrote:
> > On Wed, Nov 18, 2020 at 10:16:17AM +0100, Jan Beulich wrote:
> >> On 17.11.2020 17:40, Manuel Bouyer wrote:
> >>> On Tue, Nov 17, 2020 at 04:58:07PM +0100, Roger Pau Monné wrote:
> [...
I like the improvements for the build process but I wonder whether these should
be mixed with functional code changes. But that is only a cosmetic concern as
it might impact identifying patches when they are backported. The code change
looks good to me, too. I support moving to Dune for buildi
On 18.11.2020 11:14, Manuel Bouyer wrote:
> On Wed, Nov 18, 2020 at 10:43:27AM +0100, Jan Beulich wrote:
>> On 18.11.2020 10:28, Manuel Bouyer wrote:
>>> On Wed, Nov 18, 2020 at 10:16:17AM +0100, Jan Beulich wrote:
On 17.11.2020 17:40, Manuel Bouyer wrote:
> On Tue, Nov 17, 2020 at 04:58:0
Hello Stefano,
> On 17 Nov 2020, at 11:53 pm, Stefano Stabellini
> wrote:
>
> Adding Bertrand, Oleksandr, Julien, and others -- they have a more
> recent experience with GICv3 ITS than me and might be able to help.
> I am attaching the device tree Leo sent a few days ago for reference.
>
>
>
On 18.11.2020 09:41, Jürgen Groß wrote:
> On 18.11.20 09:22, Jan Beulich wrote:
>> On 17.11.2020 19:13, Julien Grall wrote:
>>> On 09/11/2020 16:38, Juergen Gross wrote:
Juergen Gross (3):
xen/events: access last_priority and last_vcpu_id together
xen/evtchn: rework per event
Hi Paul.
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -314,6 +314,8 @@ struct sched_unit {
struct evtchn_port_ops;
+#define MAX_NR_IOREQ_SERVERS 8
+
struct domain
{
domid_t domain_id;
@@ -521,6 +523,21 @@ struct domain
/* Argo interdomain com
On Wed, Nov 18, 2020 at 11:00:25AM +0100, Roger Pau Monné wrote:
> On Wed, Nov 18, 2020 at 10:24:25AM +0100, Manuel Bouyer wrote:
> > On Wed, Nov 18, 2020 at 09:57:38AM +0100, Roger Pau Monné wrote:
> > > On Tue, Nov 17, 2020 at 05:40:33PM +0100, Manuel Bouyer wrote:
> > > > On Tue, Nov 17, 2020 at
flight 156845 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156845/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-examine 4 memdisk-try-append fail like 156711
test-amd64-amd64-xl-rtds 20 gues
Hi,
On 17/11/2020 23:53, Stefano Stabellini wrote:
Adding Bertrand, Oleksandr, Julien, and others -- they have a more
recent experience with GICv3 ITS than me and might be able to help.
I am attaching the device tree Leo sent a few days ago for reference.
Typically when you can set the etherne
> -Original Message-
> From: Oleksandr
> Sent: 18 November 2020 12:09
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Oleksandr Tyshchenko
> ; Jan Beulich
> ; Andrew Cooper ; Roger Pau
> Monné
> ; Wei Liu ; George Dunlap
> ; Ian Jackson
> ; Julien Grall ; Stefano Stabellini
>
On Wed, Nov 18, 2020 at 10:23:51AM +0100, Jan Beulich wrote:
> On 18.11.2020 10:09, Greg KH wrote:
> > On Wed, Nov 18, 2020 at 10:04:04AM +0100, Jan Beulich wrote:
> >> On 18.11.2020 09:58, Christoph Hellwig wrote:
> >>> On Wed, Nov 18, 2020 at 09:56:11AM +0100, Jan Beulich wrote:
> since this
On 09.11.2020 17:38, Juergen Gross wrote:
> Currently the lock for a single event channel needs to be taken with
> interrupts off, which causes deadlocks in some cases.
>
> Rework the per event channel lock to be non-blocking for the case of
> sending an event and removing the need for disabling i
On Wed 18-11-20 09:47:41, Christoph Hellwig wrote:
> disk_get_part needs to be paired with a disk_put_part.
>
> Fixes: ef45fe470e1 ("blk-cgroup: show global disk stats in root cgroup
> io.stat")
> Signed-off-by: Christoph Hellwig
Looks good to me. You can add:
Reviewed-by: Jan Kara
Hi Jan,
On 18/11/2020 08:22, Jan Beulich wrote:
On 17.11.2020 19:13, Julien Grall wrote:
On 09/11/2020 16:38, Juergen Gross wrote:
Juergen Gross (3):
xen/events: access last_priority and last_vcpu_id together
xen/evtchn: rework per event channel lock
xen/evtchn: revert 52e1fc47abc3
Hi Jan,
> On 18 Nov 2020, at 08:50, Jan Beulich wrote:
>
> On 18.11.2020 09:45, Bertrand Marquis wrote:
>>> On 18 Nov 2020, at 00:50, Stefano Stabellini wrote:
>>> --- a/xen/arch/x86/Kconfig
>>> +++ b/xen/arch/x86/Kconfig
>>> @@ -102,8 +102,8 @@ config HVM
>>> If unsure, say Y.
>>>
>>> c
Hi,
> On 17 Nov 2020, at 09:42, Jan Beulich wrote:
>
> Olaf reported observing
>
> xenstat_qmp.c:26:10: fatal error: _paths.h: No such file or directory
> .../tools/libs/stat/../../../tools/Rules.mk:153: xenstat_qmp.opic] Error 1
>
> Obviously _paths.h, when included by any of the sources, nee
Julien Grall writes ("Re: [PATCH v6 0/3] XSA-343 followup patches"):
> On 18/11/2020 08:22, Jan Beulich wrote:
> > Without a clear outline of what would break with the present logic,
> > I had previously indicated I'm not convinced of the change. This
> > isn't a strong objection, no, but I still w
> -Original Message-
> From: Xen-devel On Behalf Of Julien
> Grall
> Sent: 18 November 2020 14:18
> To: Jan Beulich
> Cc: Andrew Cooper ; George Dunlap
> ; Ian Jackson
> ; Stefano Stabellini ; Wei Liu
> ; Roger Pau
> Monné ; Daniel De Graaf ;
> committ...@xenproject.org; xen-
> de...@
On Wed, Nov 18, 2020 at 01:14:03PM +0100, Manuel Bouyer wrote:
> On Wed, Nov 18, 2020 at 11:00:25AM +0100, Roger Pau Monné wrote:
> > On Wed, Nov 18, 2020 at 10:24:25AM +0100, Manuel Bouyer wrote:
> > > On Wed, Nov 18, 2020 at 09:57:38AM +0100, Roger Pau Monné wrote:
> > > > On Tue, Nov 17, 2020 at
On 18.11.2020 15:39, Roger Pau Monné wrote:
> On Wed, Nov 18, 2020 at 01:14:03PM +0100, Manuel Bouyer wrote:
>> I did some more instrumentation from the NetBSD kernel, including dumping
>> the iopic2 pin2 register.
>>
>> At the time of the command timeout, the register value is 0xa067,
>> which
flight 156855 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156855/
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 14.11.20 00:52, Daniel Kiper wrote:
> Hey,
>
> This is next attempt to create firmware and bootloader log specification.
> Due to high interest among industry it is an extension to the initial
> bootloader log only specification. It takes into the account most of the
> comments which I got up un
Hello Jan,
> On 17 Nov 2020, at 10:55 am, Jan Beulich wrote:
>
> On 16.11.2020 13:25, Rahul Singh wrote:
>> NS16550 driver has PCI support that is under HAS_PCI flag. When HAS_PCI
>> is enabled for ARM, compilation error is observed for ARM architecture
>> because ARM platforms do not have full
On Wed, Nov 18, 2020 at 03:39:28PM +0100, Roger Pau Monné wrote:
> > [...]
> > I can get the same effect by just doing ^A^A^A so my guess is that it's
> > not accessing the iopic's register which changes the IOAPIC_REDLO_RIRR bit,
> > but the XEN printf. Also, from NetBSD, using a dump fuinction wh
flight 156852 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156852/
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 18.11.2020 16:02, Rahul Singh wrote:
> Hello Jan,
>
>> On 17 Nov 2020, at 10:55 am, Jan Beulich wrote:
>>
>> On 16.11.2020 13:25, Rahul Singh wrote:
>>> NS16550 driver has PCI support that is under HAS_PCI flag. When HAS_PCI
>>> is enabled for ARM, compilation error is observed for ARM archite
Hi!
So I managed to get an agenda with basic questions. The meeting is at the
planned time (Nov the 19th, at 3PM central time, which is 9PM in UK and
10PM in Europe).
Meeting place will be: https://ibm.webex.com/meet/mendy
Don't forget to ping your colleagues/friends that aren't watching this
ma
On 18/11/2020 07:12, Michal Orzel wrote:
Hi Julien,
Hi Michal,
On 17.11.2020 18:30, Julien Grall wrote:
Hi Michal,
On 16/11/2020 12:11, Michal Orzel wrote:
On the affected Cortex-A76/Neoverse-N1 cores (r0p0 to r3p0),
if a virtual address for a cacheable mapping of a location is being
ac
Hi,
On 18/11/2020 15:16, Jan Beulich wrote:
On 18.11.2020 16:02, Rahul Singh wrote:
Hello Jan,
On 17 Nov 2020, at 10:55 am, Jan Beulich wrote:
On 16.11.2020 13:25, Rahul Singh wrote:
NS16550 driver has PCI support that is under HAS_PCI flag. When HAS_PCI
is enabled for ARM, compilation err
Hi Rahul,
On 16/11/2020 12:25, Rahul Singh wrote:
NS16550 driver has PCI support that is under HAS_PCI flag. When HAS_PCI
is enabled for ARM, compilation error is observed for ARM architecture
because ARM platforms do not have full PCI support available.
>
Introducing new kconfig option CONFIG
On Wed, Nov 18, 2020 at 04:54:51PM +0800, Coly Li wrote:
> On 11/18/20 4:47 PM, Christoph Hellwig wrote:
> > Don't bother to call lookup_bdev for just a slightly different error
> > message without any functional change.
> >
> > Signed-off-by: Christoph Hellwig ist
>
> Hi Christoph,
>
> NACK. Th
CentOS 6 is no longer supported by upstream so we cannot test against it
for future Xen releases.
Signed-off-by: Doug Goldstein
---
CC: Andrew Cooper
CC: George Dunlap
CC: Ian Jackson
CC: Jan Beulich
CC: Julien Grall
CC: Stefano Stabellini
CC: Wei Liu
---
automation/gitlab-ci/build.yaml |
On 11/17/20 12:24 PM, Edwin Török wrote:
> On CentOS 8 with SELinux containerize doesn't work at all:
>
> Make sure that the source code and SSH agent directories are passed on
> with SELinux relabeling enabled.
> (`-security-opt label=disabled` would be another option)
>
> Signed-off-by: Edwi
On 18/11/2020 16:27, Doug Goldstein wrote:
> CentOS 6 is no longer supported by upstream so we cannot test against it
> for future Xen releases.
>
> Signed-off-by: Doug Goldstein
> ---
> CC: Andrew Cooper
> CC: George Dunlap
> CC: Ian Jackson
> CC: Jan Beulich
> CC: Julien Grall
> CC: Stefano
On 11/17/20 12:24 PM, Edwin Török wrote:
> Signed-off-by: Edwin Török
Looks good. Do you have permissions to push the container or do you need
me to?
Acked-by: Doug Goldstein
On 11/18/20 10:39 AM, Andrew Cooper wrote:
> On 18/11/2020 16:27, Doug Goldstein wrote:
>> CentOS 6 is no longer supported by upstream so we cannot test against it
>> for future Xen releases.
>>
>> Signed-off-by: Doug Goldstein
>> ---
>> CC: Andrew Cooper
>> CC: George Dunlap
>> CC: Ian Jacks
On Wed, 2020-11-18 at 10:40 -0600, Doug Goldstein wrote:
>
>
> On 11/17/20 12:24 PM, Edwin Török wrote:
> > Signed-off-by: Edwin Török
>
> Looks good. Do you have permissions to push the container or do you
> need
> me to?
>
> Acked-by: Doug Goldstein
Thanks, if you could push it that'd be g
Hi,
On 13/11/2020 05:18, Jürgen Groß wrote:
On 12.11.20 22:38, Stefano Stabellini wrote:
On Thu, 12 Nov 2020, Jan Beulich wrote:
On 12.11.2020 13:50, Jürgen Groß wrote:
Any further comments, or even better, Acks?
To be honest I'd prefer to have at least one of the people Cc-ed
minimally ind
Hi Jan,
On 23/10/2020 11:16, Jan Beulich wrote:
This is, besides for tidying, in preparation of then starting to use an
archive rather than an object file for generic library code which
arch-es (or even specific configurations within a single arch) may or
may not need.
Signed-off-by: Jan Beulic
(+ Anthony)
Hi Jan,
On 23/10/2020 11:17, Jan Beulich wrote:
In order to (subsequently) drop odd things like CONFIG_NEEDS_LIST_SORT
just to avoid bloating binaries when only some arch-es and/or
configurations need generic library routines, combine objects under lib/
into an archive, which the li
Hi Jan,
On 23/10/2020 11:17, Jan Beulich wrote:
In order to (subsequently) drop odd things like CONFIG_NEEDS_LIST_SORT
just to avoid bloating binaries when only some arch-es and/or
configurations need generic library routines, combine objects under lib/
into an archive, which the linker then can
Hi Jan,
On 23/10/2020 11:17, Jan Beulich wrote:
Build the source file always, as by putting it into an archive it still
won't be linked into final binaries when not needed. This way possible
build breakage will be easier to notice, and it's more consistent with
us unconditionally building other
Hi Jan,
On 23/10/2020 11:17, Jan Beulich wrote:
... into its own CU, to build it into an archive.
Signed-off-by: Jan Beulich
... into its own CU, to build it into an archive.
Signed-off-by: Jan Beulich
Acked-by: Julien Grall
Cheers,
--
Julien Grall
Hi Jan,
On 23/10/2020 11:18, Jan Beulich wrote:
... into its own CU, for being unrelated to other things in
common/lib.c. For now it gets compiled into built_in.o rather than
lib.a, as it gets used unconditionally by Arm's as well as x86'es
{,__}start_xen().
AFAICT, parse_size_and_unit() is a
Hi Jan,
On 23/10/2020 11:18, Jan Beulich wrote:
Build this code into an archive, which results in not linking it into
x86 final binaries. This saves about 1.5k of dead code.
While moving the source file, take the opportunity and drop the
pointless EXPORT_SYMBOL().
Given this code is borrowed
On 18/11/2020 17:39, Julien Grall wrote:
Hi Jan,
On 23/10/2020 11:17, Jan Beulich wrote:
... into its own CU, to build it into an archive.
Signed-off-by: Jan Beulich
I forgot to mention the commit message was duplicated.
... into its own CU, to build it into an archive.
Signed-off-by
On 17/11/2020 18:24, Edwin Török wrote:
> Signed-off-by: Edwin Török
> ---
> automation/build/ubuntu/focal.dockerfile | 50
> automation/scripts/containerize | 1 +
> 2 files changed, 51 insertions(+)
> create mode 100644 automation/build/ubuntu/focal.dockerfil
Hi Jan,
On 23/10/2020 11:19, Jan Beulich wrote:
Convert this code to an inline function (backed by an instance in an
archive in case the compiler decides against inlining), which results
in not having it in x86 final binaries. This saves a little bit of dead
code.
Signed-off-by: Jan Beulich
--
Hi Jan,
On 23/10/2020 11:19, Jan Beulich wrote:
Build this code into an archive, partly paralleling bsearch().
Signed-off-by: Jan Beulich
Acked-by: Julien Grall
Cheers,
--
Julien Grall
On 17/11/2020 18:24, Edwin Török wrote:
> One can specify the domid to use when creating the domain, but this was
> hardcoded to 0.
>
> Keep the existing `domain_create` function (and the type of its parameters)
> as is to make
> backwards compatibility easier.
> Introduce a new `domain_create_do
flight 156860 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156860/
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
Hi Jan,
On 06/11/2020 07:11, 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.
I can see a few reasons why they are not suitable:
- xmalloc() will try to using an
1 - 100 of 116 matches
Mail list logo
