Using dprintk results in printing additionally file name and line
number. This is something we do not want when printing regular
information unconditionally as it looks like as if there was some issue.
It also makes the logging inconsistent.
Fix this by switching to printk because this information
flight 173228 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173228/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
Hi,
On 16/09/2022 08:19, Michal Orzel wrote:
Using dprintk results in printing additionally file name and line
number. This is something we do not want when printing regular
information unconditionally as it looks like as if there was some issue.
I am OK if you want to switch to a printk() but I
On Fri, Sep 16, 2022 at 01:20:11AM +0100, Ian Jackson wrote:
> Roger Pau Monné writes ("Re: [PATCH] libvirt: disable Werror for non-libvirt
> flights"):
> > I don't mind using -Dwerror=false if that's considered better. Ian, do
> > you have an opinion?
>
> No, I don't think I do. I think it depe
Hi Julien,
On 16/09/2022 10:08, Julien Grall wrote:
>
>
> Hi,
>
> On 16/09/2022 08:19, Michal Orzel wrote:
>> Using dprintk results in printing additionally file name and line
>> number. This is something we do not want when printing regular
>> information unconditionally as it looks like as if
On 16.09.2022 10:32, Michal Orzel wrote:
> On 16/09/2022 10:08, Julien Grall wrote:
>> On 16/09/2022 08:19, Michal Orzel wrote:
>>> Using dprintk results in printing additionally file name and line
>>> number. This is something we do not want when printing regular
>>> information unconditionally as
On Fri, Sep 16, 2022 at 08:22:43AM +0200, Adam Szewczyk wrote:
> I have QubesOS 4.1.1 with Xen 4.14.5 hypervisor system on which I want to
> install OpenBSD as a HVM and pass through my NICs to it (Intel Wireless
> AC-9560 and Realtek 8168 rev 0x15: RTL8168H/8111H). I tested that when
> installing
On Fri, Sep 16, 2022 at 07:57:59AM +0200, Jan Beulich wrote:
> ... this leads to the crash, which effectively tells us that this is
> likely yet another system where one needs to override the reboot
> method (e.g. reboot=acpi).
At least Linux, but also XenServer uses reboot=acpi by default (even o
flight 173229 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173229/
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 16/09/2022 09:32, Michal Orzel wrote:
Hi Julien,
Hi Michal,
On 16/09/2022 10:08, Julien Grall wrote:
Hi,
On 16/09/2022 08:19, Michal Orzel wrote:
Using dprintk results in printing additionally file name and line
number. This is something we do not want when printing regular
informa
On 09.09.22 17:43, Viresh Kumar wrote:
Hello Viresh
The iommu node will be required for other virtio device types too, not
just disk device.
Move the call to make_xen_iommu_node(), out of the disk device specific
block and rename "iommu_created" variable to "iommu_needed", and set it
to true
On 16.09.2022 11:53, Marek Marczykowski-Górecki wrote:
> On Fri, Sep 16, 2022 at 07:57:59AM +0200, Jan Beulich wrote:
>> ... this leads to the crash, which effectively tells us that this is
>> likely yet another system where one needs to override the reboot
>> method (e.g. reboot=acpi).
>
> At lea
On 16/09/2022 12:03, Julien Grall wrote:
>
>
> On 16/09/2022 09:32, Michal Orzel wrote:
>> Hi Julien,
>
> Hi Michal,
>
>> On 16/09/2022 10:08, Julien Grall wrote:
>>>
>>>
>>> Hi,
>>>
>>> On 16/09/2022 08:19, Michal Orzel wrote:
Using dprintk results in printing additionally file name an
flight 173232 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173232/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
On Fri, Sep 16, 2022 at 12:28:46PM +0200, Jan Beulich wrote:
> On 16.09.2022 11:53, Marek Marczykowski-Górecki wrote:
> > On Fri, Sep 16, 2022 at 07:57:59AM +0200, Jan Beulich wrote:
> >> ... this leads to the crash, which effectively tells us that this is
> >> likely yet another system where one n
flight 173225 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173225/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172128
build-amd64-libvirt
On Fri, Sep 16, 2022 at 12:55:06PM +0200, Marek Marczykowski-Górecki wrote:
> On Fri, Sep 16, 2022 at 12:28:46PM +0200, Jan Beulich wrote:
> > On 16.09.2022 11:53, Marek Marczykowski-Górecki wrote:
> > > On Fri, Sep 16, 2022 at 07:57:59AM +0200, Jan Beulich wrote:
> > >> ... this leads to the crash
On 16.09.2022 12:55, Marek Marczykowski-Górecki wrote:
> On Fri, Sep 16, 2022 at 12:28:46PM +0200, Jan Beulich wrote:
>> On 16.09.2022 11:53, Marek Marczykowski-Górecki wrote:
>>> On Fri, Sep 16, 2022 at 07:57:59AM +0200, Jan Beulich wrote:
... this leads to the crash, which effectively tells
On 15.09.2022 16:01, Tamas K Lengyel wrote:
> While experimenting with the vPMU subsystem an ASSERT failure was
> observed in vmx_find_msr because the vcpu_runnable state was true.
>
> The root cause of the bug appears to be the fact that the vPMU subsystem
> doesn't save its state on context_swit
Please keep xen-devel in Cc and avoid top-posting.
On Fri, Sep 16, 2022 at 02:35:17PM +0200, Adam Szewczyk wrote:
> After trying to configure previously disabled iwm0 interface first those
> errors appears:
>
> > iwm0: fw chunk addr Ox404000 len 712 failed to load
> > iwm0: could not load firmwar
Again, please keep xen-devel on Cc and don't top-post.
On Fri, Sep 16, 2022 at 03:19:30PM +0200, Adam Szewczyk wrote:
> I executed it in dom0 terminal and it prints lots of stuff, but when I run
> jus xl dmesg it prints almost the same logs. So I'm not sure if I have
> right output or what I shuld
flight 173227 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173227/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
test-amd64-i386-libvirt-raw 1 buil
flight 173234 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173234/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
On 14/09/2022 03:07, Ji, Ruili wrote:
[AMD Official Use Only - General]
Hi Paul,
Thank you!
But how could we merge this patch ?
AFAIK Anthony (anthony.per...@citrix.com) still deals with this.
Cheers,
Paul
Sorry, I always forgot that default answer is "answer" to not "answer to
all".
My xl dmesg after calling those debug-keys is:
> t=0 d0: 8(---)
> (XEN)IRQ: 9 vec:39 IO-APIC-level status=030 aff:{4}/{0-11}
> in-flight=0 d0: 9(---)
> (XEN)IRQ: 10 vec:78 IO-APIC-edgestatus=002 aff:
flight 173230 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173230/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172123
build-i386-libvir
Hi Jan,
On Thu, Sep 15, 2022 at 3:13 PM Jan Beulich wrote:
>
> On 26.08.2022 14:51, Carlo Nonato wrote:
> > This commit adds a new memory page allocator that implements the cache
> > coloring mechanism. The allocation algorithm follows the given color
> > configuration of the domain and maximizes
Hi Jan,
On Thu, Sep 15, 2022 at 3:25 PM Jan Beulich wrote:
>
> On 26.08.2022 14:51, Carlo Nonato wrote:
> > --- a/xen/common/vmap.c
> > +++ b/xen/common/vmap.c
> > @@ -8,6 +8,9 @@
> > #include
> > #include
> > #include
> > +#ifdef CONFIG_CACHE_COLORING
> > +#include
> > +#endif
>
> Even in
flight 173236 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173236/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
flight 173231 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173231/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 172133
build-i386-libvirt
Hi All,
This is a follow up discussion on the crash issue being discussed on the
IRC on 15th Sep.
For the context, the issue is as follows :-
Crash logs - https://pastebin.com/F2BKbW5a
Codebase :-
https://gitlab.com/ayankuma/xen-integration/-/tree/integration/mpu
The crash is observed in
>
> 00:00.0 Host bridge: Intel Corporation 8th Gen Core Processor Host
> Bridge/DRAM Registers (rev 07)
> Subsystem: Lenovo Device 3807
> Flags: bus master, fast devsel, latency 0
> Capabilities:
>
> 00:01.0 PCI bridge: Intel Corporation 6th-10th Gen Core Processor PCIe
> Controller (x16) (rev 07)
flight 173238 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173238/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
I made another experiment. I tried if eth pass trough works in HVMs with
other OSes. FreeBSD can't configure connection using DHCP. Ubuntu 22.04
kickstart the connection on Live Cd.
BR Adam
pt., 16 wrz 2022 o 21:26 Adam Szewczyk napisał(a):
> 00:00.0 Host bridge: Intel Corporation 8th Gen Core
flight 173235 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173235/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172128
build-amd64-libvirt
On 9/16/22 8:52 AM, Jan Beulich wrote:
On 15.09.2022 16:01, Tamas K Lengyel wrote:
While experimenting with the vPMU subsystem an ASSERT failure was
observed in vmx_find_msr because the vcpu_runnable state was true.
The root cause of the bug appears to be the fact that the vPMU subsystem
does
flight 173241 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173241/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
flight 173237 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173237/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172123
build-i386-libvir
flight 173243 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173243/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 2c17d676e402d75a3a674499342f7ddaccf387bd
baseline version:
ovmf 444260d45ec2a84e8f8c1
flight 173239 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173239/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 172133
build-i386-libvirt
Register common device reserved memory similar to how ivmd= parameter is
handled.
Signed-off-by: Marek Marczykowski-Górecki
Acked-by: Jan Beulich
---
Changes in v3:
- use variable initializer
- use pfn_to_paddr()
---
xen/drivers/passthrough/amd/iommu_acpi.c | 21 +
1 file
This allows configuring EHCI and XHCI consoles separately,
simultaneously.
This changes string_param() to custom_param() in both ehci and xhci
drivers. Both drivers parse only values applicable to them.
Suggested-by: Jan Beulich
Signed-off-by: Marek Marczykowski-Górecki
---
Changes in v7:
- res
The important part is to include those buffers in IOMMU page table
relevant for the USB controller. Otherwise, DbC will stop working as
soon as IOMMU is enabled, regardless of to which domain device assigned
(be it xen or dom0).
If the device is passed through to dom0 or other domain (see later
pat
Add API similar to rmrr= and ivmd= arguments, but in a common code. This
will allow drivers to register reserved memory regardless of the IOMMU
vendor.
The direct reason for this API is xhci-dbc console driver (aka xue),
that needs to use DMA. But future change may unify command line
arguments for
This is integration of https://github.com/connojd/xue into mainline Xen.
This patch series includes several patches that I made in the process, some are
very loosely related.
The driver developed by Connor supports console via USB3 debug capability. The
capability is designed to operate mostly ind
When cable is unplugged, dbc_ensure_running() correctly detects this
situation (DBC_CTRL_DCR flag is clear), and prevent sending data
immediately to the device. It gets only queued in work ring buffers.
When cable is plugged in again, subsequent dbc_flush() will send the
buffered data.
But there is
Re-use rmrr= parameter handling code to handle common device reserved
memory.
Signed-off-by: Marek Marczykowski-Górecki
---
Changes in v3:
- make MAX_USER_RMRR_PAGES applicable only to user-configured RMRR
---
xen/drivers/passthrough/vtd/dmar.c | 201 +-
1 file change
Add another work ring buffer for received data, and point IN TRB at it.
Ensure there is always at least one pending IN TRB, so the controller
has a way to send incoming data to the driver.
Note that both "success" and "short packet" completion codes are okay -
in fact it will be "short packet" most
That's possible, because the capability was designed specifically to
allow separate driver handle it, in parallel to unmodified xhci driver
(separate set of registers, pretending the port is "disconnected" for
the main xhci driver etc). It works with Linux dom0, although requires
an awful hack - re
Previously only one serial console was supported at the same time. Using
console=com1,dbgp,vga silently ignored all but last serial console (in
this case: only dbgp and vga were active).
Fix this by storing not a single sercon_handle, but an array of them, up
to MAX_SERCONS entries. The value of M
Similar to the EHCI driver - save/restore relevant BAR and command
register, re-configure DbC on resume and stop/start timer.
On resume trigger sending anything that was queued in the meantime.
Save full BAR value, instead of just the address part, to ease restoring
on resume.
Signed-off-by: Marek
Make it consistent with console=xhci.
Suggested-by: Jan Beulich
Signed-off-by: Marek Marczykowski-Górecki
---
docs/misc/xen-command-line.pandoc | 4 ++--
xen/drivers/char/serial.c | 6 ++
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/docs/misc/xen-command-line.pando
flight 173242 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173242/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf broken
build-armhf 5 host-build-p
53 matches
Mail list logo
