flight 159486 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159486/
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
Reviewed-by: Huacai Chen
On Sat, Feb 20, 2021 at 12:56 PM Jiaxun Yang wrote:
>
> 在 2021/2/20 上午1:38, Philippe Mathieu-Daudé 写道:
> > Restrit KVM to the following MIPS machines:
> > - malta
> > - loongson3-virt
> >
> > Signed-off-by: Philippe Mathieu-Daudé
>
> Reviewed-by: Jiaxun Yang
>
> > ---
flight 159475 xen-unstable real [real]
flight 159485 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/159475/
http://logs.test-lab.xenproject.org/osstest/logs/159485/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
On 2/19/21 3:32 PM, Konrad Rzeszutek Wilk wrote:
> On Sun, Feb 07, 2021 at 04:56:01PM +0100, Christoph Hellwig wrote:
>> On Thu, Feb 04, 2021 at 09:40:23AM +0100, Christoph Hellwig wrote:
>>> So one thing that has been on my mind for a while: I'd really like
>>> to kill the separate dma ops in
Hi all,
On Fri, 19 Feb 2021 at 22:19, osstest service owner
wrote:
>
> flight 159463 linux-linus real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/159463/
[...]
> test-arm64-arm64-xl-seattle fail
[...]
> test-arm64-arm64-xl-thunderx
flight 159463 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159463/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332
On Sun, Feb 07, 2021 at 05:09:29PM +0100, Christoph Hellwig wrote:
> Use the existing variable that holds the physical address for
> xen_io_tlb_end to simplify xen_swiotlb_dma_supported a bit, and remove
> the otherwise unused xen_io_tlb_end variable and the xen_virt_to_bus
> helper.
>
flight 159462 qemu-mainline real [real]
flight 159482 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/159462/
http://logs.test-lab.xenproject.org/osstest/logs/159482/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not
On Sun, Feb 07, 2021 at 05:09:28PM +0100, Christoph Hellwig wrote:
> Use the is_swiotlb_buffer to check if a physical address is
> a swiotlb buffer. This works because xen-swiotlb does use the
> same buffer as the main swiotlb code, and xen_io_tlb_{start,end}
> are just the addresses for it that
On Sun, Feb 07, 2021 at 04:56:01PM +0100, Christoph Hellwig wrote:
> On Thu, Feb 04, 2021 at 09:40:23AM +0100, Christoph Hellwig wrote:
> > So one thing that has been on my mind for a while: I'd really like
> > to kill the separate dma ops in Xen swiotlb. If we compare xen-swiotlb
> > to swiotlb
On 19/02/2021 16:10, Kevin Negy wrote:
> Hello,
>
> I'm trying to understand how the shadow page table works in Xen,
> specifically during live migration. My understanding is that after
> shadow paging is enabled (sh_enable_log_dirty() in
> xen/arch/x86/mm/shadow/common.c), a shadow page table is
flight 159481 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159481/
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
On 19/02/2021 17:38, Philippe Mathieu-Daudé wrote:
When started with other accelerator than Xen, the XenPV machine
fails with a criptic message:
$ qemu-system-x86_64 -M xenpv,accel=kvm
xen be core: can't connect to xenstored
qemu-system-x86_64: xen_init_pv: xen backend core setup
flight 159471 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159471/
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
flight 159480 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159480/
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
By default machines can only use the TCG and QTest accelerators.
If a machine can use another accelerator, it has to explicitly
list it in its MachineClass valid_accelerators[].
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/boards.h | 4 ++--
hw/core/machine.c | 8
2 files
Before configuring an accelerator, check it is valid for
the current machine. Doing so we can return a simple error
message instead of criptic one.
Before:
$ qemu-system-arm -M raspi2b -enable-kvm
qemu-system-arm: /build/qemu-ETIdrs/qemu-4.2/exec.c:865:
cpu_address_space_init: Assertion
x86 machines currently support all accelerators.
Signed-off-by: Philippe Mathieu-Daudé
---
RFC: not sure about this, x86 is not my cup of tea
hw/i386/x86.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/hw/i386/x86.c b/hw/i386/x86.c
index 6329f90ef90..2dc10e7d386 100644
---
When started with other accelerator than Xen, the XenPV machine
fails with a criptic message:
$ qemu-system-x86_64 -M xenpv,accel=kvm
xen be core: can't connect to xenstored
qemu-system-x86_64: xen_init_pv: xen backend core setup failed
By restricting it to Xen, we display a clearer error
All s390-ccw-virtio machines support TCG and KVM.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/s390x/s390-virtio-ccw.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
index 2972b607f36..1f168485066 100644
---
Restrit KVM to the following ARM machines:
- virt
- xlnx-versal-virt
Signed-off-by: Philippe Mathieu-Daudé
---
hw/arm/virt.c | 5 +
hw/arm/xlnx-versal-virt.c | 5 +
2 files changed, 10 insertions(+)
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 371147f3ae9..8e9861b61a9
Restrit KVM to the following PPC machines:
- 40p
- bamboo
- g3beige
- mac99
- mpc8544ds
- ppce500
- pseries
- sam460ex
- virtex-ml507
Signed-off-by: Philippe Mathieu-Daudé
---
RFC: I'm surprise by this list, but this is the result of
auditing calls to kvm_enabled() checks.
Restrit KVM to the following MIPS machines:
- malta
- loongson3-virt
Signed-off-by: Philippe Mathieu-Daudé
---
hw/mips/loongson3_virt.c | 5 +
hw/mips/malta.c | 5 +
2 files changed, 10 insertions(+)
diff --git a/hw/mips/loongson3_virt.c b/hw/mips/loongson3_virt.c
index
Do not let 'query-machines' return machines not valid with
the current accelerator.
Suggested-by: Daniel Berrangé
Signed-off-by: Philippe Mathieu-Daudé
---
hw/core/machine-qmp-cmds.c | 4
1 file changed, 4 insertions(+)
diff --git a/hw/core/machine-qmp-cmds.c b/hw/core/machine-qmp-cmds.c
Introduce the valid_accelerators[] field to express the list
of valid accelators a machine can use, and add the
machine_class_valid_for_current_accelerator() and
machine_class_valid_for_accelerator() methods.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/boards.h | 24
MachineClass::kvm_type() can return -1 on failure.
Document it, and add a check in kvm_init().
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/boards.h | 3 ++-
accel/kvm/kvm-all.c | 6 ++
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/include/hw/boards.h
Hi,
This series aims to improve user experience by providing
a better error message when the user tries to enable KVM
on machines not supporting it.
Since v1:
- added missing x86 arch (Peter)
- consider all accelerators (Daniel and Peter)
- do not enable KVM on sbsa-ref (Leif)
- updated
On Thu, Oct 15, 2020 at 1:13 PM Jason Andryuk wrote:
>
> On Thu, Oct 15, 2020 at 12:39 PM Tamas K Lengyel
> wrote:
> >
> > > > Can you paste the memory map as printed by Xen when booting, and what
> > > > command line are you using to boot Xen.
> > >
> > > So this is OpenXT, and it's booting EFI
On Wed, Oct 21, 2020 at 9:59 AM Jan Beulich wrote:
>
> On 21.10.2020 15:36, Jason Andryuk wrote:
> > On Wed, Oct 21, 2020 at 8:53 AM Jan Beulich wrote:
> >>
> >> On 21.10.2020 14:45, Jason Andryuk wrote:
> >>> On Wed, Oct 21, 2020 at 5:58 AM Roger Pau Monné
> >>> wrote:
> Hm, it's hard to
On Fri, Feb 19, 2021 at 03:13:37PM +0100, Juergen Gross wrote:
> libxl_domain_resume() won't work correctly for the case it was called
> due to a "xl save -c" command, i.e. to continue the suspended domain.
>
> The information to do that is not saved in libxl__dm_resume_state for
> non-HVM
Jan Beulich writes ("[PATCH v2] VMX: use a single, global APIC access page"):
> The address of this page is used by the CPU only to recognize when to
> access the virtual APIC page instead. No accesses would ever go to this
> page. It only needs to be present in the (CPU) page tables so that
>
On 19.02.2021 17:45, Jan Beulich wrote:
> The address of this page is used by the CPU only to recognize when to
> access the virtual APIC page instead. No accesses would ever go to this
> page. It only needs to be present in the (CPU) page tables so that
> address translation will produce its
Jan Beulich writes ("[PATCH] build: remove more absolute paths from dependency
tracking files"):
> d6b12add90da ("DEPS handling: Remove absolute paths from references to
> cwd") took care of massaging the dependencies of the output file, but
> for our passing of -MP to the compiler to take effect
On 19.02.2021 17:47, Ian Jackson wrote:
> J. x86/time: calibration rendezvous adjustments
>
> Information from
> Jan Beulich
>
> Not entirely a regression. But 3 out of the 4 patches have reviews
> and R-A and should be going in shortly.
>
> Patch 4/ is RFC and it's not clear to e whether
Today is the last day for committing anything to 4.15 without an
explicit release-ack.
Today, still:
You may continue to commit straightforward bugfixes, docs changes, and
new tests, without a release-ack. Anything involving reorganisation
or refactoring should get a release ack.
The address of this page is used by the CPU only to recognize when to
access the virtual APIC page instead. No accesses would ever go to this
page. It only needs to be present in the (CPU) page tables so that
address translation will produce its address as result for respective
accesses.
By
Jan Beulich writes ("[PATCH] build: remove more absolute paths from dependency
tracking files"):
> d6b12add90da ("DEPS handling: Remove absolute paths from references to
> cwd") took care of massaging the dependencies of the output file, but
> for our passing of -MP to the compiler to take effect
On 19.02.2021 17:10, Kevin Negy wrote:
> I'm trying to understand how the shadow page table works in Xen,
> specifically during live migration. My understanding is that after shadow
> paging is enabled (sh_enable_log_dirty() in
> xen/arch/x86/mm/shadow/common.c), a shadow page table is created,
Andrew Cooper writes ("[PATCH v2 for-4.15] tools/libxl: Work around
unintialised variable libxl__domain_get_device_model_uid()"):
> Various version of gcc, when compiling with -Og, complain:
>
> libxl_dm.c: In function 'libxl__domain_get_device_model_uid':
> libxl_dm.c:256:12: error:
Jan Beulich writes ("Re: [PATCH v2 0/8] x86/PV: avoid speculation abuse through
guest accessors"):
> On 19.02.2021 17:13, Ian Jackson wrote:
> > Jan Beulich writes ("Re: [PATCH v2 0/8] x86/PV: avoid speculation abuse
> > through guest accessors"):
> > I think 4-6 and 8 are good candidates for
On 19.02.2021 17:13, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH v2 0/8] x86/PV: avoid speculation abuse
> through guest accessors"):
>> On 19.02.2021 16:50, Ian Jackson wrote:
>>> You say "consistency" but in practical terms, what will happen if the
>>> code is not "conxistent" in this
Jan Beulich writes ("Re: [PATCH v2 0/8] x86/PV: avoid speculation abuse through
guest accessors"):
> On 19.02.2021 16:50, Ian Jackson wrote:
> > You say "consistency" but in practical terms, what will happen if the
> > code is not "conxistent" in this sense ?
>
> Patches 4-6: The code is harder
Hello,
I'm trying to understand how the shadow page table works in Xen,
specifically during live migration. My understanding is that after shadow
paging is enabled (sh_enable_log_dirty() in
xen/arch/x86/mm/shadow/common.c), a shadow page table is created, which is
a complete copy of the current
Jan Beulich writes ("[PATCH v3 0/4] x86/time: calibration rendezvous
adjustments"):
> The middle 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
>
d6b12add90da ("DEPS handling: Remove absolute paths from references to
cwd") took care of massaging the dependencies of the output file, but
for our passing of -MP to the compiler to take effect the same needs to
be done on the "phony" rules that the compiler emits.
Signed-off-by: Jan Beulich
On 19.02.2021 16:50, Ian Jackson wrote:
> Jan Beulich writes ("[PATCH v2 0/8] x86/PV: avoid speculation abuse through
> guest accessors"):
>> Re-sending primarily for the purpose of getting a release ack, an
>> explicit release nak, or an indication of there not being a need,
>> all for at least
Jan Beulich writes ("[PATCH v2 0/8] x86/PV: avoid speculation abuse through
guest accessors"):
> Re-sending primarily for the purpose of getting a release ack, an
> explicit release nak, or an indication of there not being a need,
> all for at least the first three patches here (which are
Add syfs nodes for each xenbus device showing event statistics (number
of events and spurious events, number of associated event channels)
and for setting a spurious event threshold in case a frontend is
sending too many events without being rogue on purpose.
Signed-off-by: Juergen Gross
In order to support the possibility of per-device event channel
settings (e.g. lateeoi spurious event thresholds) add a xenbus device
pointer to struct irq_info() and modify the related event channel
binding interfaces to take the pointer to the xenbus device as a
parameter instead of the domain
For avoiding read- and write-tearing by the compiler use READ_ONCE()
and WRITE_ONCE() for accessing the ring indices in evtchn.c.
Signed-off-by: Juergen Gross
---
V2:
- modify all accesses (Julien Grall)
V3:
- fix incrementing producer index (Ross Lagerwall)
---
drivers/xen/evtchn.c | 25
The ring buffer for user events is local to the given kernel instance,
so smp barriers are fine for ensuring consistency.
Reported-by: Andrew Cooper
Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
---
drivers/xen/evtchn.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff
In case of a common event for rx and tx queue the event should be
regarded to be spurious if no rx and no tx requests are pending.
Unfortunately the condition for testing that is wrong causing to
decide a event being spurious if no rx OR no tx requests are
pending.
Fix that plus using local
The first four patches are fixes for XSA-332. The avoid WARN splats
and a performance issue with interdomain events.
Patches 5 and 6 are some additions to event handling in order to add
some per pv-device statistics to sysfs and the ability to have a per
backend device spurious event delay
When changing the cpu affinity of an event it can happen today that
(with some unlucky timing) the same event will be handled on the old
and the new cpu at the same time.
Avoid that by adding an "event active" flag to the per-event data and
call the handler only if this flag isn't set.
Cc:
An event channel should be kept masked when an eoi is pending for it.
When being migrated to another cpu it might be unmasked, though.
In order to avoid this keep three different flags for each event channel
to be able to distinguish "normal" masking/unmasking from eoi related
masking/unmasking
When creating a new event channel with 2-level events the affinity
needs to be reset initially in order to avoid using an old affinity
from earlier usage of the event channel port. So when tearing an event
channel down reset all affinity bits.
The same applies to the affinity when onlining a
flight 159459 xen-4.11-testing real [real]
flight 159479 xen-4.11-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/159459/
http://logs.test-lab.xenproject.org/osstest/logs/159479/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
Various version of gcc, when compiling with -Og, complain:
libxl_dm.c: In function 'libxl__domain_get_device_model_uid':
libxl_dm.c:256:12: error: 'kill_by_uid' may be used uninitialized in this
function [-Werror=maybe-uninitialized]
256 | if (kill_by_uid)
|^
On Fri, Feb 19, 2021 at 03:15:52PM +0100, Jan Beulich wrote:
> On 19.02.2021 15:13, Juergen Gross wrote:
> > libxl_domain_resume() won't work correctly for the case it was called
> > due to a "xl save -c" command, i.e. to continue the suspended domain.
> >
> > The information to do that is not
On 2/18/21 6:48 AM, Roger Pau Monné wrote:
>
>> +/* Get the domain's default policy. */
>> +nr_leaves = 0;
>> +rc = xc_get_system_cpu_policy(xch, di.hvm ?
>> XEN_SYSCTL_cpu_policy_hvm_default
>> + :
>> XEN_SYSCTL_cpu_policy_pv_default,
On 2/18/21 5:51 AM, Roger Pau Monné wrote:
> On Wed, Jan 20, 2021 at 05:49:10PM -0500, Boris Ostrovsky wrote:
>> When toolstack updates MSR policy, this MSR offset (which is the last
>> index in the hypervisor MSR range) is used to indicate hypervisor
>> behavior when guest accesses an MSR which
On 2/18/21 10:57 AM, Jan Beulich wrote:
> On 18.02.2021 16:52, Roger Pau Monné wrote:
>> On Thu, Feb 18, 2021 at 12:54:13PM +0100, Jan Beulich wrote:
>>> On 18.02.2021 11:42, Roger Pau Monné wrote:
Not that you need to implement the full thing now, but maybe we could
have something
Hi,
On 17/02/2021 23:23, Stefano Stabellini wrote:
+IanJ
On Wed, 17 Feb 2021, Bertrand Marquis wrote:
Hi Rahul,
On 17 Feb 2021, at 10:05, Rahul Singh wrote:
SMMUv3 driver does not handle multiple StreamId if the master device
supports more than one StreamID.
This bug was introduced when
On 10.02.2021 10:22, Roger Pau Monne wrote:
> The for loop in unmap_domain_pirq is unnecessary complicated, with
> several places where the index is incremented, and also different
> exit conditions spread between the loop body.
>
> Simplify it by looping over each possible PIRQ using the for
On 19.02.2021 15:13, Juergen Gross wrote:
> libxl_domain_resume() won't work correctly for the case it was called
> due to a "xl save -c" command, i.e. to continue the suspended domain.
>
> The information to do that is not saved in libxl__dm_resume_state for
> non-HVM domains.
>
> Fixes:
libxl_domain_resume() won't work correctly for the case it was called
due to a "xl save -c" command, i.e. to continue the suspended domain.
The information to do that is not saved in libxl__dm_resume_state for
non-HVM domains.
Fixes: 6298f0eb8f443 ("libxl: Re-introduce libxl__domain_resume")
On 18.02.2021 16:01, Norbert Manthey wrote:
> To prevent leaking HVM params via L1TF and similar issues on a
> hyperthread pair, let's load values of domains only after performing all
> relevant checks, and blocking speculative execution.
>
> For both get and set, the value of the index is
On 19.02.21 14:37, Jan Beulich wrote:
On 19.02.2021 14:18, Jürgen Groß wrote:
On 19.02.21 14:10, Jan Beulich wrote:
On 19.02.2021 13:48, Jürgen Groß wrote:
On 17.02.21 14:48, Marek Marczykowski-Górecki wrote:
On Wed, Feb 17, 2021 at 07:51:42AM +0100, Jürgen Groß wrote:
On 17.02.21 06:12,
On 19.02.2021 14:18, Jürgen Groß wrote:
> On 19.02.21 14:10, Jan Beulich wrote:
>> On 19.02.2021 13:48, Jürgen Groß wrote:
>>> On 17.02.21 14:48, Marek Marczykowski-Górecki wrote:
On Wed, Feb 17, 2021 at 07:51:42AM +0100, Jürgen Groß wrote:
> On 17.02.21 06:12, Marek Marczykowski-Górecki
On 19.02.21 14:10, Jan Beulich wrote:
On 19.02.2021 13:48, Jürgen Groß wrote:
On 17.02.21 14:48, Marek Marczykowski-Górecki wrote:
On Wed, Feb 17, 2021 at 07:51:42AM +0100, Jürgen Groß wrote:
On 17.02.21 06:12, Marek Marczykowski-Górecki wrote:
Hi,
I'm observing Linux PV/PVH guest crash
On 19.02.2021 13:48, Jürgen Groß wrote:
> On 17.02.21 14:48, Marek Marczykowski-Górecki wrote:
>> On Wed, Feb 17, 2021 at 07:51:42AM +0100, Jürgen Groß wrote:
>>> On 17.02.21 06:12, Marek Marczykowski-Górecki wrote:
Hi,
I'm observing Linux PV/PVH guest crash when I resume it from
On 17.02.21 14:48, Marek Marczykowski-Górecki wrote:
On Wed, Feb 17, 2021 at 07:51:42AM +0100, Jürgen Groß wrote:
On 17.02.21 06:12, Marek Marczykowski-Górecki wrote:
Hi,
I'm observing Linux PV/PVH guest crash when I resume it from sleep. I do
this with:
virsh -c xen dompmsuspend mem
On 19.02.2021 09:59, Dan Carpenter wrote:
> Hello Jan Beulich,
>
> The patch 5a264285ed1c: "xen-blkback: don't "handle" error by BUG()"
> from Feb 15, 2021, leads to the following static checker warning:
>
> drivers/block/xen-blkback/blkback.c:836 xen_blkbk_map()
> warn: should this
flight 159457 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159457/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 158387
test-armhf-armhf-libvirt 16
Hi Stefano,
On 19/02/2021 01:42, Stefano Stabellini wrote:
On Thu, 18 Feb 2021, Julien Grall wrote:
On 17/02/2021 23:54, Stefano Stabellini wrote:
On Wed, 17 Feb 2021, Julien Grall wrote:
On 17/02/2021 02:00, Stefano Stabellini wrote:
But actually it was always wrong for Linux to enable
Hi Jan,
On 19/02/2021 08:49, Jan Beulich wrote:
On 18.02.2021 14:25, Julien Grall wrote:
Hi,
On 18/02/2021 13:05, Jan Beulich wrote:
On 17.02.2021 17:07, Julien Grall wrote:
On 17/02/2021 15:01, Jan Beulich wrote:
On 17.02.2021 15:24, Julien Grall wrote:
From: Julien Grall
The new x86
Hello Jan Beulich,
The patch 5a264285ed1c: "xen-blkback: don't "handle" error by BUG()"
from Feb 15, 2021, leads to the following static checker warning:
drivers/block/xen-blkback/blkback.c:836 xen_blkbk_map()
warn: should this be a bitwise negate mask?
On 19/02/2021 08:46, Jan Beulich wrote:
On 18.02.2021 18:41, Julien Grall wrote:
On 18/02/2021 17:04, Jan Beulich wrote:
On 18.02.2021 14:19, Julien Grall wrote:
On 18/02/2021 13:10, Jan Beulich wrote:
On 17.02.2021 17:29, Julien Grall wrote:
On 17/02/2021 15:13, Jan Beulich wrote:
On 18.02.2021 15:00, Paul Durrant wrote:
> On 18/02/2021 13:05, Jan Beulich wrote:
>> On 17.02.2021 17:07, Julien Grall wrote:
>>> On 17/02/2021 15:01, Jan Beulich wrote:
On 17.02.2021 15:24, Julien Grall wrote:
> From: Julien Grall
>
> The new x86 IOMMU page-tables allocator
On 18.02.2021 14:25, Julien Grall wrote:
> Hi,
>
> On 18/02/2021 13:05, Jan Beulich wrote:
>> On 17.02.2021 17:07, Julien Grall wrote:
>>> On 17/02/2021 15:01, Jan Beulich wrote:
On 17.02.2021 15:24, Julien Grall wrote:
> From: Julien Grall
>
> The new x86 IOMMU page-tables
On 18.02.2021 18:41, Julien Grall wrote:
>
>
> On 18/02/2021 17:04, Jan Beulich wrote:
>> On 18.02.2021 14:19, Julien Grall wrote:
>>>
>>>
>>> On 18/02/2021 13:10, Jan Beulich wrote:
On 17.02.2021 17:29, Julien Grall wrote:
> On 17/02/2021 15:13, Jan Beulich wrote:
>> On 17.02.2021
On 19.02.2021 02:42, Stefano Stabellini wrote:
> OK it took me a lot longer than expected (I have never had the dubious
> pleasure of working with autoconf before) but the following seems to
> work, tested on both Alpine Linux and Debian Unstable. Of course I had
> to run autoreconf first.
>
>
>
All of the sudden ld creates base relocations itself, for PE
executables - as a result we now have two of them for every entity to
be relocated. While we will likely want to use this down the road, it
doesn't work quite right yet in corner cases, so rather than suppressing
our own way of creating
83 matches
Mail list logo
