flight 152659 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152659/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail REGR. vs. 152631
test-amd64-amd64-
flight 152658 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152658/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 10 debian-hvm-install fail in
152644 pass in 152658
test-amd64-am
From: Michael Kurth
Add "all_symbols" to all /tools/symbols calls so that
xen-syms.map lists all symbols and not only .text section
symbols. This change enhances debugging and livepatch
capabilities.
Signed-off-by: Michael Kurth
Reviewed-by: Eslam Elnikety
Reviewed-by: Julien Grall
Reviewed-b
Jason,
On Fri, Aug 21 2020 at 21:51, Jason Gunthorpe wrote:
> On Sat, Aug 22, 2020 at 01:47:12AM +0200, Thomas Gleixner wrote:
>> > If the device has died the driver has code to detect and trigger a
>> > PCI function reset which will definitely stop the interrupt.
>>
>> If that interrupt is gone
On Sat, Aug 22, 2020 at 01:47:12AM +0200, Thomas Gleixner wrote:
> On Fri, Aug 21 2020 at 17:17, Jason Gunthorpe wrote:
> > On Fri, Aug 21, 2020 at 09:47:43PM +0200, Thomas Gleixner wrote:
> >> So if I understand correctly then the queue memory where the MSI
> >> descriptor sits is in RAM.
> >
> >
On Fri, Aug 21 2020 at 22:27, Thomas Gleixner wrote:
> Add a new quirk flag IRQCHIP_SHUTDOWN_ON_SUSPEND and add support for
> it the core interrupt suspend/resume paths.
>
> Changelog:
> v1->v2: Corrected the author's name to tglx@
Can you please move that Changelog part below the --- seperator ne
On Fri, Aug 21 2020 at 23:38, Sergei Temerkhanov wrote:
> On Fri, Aug 21, 2020 at 11:07 PM Thomas Gleixner wrote:
>> Fiddling in irqchip is wrong to begin with.
>>
>> int irq_set_handler_data(unsigned int irq, void *data);
>> static inline void *irq_get_handler_data(unsigned int irq)
>> static inl
flight 152656 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152656/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 7 xen-boot fail REGR. vs. 152614
test-amd64-i386-libvi
On Fri, Aug 21 2020 at 17:17, Jason Gunthorpe wrote:
> On Fri, Aug 21, 2020 at 09:47:43PM +0200, Thomas Gleixner wrote:
>> So if I understand correctly then the queue memory where the MSI
>> descriptor sits is in RAM.
>
> Yes, IMHO that is the whole point of this 'IMS' stuff. If devices
> could hav
The pull request you sent on Fri, 21 Aug 2020 20:02:17 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
> for-linus-5.9-rc2-tag
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/c0a4f5b354dc26573cfaa541064fd35a794eb166
Thank you!
--
Deet-doot-dot, I
On Fri, Aug 21, 2020 at 11:07 PM Thomas Gleixner wrote:
> Fiddling in irqchip is wrong to begin with.
>
> int irq_set_handler_data(unsigned int irq, void *data);
> static inline void *irq_get_handler_data(unsigned int irq)
> static inline void *irq_data_get_irq_handler_data(struct irq_data *d)
>
>
On Fri, Aug 21, 2020 at 09:47:43PM +0200, Thomas Gleixner wrote:
> On Fri, Aug 21 2020 at 09:45, Jason Gunthorpe wrote:
> > On Fri, Aug 21, 2020 at 02:25:02AM +0200, Thomas Gleixner wrote:
> >> +static void ims_mask_irq(struct irq_data *data)
> >> +{
> >> + struct msi_desc *desc = irq_data_get_msi
On Fri, Aug 21 2020 at 14:17, Jürgen Groß wrote:
> On 21.08.20 13:19, Sergei Temerkhanov wrote:
>>> Did you see any specific problem where handler_data is written by
>> another component?
>>
>> I've posted this series in the thread
>> https://lists.xenproject.org/archives/html/xen-devel/2020-08/ms
On Fri, Aug 21 2020 at 09:45, Jason Gunthorpe wrote:
> On Fri, Aug 21, 2020 at 02:25:02AM +0200, Thomas Gleixner wrote:
>> +static void ims_mask_irq(struct irq_data *data)
>> +{
>> +struct msi_desc *desc = irq_data_get_msi_desc(data);
>> +struct ims_array_slot __iomem *slot = desc->device_m
On 21/08/2020 15:32, George Dunlap wrote:
> Signed-off-by: George Dunlap
Acked-by: Andrew Cooper
Hi Stefano,
On 21/08/2020 01:53, Stefano Stabellini wrote:
On Thu, 20 Aug 2020, Oleksandr wrote:
On 11/08/2020 23:48, Stefano Stabellini wrote:
I have the impression that we disagree in what the Device Emulator is
meant to
do. IHMO, the goal of the device emulator is to emulate a device in an
Signed-off-by: George Dunlap
---
CC: Andrew Cooper
CC: Jan Beulich
CC: Roger Pau Monne
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 33fe51324e..978fc2fe72 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -521,8 +521,8 @@ F: d
On Fri, Aug 21, 2020 at 03:03:08PM +0100, Andrew Cooper wrote:
> On 21/08/2020 12:52, Roger Pau Monné wrote:
> > On Thu, Aug 20, 2020 at 06:08:53PM +0100, Andrew Cooper wrote:
> >> On 20/08/2020 16:08, Roger Pau Monne wrote:
> >>
> >>> diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c
> >>> inde
On 21/08/2020 12:52, Roger Pau Monné wrote:
> On Thu, Aug 20, 2020 at 06:08:53PM +0100, Andrew Cooper wrote:
>> On 20/08/2020 16:08, Roger Pau Monne wrote:
>>
>>> diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c
>>> index ca4307e19f..a890cb9976 100644
>>> --- a/xen/arch/x86/msr.c
>>> +++ b/xen/
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-5.9-rc2-tag
xen: branch for v5.9-rc2
It contains one build fix and a minor fix for suppressing a useless
warning when booting a Xen dom0 via UEFI.
Thanks.
Juergen
arch/x86/pci/xen
flight 152649 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152649/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail REGR. vs. 152332
test-amd64-i386-xl-
On 21.08.2020 17:10, Michael Kurth wrote:
> From: Michael Kurth
>
> Add "all_symbols" to all /tools/symbols calls so that
> xen-syms.map lists all symbols and not only .text section
> symbols. This change enhances debugging and livepatch
> capabilities.
With
ifdef CONFIG_LIVEPATCH
all_symbols =
On 21.08.2020 16:32, George Dunlap wrote:
> Signed-off-by: George Dunlap
Acked-by: Jan Beulich
On Thu, Aug 20, 2020 at 06:08:53PM +0100, Andrew Cooper wrote:
> On 20/08/2020 16:08, Roger Pau Monne wrote:
>
> > diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c
> > index ca4307e19f..a890cb9976 100644
> > --- a/xen/arch/x86/msr.c
> > +++ b/xen/arch/x86/msr.c
> > @@ -274,6 +274,14 @@ int gue
flight 152651 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152651/
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
On 21/08/2020 11:12, Olaf Hering wrote:
> While reviewing changed behavior in 'xen-cpuid -d' output between Xen 4.8 and
> 4.9 I found commit 20e92c97f904aa460e2223c30dcad36c234496b6 ("x86/cpuid: Only
> recalculate the shared feature bits once").
>
> I wonder what the mentioned "cross-vendor case"
On 21/08/2020 07:50, Jan Beulich wrote:
> On 20.08.2020 21:12, Roman Shaposhnik wrote:
>> On Thu, Aug 20, 2020 at 5:56 AM Andrew Cooper
>> wrote:
>>> On 19/08/2020 23:50, Roman Shaposhnik wrote:
Hi!
below you can see a trace of Xen 4.14.0 failing on Dell IoT Gateway 3001
with
On Fri, Aug 21, 2020 at 02:25:02AM +0200, Thomas Gleixner wrote:
> +static void ims_mask_irq(struct irq_data *data)
> +{
> + struct msi_desc *desc = irq_data_get_msi_desc(data);
> + struct ims_array_slot __iomem *slot = desc->device_msi.priv_iomem;
> + u32 __iomem *ctrl = &slot->ctrl;
>
flight 152644 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152644/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 10 debian-hvm-install fail REGR.
vs. 152597
Tests w
On 21.08.20 13:19, Sergei Temerkhanov wrote:
Did you see any specific problem where handler_data is written by
another component?
I've posted this series in the thread
https://lists.xenproject.org/archives/html/xen-devel/2020-08/msg00957.html
where the problem is caused exactly by that behavior
>Did you see any specific problem where handler_data is written by
another component?
I've posted this series in the thread
https://lists.xenproject.org/archives/html/xen-devel/2020-08/msg00957.html
where the problem is caused exactly by that behavior
>In case this is a real problem I don't think
On 21.08.20 09:16, Jan Beulich wrote:
Hi Jan.
Thank you for your answer.
On 20.08.2020 20:30, Oleksandr wrote:
On 06.08.20 14:29, Jan Beulich wrote:
On 06.08.2020 13:08, Julien Grall wrote:
On 05/08/2020 20:30, Oleksandr wrote:
I was thinking how to split handle_hvm_io_completion()
grace
Let's use the new mechanism to merge system ram resources below the
root. We are the only one hotplugging system ram, e.g., DIMMs don't apply,
so this is safe to be used.
Cc: Andrew Morton
Cc: Michal Hocko
Cc: "K. Y. Srinivasan"
Cc: Haiyang Zhang
Cc: Stephen Hemminger
Cc: Wei Liu
Cc: Pankaj
virtio-mem adds memory in memory block granularity, to be able to
remove it in the same granularity again later, and to grow slowly on
demand. This, however, results in quite a lot of resources when
adding a lot of memory. Resources are effectively stored in a list-based
tree. Having a lot of resou
Let's reuse the new mechanism to merge system ram resources below the
root. We are the only one hotplugging system ram (e.g., DIMMs don't apply),
so this is safe to be used.
Cc: Andrew Morton
Cc: Michal Hocko
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: Roger Pau Monné
Cc
This is the follow-up of "[PATCH RFCv1 0/5] mm/memory_hotplug: selective
merging of memory resources" [1]
Some add_memory*() users add memory in small, contiguous memory blocks.
Examples include virtio-mem, hyper-v balloon, and the XEN balloon.
This can quickly result in a lot of memory resources
Some add_memory*() users add memory in small, contiguous memory blocks.
Examples include virtio-mem, hyper-v balloon, and the XEN balloon.
This can quickly result in a lot of memory resources, whereby the actual
resource boundaries are not of interest (e.g., it might be relevant for
DIMMs, exposed
Let's make sure splitting a resource on memory hotunplug will never fail.
This will become more relevant once we merge selected system ram
resources - then, we'll trigger that case more frequently on memory
hotunplug.
In general, this function is already unlikely to fail. When we remove
memory, we
On 21.08.20 09:15, Sergey Temerkhanov wrote:
Use a dedicated pointer for IRQ data to avoid conflicts with some
other parts of the kernel code which my use handler_data for their
own purposes while still running on Xen
Sergey Temerkhanov (2):
Xen: Use a dedicated irq_info structure pointer
While reviewing changed behavior in 'xen-cpuid -d' output between Xen 4.8 and
4.9 I found commit 20e92c97f904aa460e2223c30dcad36c234496b6 ("x86/cpuid: Only
recalculate the shared feature bits once").
I wonder what the mentioned "cross-vendor case" in the comment, which was
removed from sanitise
On 20.08.20 20:35, Stefano Stabellini wrote:
> Thank for the well-written analysis of the problem. The following
should
> work to translate the virtual address properly in xenbus_grant_ring:
>
> if (is_vmalloc_addr(vaddr))
> page = vmalloc_to_page(vaddr);
> else
>
On 21.08.2020 09:38, Roman Shaposhnik wrote:
> On Thu, Aug 20, 2020 at 11:47 PM Jan Beulich wrote:
>> On 20.08.2020 21:31, Roman Shaposhnik wrote:
>>> Well, default is overloaded. What I would like to see (and consider it
>>> a void of a small downstream/distro) is a community-agreed and
>>> maint
On 20.08.2020 18:28, Andrew Cooper wrote:
> On 20/08/2020 16:34, Roger Pau Monne wrote:
>> Currently the dpci EOI callback is only executed for specific EOIs.
>> This is wrong as non-specific EOIs will also clear the ISR bit and
>> thus end the interrupt. Re-arrange the code a bit so that the commo
On Thu, Aug 20, 2020 at 11:47 PM Jan Beulich wrote:
>
> On 20.08.2020 21:31, Roman Shaposhnik wrote:
> > On Thu, Aug 20, 2020 at 1:34 AM Jan Beulich wrote:
> >> On 20.08.2020 00:50, Roman Shaposhnik wrote:
> >>> (XEN) Unknown cachability for MFNs 0xff900-0xf
> >>
> >> The fault address fallin
Use a dedicated pointer for IRQ data to avoid conflicts with some
other parts of the kernel code which my use handler_data for their
own purposes while still running on Xen
Sergey Temerkhanov (2):
Xen: Use a dedicated irq_info structure pointer
Xen: Rename irq_info structure
drivers/xen/even
Rename irq_info structure to xen_irq_info to avoid namespace
conflicts
Signed-off-by: Sergey Temerkhanov
---
drivers/xen/events/events_2l.c | 2 +-
drivers/xen/events/events_base.c | 60 ++--
drivers/xen/events/events_fifo.c | 5 ++-
drivers/xen/events/eve
Use a dedicated irq_info structure pointer to avoid conflicts
with other parts of the kernel code
Signed-off-by: Sergey Temerkhanov
---
drivers/xen/events/events_base.c | 62 +++-
include/linux/irq.h | 15
kernel/irq/chip.c| 14 ++
47 matches
Mail list logo
