On Sat, Jan 30, 2021 at 12:50:13PM +0100, Manuel Bouyer wrote:
> On Thu, Jan 28, 2021 at 12:08:02PM +0100, Roger Pau Monné wrote:
> > [...]
> > Also, the qemu-ifup script doesn't seem to be part of the NetBSD
> > scripts that are upstream, is this something carried by the NetBSD
> > package?
>
> A
On Sun, Jan 31, 2021 at 10:13:49AM -0800, Elliott Mitchell wrote:
> On Thu, Jan 28, 2021 at 10:42:27PM +, George Dunlap wrote:
> >
> > > On Jan 28, 2021, at 6:26 PM, Elliott Mitchell wrote:
> > > type = "hvm"
> > > memory = 1024
> > > maxmem = 1073741824
> > >
> > > I suspect maxmem > free X
On Sun, Jan 31, 2021 at 12:03:00AM +0100, Manuel Bouyer wrote:
> Document that on NetBSD, the tap interface will be configured by the
> qemu-ifup script. Document the arguments, and XEN_DOMAIN_ID environnement
> variable.
You are missing a Signed-off-by tag here ;).
> ---
> docs/man/xl-network-c
On 31/01/21 15:18, Philippe Mathieu-Daudé wrote:
9pfs is not an accelerator feature but a machine one,
move the selection on the machine Kconfig (in hw/).
Signed-off-by: Philippe Mathieu-Daudé
---
accel/Kconfig | 1 -
hw/i386/xen/Kconfig | 1 +
hw/xen/Kconfig | 1 +
3 files chan
On 30.01.2021 00:40, Tamas K Lengyel wrote:
> On Fri, Jan 29, 2021 at 6:22 PM Andrew Cooper
> wrote:
>>
>> On 26/01/2021 14:27, Jan Beulich wrote:
>>> On 21.01.2021 22:27, Andrew Cooper wrote:
--- a/xen/arch/x86/vm_event.c
+++ b/xen/arch/x86/vm_event.c
@@ -251,6 +251,9 @@ void vm_e
On 01/02/2021 08:55, Jan Beulich wrote:
> On 30.01.2021 00:40, Tamas K Lengyel wrote:
>> On Fri, Jan 29, 2021 at 6:22 PM Andrew Cooper
>> wrote:
>>> On 26/01/2021 14:27, Jan Beulich wrote:
On 21.01.2021 22:27, Andrew Cooper wrote:
> --- a/xen/arch/x86/vm_event.c
> +++ b/xen/arch/x86/
On 2/1/21 9:34 AM, Paolo Bonzini wrote:
> On 31/01/21 15:18, Philippe Mathieu-Daudé wrote:
>> 9pfs is not an accelerator feature but a machine one,
>> move the selection on the machine Kconfig (in hw/).
>>
>> Signed-off-by: Philippe Mathieu-Daudé
>> ---
>> accel/Kconfig | 1 -
>> hw/i386/
On 30.01.2021 03:59, Andrew Cooper wrote:
> On 30/01/2021 01:59, Tamas K Lengyel wrote:
>> When using gdbsx dbg_rw_guest_mem is used to read/write guest memory. When
>> the
>> buffer being accessed is on a page-boundary, the next page needs to be
>> grabbed
>> to access the correct memory for the
On Mon, Feb 01, 2021 at 09:21:58AM +0100, Roger Pau Monné wrote:
> On Sun, Jan 31, 2021 at 12:03:00AM +0100, Manuel Bouyer wrote:
> > Document that on NetBSD, the tap interface will be configured by the
> > qemu-ifup script. Document the arguments, and XEN_DOMAIN_ID environnement
> > variable.
>
>
On Mon, Feb 01, 2021 at 09:06:13AM +0100, Roger Pau Monné wrote:
> On Sat, Jan 30, 2021 at 12:50:13PM +0100, Manuel Bouyer wrote:
> > On Thu, Jan 28, 2021 at 12:08:02PM +0100, Roger Pau Monné wrote:
> > > [...]
> > > Also, the qemu-ifup script doesn't seem to be part of the NetBSD
> > > scripts tha
On 30.01.2021 16:22, Julien Grall wrote:
> @@ -1442,13 +1447,6 @@ long do_memory_op(unsigned long cmd,
> XEN_GUEST_HANDLE_PARAM(void) arg)
> if ( d == NULL )
> return -ESRCH;
>
> -rc = xatp_permission_check(d, xatpb.space);
> -if ( rc )
> -{
> -
On 30.01.2021 03:58, Andrew Cooper wrote:
> From: Tamas K Lengyel
>
> Add vmtrace_pos field to x86 regs in vm_event. Initialized to ~0 if
> vmtrace is not in use.
>
> Signed-off-by: Tamas K Lengyel
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
On Sat, Jan 30, 2021 at 02:58:42AM +, Andrew Cooper wrote:
> A guest's default number of grant frames is 64, and XENMEM_acquire_resource
> will reject an attempt to map more than 32 frames. This limit is caused by
> the size of mfn_list[] on the stack.
>
> Fix mapping of arbitrary size reques
On 01/02/21 10:18, Philippe Mathieu-Daudé wrote:
FYI using 'imply FSDEV_9P' instead I get:
/usr/bin/ld: libcommon.fa.p/hw_xen_xen-legacy-backend.c.o: in function
`xen_be_register_common':
hw/xen/xen-legacy-backend.c:754: undefined reference to `xen_9pfs_ops'
Ok, so then we have the case of a f
On Sat, Jan 30, 2021 at 02:58:43AM +, Andrew Cooper wrote:
> We're about to introduce support for Intel Processor Trace, but similar
> functionality exists in other platforms.
>
> Aspects of vmtrace can reasonably can be common, so start with
> XEN_SYSCTL_PHYSCAP_vmtrace and plumb the signal f
> On Jan 31, 2021, at 6:13 PM, Elliott Mitchell wrote:
>
> On Thu, Jan 28, 2021 at 10:42:27PM +, George Dunlap wrote:
>>
>>> On Jan 28, 2021, at 6:26 PM, Elliott Mitchell wrote:
>>> type = "hvm"
>>> memory = 1024
>>> maxmem = 1073741824
>>>
>>> I suspect maxmem > free Xen memory may be s
On Sat, Jan 30, 2021 at 02:58:44AM +, Andrew Cooper wrote:
> From: Michał Leszczyński
>
> To use vmtrace, buffers of a suitable size need allocating, and different
> tasks will want different sizes.
>
> Add a domain creation parameter, and audit it appropriately in the
> {arch_,}sanitise_dom
On Mon, Feb 01, 2021 at 10:39:39AM +0100, Manuel Bouyer wrote:
> On Mon, Feb 01, 2021 at 09:06:13AM +0100, Roger Pau Monné wrote:
> > On Sat, Jan 30, 2021 at 12:50:13PM +0100, Manuel Bouyer wrote:
> > > On Thu, Jan 28, 2021 at 12:08:02PM +0100, Roger Pau Monné wrote:
> > > > [...]
> > > > Also, the
On Mon, Feb 01, 2021 at 10:37:47AM +0100, Manuel Bouyer wrote:
> On Mon, Feb 01, 2021 at 09:21:58AM +0100, Roger Pau Monné wrote:
> > On Sun, Jan 31, 2021 at 12:03:00AM +0100, Manuel Bouyer wrote:
> > > Document that on NetBSD, the tap interface will be configured by the
> > > qemu-ifup script. Doc
On 1/31/21 3:18 PM, Philippe Mathieu-Daudé wrote:
> xenpv machine requires USB, IDE_PIIX and PCI:
>
> /usr/bin/ld:
> libcommon.fa.p/hw_xen_xen-legacy-backend.c.o: in function
> `xen_be_register_common':
> hw/xen/xen-legacy-backend.c:757: undefined reference to `xen_usb_ops'
> libqemu-i386
On 2/1/21 11:23 AM, Paolo Bonzini wrote:
> On 01/02/21 10:18, Philippe Mathieu-Daudé wrote:
>> FYI using 'imply FSDEV_9P' instead I get:
>>
>> /usr/bin/ld: libcommon.fa.p/hw_xen_xen-legacy-backend.c.o: in function
>> `xen_be_register_common':
>> hw/xen/xen-legacy-backend.c:754: undefined reference
On 01/02/21 11:59, Philippe Mathieu-Daudé wrote:
On 1/31/21 3:18 PM, Philippe Mathieu-Daudé wrote:
xenpv machine requires USB, IDE_PIIX and PCI:
/usr/bin/ld:
libcommon.fa.p/hw_xen_xen-legacy-backend.c.o: in function
`xen_be_register_common':
hw/xen/xen-legacy-backend.c:757: undefined
On 01/02/2021 10:10, Roger Pau Monné wrote:
> On Sat, Jan 30, 2021 at 02:58:42AM +, Andrew Cooper wrote:
>> A guest's default number of grant frames is 64, and XENMEM_acquire_resource
>> will reject an attempt to map more than 32 frames. This limit is caused by
>> the size of mfn_list[] on the
On 01/02/2021 10:51, Roger Pau Monné wrote:
> On Sat, Jan 30, 2021 at 02:58:44AM +, Andrew Cooper wrote:
>> From: Michał Leszczyński
>>
>> To use vmtrace, buffers of a suitable size need allocating, and different
>> tasks will want different sizes.
>>
>> Add a domain creation parameter, and au
On Mon, Feb 01, 2021 at 11:54:35AM +0100, Roger Pau Monné wrote:
> > I can, but how do I get the ecript removed from qemu-traditional ?
> > It's a different repo, isn't it ?
>
> Yes, it's:
>
> http://xenbits.xen.org/gitweb/?p=qemu-xen-traditional.git;a=summary
>
> I would remove it from qemu-tra
Sort the Xen buildsys glue a bit.
The first patches are probably ready now.
Since v2:
- Addressed some of Paolo's comments
- More fixes
- XEN_PV still not buildable alone -> postponed
v2: Considered Paolo's comments from v1
Philippe Mathieu-Daudé (7):
meson: Do not build Xen x86_64-softmmu on
The Xen on ARM documentation only mentions the i386-softmmu
target. As the x86_64-softmmu doesn't seem used, remove it
to avoid wasting cpu cycles building it.
Signed-off-by: Philippe Mathieu-Daudé
---
meson.build | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/meson.bui
Relax the dependency on 9pfs by using the 'imply' Kconfig rule.
This fixes when XEN_PV without XEN_FV:
/usr/bin/ld: libcommon.fa.p/hw_xen_xen-legacy-backend.c.o: in function
`xen_be_register_common':
hw/xen/xen-legacy-backend.c:754: undefined reference to `xen_9pfs_ops'
Suggested-by: Paolo
xen-mapcache.c contains accelerator related routines,
not particular to the X86 HVM machine. Move this file
to accel/xen/ (adapting the buildsys machinery).
Signed-off-by: Philippe Mathieu-Daudé
---
meson.build | 3 +++
accel/xen/trace.h | 1 +
{hw
Introduce XEN_FV to differency the machine from the accelerator.
Suggested-by: Paolo Bonzini
Signed-off-by: Philippe Mathieu-Daudé
---
hw/i386/Kconfig | 2 ++
hw/i386/xen/Kconfig | 5 +
hw/i386/xen/meson.build | 2 +-
3 files changed, 8 insertions(+), 1 deletion(-)
create mode
xen_shutdown_fatal_error() is also used by XEN_PV.
This fixes when XEN_PV without XEN_FV:
/usr/bin/ld: libqemu-x86_64-softmmu.fa.p/hw_xen_xen_pt_config_init.c.o: in
function `xen_pt_status_reg_init':
hw/xen/xen_pt_config_init.c:281: undefined reference to
`xen_shutdown_fatal_error'
/usr/b
qmp_xen_set_global_dirty_log() is also used by XEN_PV.
This fixes when XEN_PV without XEN_FV:
/usr/bin/ld:
libqemuutil.a(meson-generated_.._qapi_qapi-commands-migration.c.o): in function
`qmp_marshal_xen_set_global_dirty_log':
qapi/qapi-commands-migration.c:626: undefined reference to
`qmp
xenpv machine requires USB, IDE_PIIX and PCI:
/usr/bin/ld:
libcommon.fa.p/hw_xen_xen-legacy-backend.c.o: in function
`xen_be_register_common':
hw/xen/xen-legacy-backend.c:757: undefined reference to `xen_usb_ops'
libqemu-i386-softmmu.fa.p/hw_i386_xen_xen_platform.c.o: in function
`unplug
On 01/02/2021 09:37, Jan Beulich wrote:
> On 30.01.2021 03:59, Andrew Cooper wrote:
>> On 30/01/2021 01:59, Tamas K Lengyel wrote:
>>> When using gdbsx dbg_rw_guest_mem is used to read/write guest memory. When
>>> the
>>> buffer being accessed is on a page-boundary, the next page needs to be
>>>
On Sat, Jan 30, 2021 at 02:58:48AM +, Andrew Cooper wrote:
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> index 12b961113e..a64c4e4177 100644
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -2261,6 +2261,157 @@ static bool vmx_get_pending_eve
On Mon, Feb 01, 2021 at 11:11:37AM +, Andrew Cooper wrote:
> On 01/02/2021 10:10, Roger Pau Monné wrote:
> > On Sat, Jan 30, 2021 at 02:58:42AM +, Andrew Cooper wrote:
> >> +(COMPAT_ARG_XLAT_SIZE - sizeof(*nat.mar)) /
> >> +sizeof(*xen_frame_list);
>
On 01/02/2021 12:07, Roger Pau Monné wrote:
> On Mon, Feb 01, 2021 at 11:11:37AM +, Andrew Cooper wrote:
>> On 01/02/2021 10:10, Roger Pau Monné wrote:
>>> On Sat, Jan 30, 2021 at 02:58:42AM +, Andrew Cooper wrote:
+(COMPAT_ARG_XLAT_SIZE - sizeof(*nat.mar)) /
+
On 01.02.2021 12:44, Andrew Cooper wrote:
> On 01/02/2021 09:37, Jan Beulich wrote:
>> On 30.01.2021 03:59, Andrew Cooper wrote:
>>> On 30/01/2021 01:59, Tamas K Lengyel wrote:
When using gdbsx dbg_rw_guest_mem is used to read/write guest memory. When
the
buffer being accessed is on
On 30.01.21 04:58, Andrew Cooper wrote:
Hi Andrew
Combined series (as they are dependent). First, the resource size fixes, and
then the external IPT monitoring built on top.
Posting in full for reference, but several patches are ready to go in. Those
in need of review are patch 6, 8 and 12
The latter two patches are meant to address a regression reported on
the list under "Problems with APIC on versions 4.9 and later (4.8
works)". In the course of analyzing output from a debugging patch I
ran into another anomaly again, which I thought I should finally try
to address. Hence patch 1.
Setting the timer a second (EPOCH) into the future at a random point
during boot (prior to bringing up APs and prior to launching Dom0) does
not yield predictable results: The timer may expire while we're still
bringing up APs (too early) or when Dom0 already boots (too late).
Instead invoke the ti
flight 158873 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158873/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 158835
test-amd64-amd64-xl-qemuu-ws16-amd64
The (stime,tsc) tuple is the basis for extrapolation by get_s_time().
Therefore the two better get taken as close to one another as possible.
This means two things: First, reading platform time is too early when
done on the first iteration. The closest we can get is on the last
iteration, immediate
While doing this for small amounts may be okay, the unconditional use
of CPU0's value here has been found to be a problem when the boot time
TSC of the BSP was behind that of all APs by more than a second. In
particular because of get_s_time_fixed() producing insane output when
the calculated delta
flight 158874 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158874/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf ea56ebf67dd55483105aa9f9996a48213e78337e
baseline version:
ovmf c6be6dab9c4bdf135bc02
On 29.01.2021 20:31, Claudemir Todo Bom wrote:
> I've applied both patches, system didn't booted, used following parameters:
>
> xen: dom0_mem=1024M,max:2048M dom0_max_vcpus=4 dom0_vcpus_pin=true smt=true
> kernel: loglevel=3
>
> The screen cleared right after the initial xen messages and frozen
On 29.01.2021 18:17, Andrew Cooper wrote:
> On 29/01/2021 16:31, Jan Beulich wrote:
>> On 29.01.2021 17:17, Andrew Cooper wrote:
>>> On 29/01/2021 11:29, Jan Beulich wrote:
On 25.01.2021 18:59, Andrew Cooper wrote:
> On 20/01/2021 08:06, Jan Beulich wrote:
>> Also, as far as "impossibl
On 29.01.2021 19:18, Andrew Cooper wrote:
> On 29/01/2021 09:46, Jan Beulich wrote:
>> On 29.01.2021 00:44, Andrew Cooper wrote:
>>> On 15/01/2021 16:12, Jan Beulich wrote:
On 12.01.2021 20:48, Andrew Cooper wrote:
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -4628,7 +4
On 01/02/2021 12:01, Roger Pau Monné wrote:
> On Sat, Jan 30, 2021 at 02:58:48AM +, Andrew Cooper wrote:
>> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
>> index 12b961113e..a64c4e4177 100644
>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> @@ -
On 01.02.2021 12:11, Andrew Cooper wrote:
> On 01/02/2021 10:10, Roger Pau Monné wrote:
>> On Sat, Jan 30, 2021 at 02:58:42AM +, Andrew Cooper wrote:
>>> @@ -636,15 +662,45 @@ int compat_memory_op(unsigned int cmd,
>>> XEN_GUEST_HANDLE_PARAM(void) compat)
>>> compat_frame_
On 01/02/2021 12:34, Oleksandr wrote:
>
> On 30.01.21 04:58, Andrew Cooper wrote:
>
> Hi Andrew
>
>> Combined series (as they are dependent). First, the resource size
>> fixes, and
>> then the external IPT monitoring built on top.
>>
>> Posting in full for reference, but several patches are ready
On 2/1/21 12:29 PM, Philippe Mathieu-Daudé wrote:
> xen-mapcache.c contains accelerator related routines,
> not particular to the X86 HVM machine. Move this file
> to accel/xen/ (adapting the buildsys machinery).
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> meson.build
On 2/1/21 12:29 PM, Philippe Mathieu-Daudé wrote:
> xen_shutdown_fatal_error() is also used by XEN_PV.
>
> This fixes when XEN_PV without XEN_FV:
>
> /usr/bin/ld: libqemu-x86_64-softmmu.fa.p/hw_xen_xen_pt_config_init.c.o: in
> function `xen_pt_status_reg_init':
> hw/xen/xen_pt_config_init.c:
On 30.01.2021 03:58, Andrew Cooper wrote:
> +static int vmtrace_alloc_buffer(struct vcpu *v)
> +{
> +struct domain *d = v->domain;
> +struct page_info *pg;
> +unsigned int i;
> +
> +if ( !d->vmtrace_size )
> +return 0;
> +
> +pg = alloc_domheap_pages(d, get_order_from_by
On 29.01.2021 17:48, George Dunlap wrote:
> When in "autoballoon" mode, xl will attempt to balloon dom0 down in
> order to free up memory to start a guest, based on the expected amount
> of memory reported by libxl. Currently, this is limited in libxl with
> a hard-coded value of 128MiB, to preven
On 01.02.21 15:07, Andrew Cooper wrote:
Hi Andrew
On 01/02/2021 12:34, Oleksandr wrote:
On 30.01.21 04:58, Andrew Cooper wrote:
Hi Andrew
Combined series (as they are dependent). First, the resource size
fixes, and
then the external IPT monitoring built on top.
Posting in full for refer
> On Feb 1, 2021, at 1:39 PM, Jan Beulich wrote:
>
> On 29.01.2021 17:48, George Dunlap wrote:
>> When in "autoballoon" mode, xl will attempt to balloon dom0 down in
>> order to free up memory to start a guest, based on the expected amount
>> of memory reported by libxl. Currently, this is lim
On 01/02/2021 13:47, Oleksandr wrote:
>
> On 01.02.21 15:07, Andrew Cooper wrote:
>
> Hi Andrew
>
>> On 01/02/2021 12:34, Oleksandr wrote:
>>> On 30.01.21 04:58, Andrew Cooper wrote:
>>
>> One query I did leave on IRC, and hasn't had an answer.
>>
>> What is the maximum number of vcpus in an ARM gu
On 01/02/2021 13:03, Jan Beulich wrote:
> On 01.02.2021 12:11, Andrew Cooper wrote:
>> On 01/02/2021 10:10, Roger Pau Monné wrote:
>>> On Sat, Jan 30, 2021 at 02:58:42AM +, Andrew Cooper wrote:
@@ -636,15 +662,45 @@ int compat_memory_op(unsigned int cmd,
XEN_GUEST_HANDLE_PARAM(void)
On 29.01.2021 00:32, Andrew Cooper wrote:
> On 15/01/2021 15:37, Jan Beulich wrote:
>> On 12.01.2021 20:48, Andrew Cooper wrote:
>>> @@ -446,6 +430,31 @@ int compat_memory_op(unsigned int cmd,
>>> XEN_GUEST_HANDLE_PARAM(void) compat)
>>>
>>> #undef XLAT_mem_acquire_resource_HNDL_frame_list
>>>
On 01/02/2021 13:18, Jan Beulich wrote:
> On 30.01.2021 03:58, Andrew Cooper wrote:
>> +static int vmtrace_alloc_buffer(struct vcpu *v)
>> +{
>> +struct domain *d = v->domain;
>> +struct page_info *pg;
>> +unsigned int i;
>> +
>> +if ( !d->vmtrace_size )
>> +return 0;
>> +
>
On Mon, Feb 01, 2021 at 01:00:47PM +, Andrew Cooper wrote:
> On 01/02/2021 12:01, Roger Pau Monné wrote:
> > On Sat, Jan 30, 2021 at 02:58:48AM +, Andrew Cooper wrote:
> >> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> >> index 12b961113e..a64c4e4177 100644
> >> ---
On 01.02.2021 15:04, Andrew Cooper wrote:
> On 01/02/2021 13:03, Jan Beulich wrote:
>> On 01.02.2021 12:11, Andrew Cooper wrote:
>>> On 01/02/2021 10:10, Roger Pau Monné wrote:
On Sat, Jan 30, 2021 at 02:58:42AM +, Andrew Cooper wrote:
> @@ -636,15 +662,45 @@ int compat_memory_op(unsig
On 01.02.2021 15:22, Andrew Cooper wrote:
> On 01/02/2021 13:18, Jan Beulich wrote:
>> On 30.01.2021 03:58, Andrew Cooper wrote:
>>> +static int vmtrace_alloc_buffer(struct vcpu *v)
>>> +{
>>> +struct domain *d = v->domain;
>>> +struct page_info *pg;
>>> +unsigned int i;
>>> +
>>> +
Julien Grall writes ("[PATCH for-4.15] xen/mm: Fix build when CONFIG_HVM=n and
CONFIG_COVERAGE=y"):
> Xen is heavily relying on the DCE stage to remove unused code so the
> linker doesn't throw an error because a function is not implemented
> yet we defined a prototype for it.
Thanks for the clea
Manuel Bouyer writes ("[PATCH v3 1/2] libs/light: pass some infos to qemu"):
> Pass bridge name to qemu as command line option
> When starting qemu, set an environnement variable XEN_DOMAIN_ID,
> to be used by qemu helper scripts
> The only functional difference of using the br parameter is that th
Going through an intermediate *.new file requires telling the compiler
what the real target is, so that the inclusion of the resulting .*.d
file will actually be useful.
Fixes: 7d2d7a43d014 ("x86/build: limit rebuilding of asm-offsets.h")
Reported-by: Julien Grall
Signed-off-by: Jan Beulich
---
Roger Pau Monné writes ("Re: [PATCH v3 2/2] Document qemu-ifup on NetBSD"):
> On Mon, Feb 01, 2021 at 10:37:47AM +0100, Manuel Bouyer wrote:
> > Well, as a user, I want to know how the scripts are called, so that I can
> > tune them ...
>
> Isn't that information on the header of the script? I wou
On 01.02.2021 15:54, Ian Jackson wrote:
> Julien Grall writes ("[PATCH for-4.15] xen/mm: Fix build when CONFIG_HVM=n
> and CONFIG_COVERAGE=y"):
>> Xen is heavily relying on the DCE stage to remove unused code so the
>> linker doesn't throw an error because a function is not implemented
>> yet we d
George Dunlap writes ("Re: [PATCH for 4.16] xl: Add xl.conf-based dom0
autoballoon limits"):
> I’d certainly be in favor of getting something like b61443b1bf76
> upstream. I still think a patch like this one would be useful
> though:
>
> 1. The error message will be given right away, rather than
On 01/02/2021 14:56, Jan Beulich wrote:
> Going through an intermediate *.new file requires telling the compiler
> what the real target is, so that the inclusion of the resulting .*.d
> file will actually be useful.
>
> Fixes: 7d2d7a43d014 ("x86/build: limit rebuilding of asm-offsets.h")
> Reported
Manuel Bouyer writes ("[PATCH v3 1/2] xenpmd.c: use dynamic allocation"):
> On NetBSD, d_name is larger than 256, so file_name[284] may not be large
> enough (and gcc emits a format-truncation error).
> Use asprintf() instead of snprintf() on a static on-stack buffer.
>
> Signed-off-by: Manuel Bou
On 01.02.2021 15:46, Claudemir Todo Bom wrote:
> Tested first without the debug patch and with following parameters:
And this test was all three of the non-debugging patches?
> xen: dom0_mem=1024M,max:2048M dom0_max_vcpus=4 dom0_vcpus_pin=true smt=true
> kernel: loglevel=3
>
> same behaviour as
Manuel Bouyer writes ("[PATCH v3 2/2] define GNU_SOURCE for asprintf()"):
> #define _GNU_SOURCE to get for asprintf() prototype on Linux.
> Harmless on NetBSD.
Release-Acked-by: Ian Jackson
This needs to be folded into the previous patch so I will do so.
Ian.
Jan Beulich writes ("Re: [PATCH for-4.15] xen/mm: Fix build when CONFIG_HVM=n
and CONFIG_COVERAGE=y [and 1 more messages]"):
> On 01.02.2021 15:54, Ian Jackson wrote:
> > Julien Grall writes ("[PATCH for-4.15] xen/mm: Fix build when CONFIG_HVM=n
> > and CONFIG_COVERAGE=y"):
...
> > Jan, can you c
Andrew Cooper writes ("Re: [PATCH] x86/build: correctly record dependencies of
asm-offsets.s"):
> On 01/02/2021 14:56, Jan Beulich wrote:
> > Going through an intermediate *.new file requires telling the compiler
> > what the real target is, so that the inclusion of the resulting .*.d
> > file wil
We consider this error path of hvm_alloc_ioreq_mfn() to not be possible
to be taken, or otherwise to indicate abuse or a bug somewhere. If there
is abuse of some kind, crashing Dom0 here would mean a system-wide DoS.
Only crash the emulator domain if it's not the (global) control domain;
crash only
On Mon, Feb 1, 2021 at 12:54 AM Elliott Mitchell wrote:
>
> On Sun, Jan 31, 2021 at 10:06:21PM -0500, Tamas K Lengyel wrote:
> > With rpi-4.19.y kernel and dtbs
> > (cc39f1c9f82f6fe5a437836811d906c709e0661c) Xen boots fine and the
> > previous error is not present. I get the boot log on the serial
On 01.02.2021 16:16, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [PATCH] x86/build: correctly record dependencies
> of asm-offsets.s"):
>> On 01/02/2021 14:56, Jan Beulich wrote:
>>> Going through an intermediate *.new file requires telling the compiler
>>> what the real target is, so that the
Em seg., 1 de fev. de 2021 às 12:09, Jan Beulich escreveu:
>
> On 01.02.2021 15:46, Claudemir Todo Bom wrote:
> > Tested first without the debug patch and with following parameters:
>
> And this test was all three of the non-debugging patches?
Yes, all three patches.
> > xen: dom0_mem=1024M,max:
Hi,
I am building the xen 4.11 branch at
310ab79875cb705cc2c7daddff412b5a4899f8c9 which includes commit
3b5de119f0399cbe745502cb6ebd5e6633cc139c "86/msr: fix handling of
MSR_IA32_PERF_{STATUS/CTL}". I think this should address this error
recorded in xen's dmesg:
(XEN) d11v0 VIRIDIAN CRASH: 3
Jan Beulich writes ("Re: [PATCH] x86/build: correctly record dependencies of
asm-offsets.s [and 1 more messages]"):
> Oh, this used to be different on prior releases once we were
> past the full freeze point. Are to intending to allow bug fixes
> without release ack until the actual release (minus
On 01.02.2021 16:28, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH] x86/build: correctly record dependencies of
> asm-offsets.s [and 1 more messages]"):
>> Oh, this used to be different on prior releases once we were
>> past the full freeze point. Are to intending to allow bug fixes
>> with
Thanks everyone for your hard work so far. We are now in feature
freeze, as of the end of Friday. No new features should be committed
to xen.git#staging.
You may continue to commit straightforward bugfixes, docs changes, and
new tests, without a release-ack. Anything involving reorganisation
or
On 01/02/2021 15:22, Jan Beulich wrote:
> We consider this error path of hvm_alloc_ioreq_mfn() to not be possible
> to be taken, or otherwise to indicate abuse or a bug somewhere. If there
> is abuse of some kind, crashing Dom0 here would mean a system-wide DoS.
> Only crash the emulator domain if
On 01/02/2021 15:02, Jan Beulich wrote:
On 01.02.2021 15:54, Ian Jackson wrote:
Julien Grall writes ("[PATCH for-4.15] xen/mm: Fix build when CONFIG_HVM=n and
CONFIG_COVERAGE=y"):
Xen is heavily relying on the DCE stage to remove unused code so the
linker doesn't throw an error because a fu
The endian.h header is in sys/ on NetBSD and FreeBSD.
Signed-off-by: Roger Pau Monné
---
Only tested on FreeBSD, but from my reading the header is at the same
place on NetBSD.
---
tools/xenstore/include/xenstore_state.h | 4
1 file changed, 4 insertions(+)
diff --git a/tools/xenstore/inclu
On 01.02.2021 16:37, Andrew Cooper wrote:
> On 01/02/2021 15:22, Jan Beulich wrote:
>> We consider this error path of hvm_alloc_ioreq_mfn() to not be possible
>> to be taken, or otherwise to indicate abuse or a bug somewhere. If there
>> is abuse of some kind, crashing Dom0 here would mean a system
Xen is heavily relying on the DCE stage to remove unused code so the
linker doesn't throw an error because a function is not implemented
yet we defined a prototype for it.
On some GCC versions (such as 9.4 provided by Debian sid), the compiler
DCE stage will not manage to figure that out for
xenme
Roger Pau Monne writes ("[PATCH for-4.15] xenstore: fix build on
{Net/Free}BSD"):
> The endian.h header is in sys/ on NetBSD and FreeBSD.
That's a bit irritating. Ah well.
Acked-by: Ian Jackson
Release-Acked-by: Ian Jackson
Ian.
On Mon, Feb 1, 2021 at 7:29 AM Jan Beulich wrote:
>
> On 01.02.2021 12:44, Andrew Cooper wrote:
> > On 01/02/2021 09:37, Jan Beulich wrote:
> >> On 30.01.2021 03:59, Andrew Cooper wrote:
> >>> On 30/01/2021 01:59, Tamas K Lengyel wrote:
> When using gdbsx dbg_rw_guest_mem is used to read/writ
On 01.02.2021 16:26, Claudemir Todo Bom wrote:
> Em seg., 1 de fev. de 2021 às 12:09, Jan Beulich escreveu:
>>
>> On 01.02.2021 15:46, Claudemir Todo Bom wrote:
>>> Tested first without the debug patch and with following parameters:
>>
>> And this test was all three of the non-debugging patches?
>
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-qemuu-freebsd12-amd64
testid guest-start
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/
On Mon, Feb 01, 2021 at 05:20:54PM +0100, Jan Beulich wrote:
> Xen is heavily relying on the DCE stage to remove unused code so the
> linker doesn't throw an error because a function is not implemented
> yet we defined a prototype for it.
>
> On some GCC versions (such as 9.4 provided by Debian si
On 01/02/2021 16:20, Jan Beulich wrote:
> Xen is heavily relying on the DCE stage to remove unused code so the
> linker doesn't throw an error because a function is not implemented
> yet we defined a prototype for it.
>
> On some GCC versions (such as 9.4 provided by Debian sid), the compiler
> DCE
On Sun, 31 Jan 2021, Tamas K Lengyel wrote:
> This seems to have been caused by a monitor being attached to the HDMI
> port, with HDMI unplugged dom0 boots OK.
FYI others have reported issues with swiotlb-xen when using graphics:
https://marc.info/?l=xen-devel&m=161201486021603 Disabling swiotlb-x
flight 158892 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158892/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm broken
test-arm64-arm
On Sat, 30 Jan 2021, Julien Grall wrote:
> > > On 27/01/2021 11:47, Jukka Kaartinen wrote:
> > > >
> > > >
> > > > On Tue, Jan 26, 2021 at 10:22 PM Stefano Stabellini
> > > > mailto:sstabell...@kernel.org>> wrote:
> > > >
> > > > On Tue, 26 Jan 2021, Jukka Kaartinen wrote:
> > > > > On
flight 158897 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158897/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 158804
build-arm64-
flight 158881 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158881/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-dom0pvh-xl-intel 14 guest-start fail REGR. vs. 158387
test-amd64-amd64-dom0
1 - 100 of 145 matches
Mail list logo
