On 11.01.2021 12:06, Julien Grall wrote:
> On 11/01/2021 10:14, Jan Beulich wrote:
>> On 08.01.2021 21:32, Julien Grall wrote:
>>> On 05/01/2021 13:09, Jan Beulich wrote:
Neither evtchn_status() nor domain_dump_evtchn_info() nor
flask_get_peer_sid() need to hold the per-domain lock -
On 26.01.21 22:36, Boris Ostrovsky wrote:
On 1/26/21 12:01 PM, David Woodhouse wrote:
From: David Woodhouse
In commit 3499ba8198ca ("xen: Fix event channel callback via INTX/GSI")
I reworked the triggering of xenbus_probe().
I tried to simplify things by taking out the workqueue based
flight 158631 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158631/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332
flight 158628 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158628/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds18 guest-start/debian.repeat fail REGR. vs. 158607
Tests which did not
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 the
bridge name gets passed to the QEMU script.
NetBSD doesn't have the ioctl to
Switch NetBSD to QEMU_XEN.
All 3 versions of libxl__default_device_model() now return
LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN, so remove it and just set
b_info->device_model_version to LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN in
libxl__domain_build_info_setdefault().
Signed-off-by: Manuel Bouyer
Define PAGE_* if not already defined
Catch up with osdep interface change.
Signed-off-by: Manuel Bouyer
Reviewed-by: Roger Pau Monné
---
tools/libs/call/netbsd.c | 19 +++
tools/libs/call/private.h | 4 +++-
2 files changed, 14 insertions(+), 9 deletions(-)
diff --git
From: Brian Woods
Restructure some of the code and add supporting functions for adding
generic device tree (DT) binding support. This will allow for using
current Linux device trees with just modifying the chosen field to
enable Xen.
Signed-off-by: Brian Woods
Signed-off-by: Stefano
From: Brian Woods
Now that all arm iommu drivers support generic bindings we can remove
the workaround from iommu_add_dt_device().
Note that if both legacy bindings and generic bindings are present in
device tree, the legacy bindings are the ones that are used.
Signed-off-by: Brian Woods
From: Brian Woods
Modify the smmu driver so that it uses the iommu_fwspec helper
functions. This means both ARM IOMMU drivers will both use the
iommu_fwspec helper functions, making enabling generic device tree
bindings in the SMMU driver much cleaner.
Signed-off-by: Brian Woods
Hi all,
This series introduces support for the generic SMMU bindings to
xen/drivers/passthrough/arm/smmu.c.
The last version of the series was
https://marc.info/?l=xen-devel=159539053406643
I realize that it is late for 4.15 -- I think it is OK if this series
goes in afterwards.
Cheers,
flight 158624 linux-5.4 real [real]
flight 158672 linux-5.4 real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/158624/
http://logs.test-lab.xenproject.org/osstest/logs/158672/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
When a domain is destroyed, xparams may not be available any more when
the block script is called to unconfigure the vnd.
Check xparam only at configure time, and just unconfigure any vnd present
in the xenstore.
Signed-off-by: Manuel Bouyer
Reviewed-by: Roger Pau Monné
---
NetBSD doesn't have setresuid(). introcuce libxl__setresuid(),
which on NetBSD assert() that it's never called (it should not be called when
dm restriction is off, and NetBSD doesn't support dm restriction at
this time).
On linux and FreeBSD it just calls setresuid().
Signed-off-by: Manuel Bouyer
Don't assume tv_sec is a unsigned long, it is 64 bits on NetBSD 32 bits.
Use %jd and cast to (intmax_t) instead
Signed-off-by: Manuel Bouyer
Reviewed-by: Roger Pau Monné
---
tools/libs/light/libxl_create.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git
NetBSD uses the same uuid library as FreeBSD. As this is in a
__FreeBSD__ || __NetBSD__ block, just drop the #ifdef __FreeBSD__
and dead code.
Signed-off-by: Manuel Bouyer
Reviewed-by: Roger Pau Monné
---
tools/libs/light/libxl_uuid.c | 21 -
1 file changed, 21 deletions(-)
Implement gnttab interface on NetBSD.
The kernel interface is different from FreeBSD so we can't use the FreeBSD
version
Signed-off-by: Manuel Bouyer
---
tools/libs/gnttab/Makefile | 2 +-
tools/libs/gnttab/netbsd.c | 267 +
2 files changed, 268
On NetBSD, PTHREAD_STACK_MIN is not available.
If PTHREAD_STACK_MIN is not defined, define it to 0 so that we fallback to
DEFAULT_THREAD_STACKSIZE
Signed-off-by: Manuel Bouyer
---
tools/libs/store/xs.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/tools/libs/store/xs.c
On NetBSD use the system-provided headers for ioctl and related definitions,
they are up to date and have more chances to match the kernel's idea of
the ioctls and structures.
Remove now-unused NetBSD/evtchn.h and NetBSD/privcmd.h.
Don't fail install if xen/sys/*.h are not present.
Signed-off-by:
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 Bouyer
---
tools/xenpmd/xenpmd.c | 8
1 file changed, 4 insertions(+), 4
Implement foreignmemory interface on NetBSD. The compat interface is now used
only on __sun__
Signed-off-by: Manuel Bouyer
---
tools/libs/foreignmemory/Makefile | 2 +-
tools/libs/foreignmemory/netbsd.c | 66 +-
tools/libs/foreignmemory/private.h | 6 +--
3 files
On NetBSD, some block device configuration requires serialisation.
Introcuce locking functions (derived from the Linux version), and use them
in the block script where appropriate.
Signed-off-by: Manuel Bouyer
---
tools/hotplug/NetBSD/Makefile | 1 +
tools/hotplug/NetBSD/block | 5 +-
Use unsigned char variable, or cast to (unsigned char), for
tolower()/islower() and friends. Fix compiler error
array subscript has type 'char' [-Werror=char-subscripts]
Signed-off-by: Manuel Bouyer
Reviewed-by: Ian Jackson
Release-Acked-by: Ian Jackson
---
tools/libs/light/libxl_qmp.c | 2 +-
On Mon, Jan 18, 2021 at 09:36:42AM +0100, Roger Pau Monné wrote:
> [...]
>
> Note also that there are networking modes that don't use a bridge, so
> you could likely end up with nics[i].bridge == NULL?
I couldn't cause this to happen. If no bridge is specified in the
domU's config file,
On Tue, 2021-01-26 at 18:03 +0100, Anders Törnqvist wrote:
> On 1/25/21 5:11 PM, Dario Faggioli wrote:
> > On Fri, 2021-01-22 at 14:26 +, Julien Grall wrote:
> > > Hi Anders,
> > >
> > > On 22/01/2021 08:06, Anders Törnqvist wrote:
> > > > On 1/22/21 12:35 AM, Dario Faggioli wrote:
> > > > >
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2021-3308 / XSA-360
version 2
IRQ vector leak on x86
UPDATES IN VERSION 2
CVE assigned.
ISSUE DESCRIPTION
=
An x86
On 1/26/21 12:01 PM, David Woodhouse wrote:
> From: David Woodhouse
>
> In commit 3499ba8198ca ("xen: Fix event channel callback via INTX/GSI")
> I reworked the triggering of xenbus_probe().
>
> I tried to simplify things by taking out the workqueue based startup
> triggered from
From: Bjorn Helgaas
Fix misspelling of "physical".
Signed-off-by: Bjorn Helgaas
---
drivers/block/xen-blkfront.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 5265975b3fba..876db9fcf388 100644
---
On Tue, 26 Jan 2021, Jukka Kaartinen wrote:
> On Tue, Jan 26, 2021 at 2:54 AM Stefano Stabellini
> wrote:
> On Sat, 23 Jan 2021, Jukka Kaartinen wrote:
> > Thanks for the response!
> >
> > On Sat, Jan 23, 2021 at 2:27 AM Stefano Stabellini
> wrote:
> > +
flight 158626 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158626/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 2d6fc9d36fd5ff15972bedab919f37bb4ee951d0
baseline version:
ovmf
flight 158653 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158653/
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
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 famous EXPERT we keep talking about on xen-devel
2) It is not obvious when we need to
From: Stefano Stabellini
Add an "(EXPERT)" tag to the one-line description of Kconfig options
that depend on EXPERT. (Not where just the prompt depends on EXPERT.)
Today we only have one such option: XEN_SHSTK.
Signed-off-by: Stefano Stabellini
CC: andrew.coop...@citrix.com
CC:
Hi all,
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 famous EXPERT we keep talking about on xen-devel
2) It is not obvious when we need to enable EXPERT to
flight 158622 qemu-mainline real [real]
flight 158651 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/158622/
http://logs.test-lab.xenproject.org/osstest/logs/158651/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not
On Tue, 26 Jan 2021, Jan Beulich wrote:
> On 25.01.2021 22:27, Stefano Stabellini wrote:
> > --- a/xen/arch/x86/Kconfig
> > +++ b/xen/arch/x86/Kconfig
> > @@ -103,7 +103,7 @@ config HVM
> > If unsure, say Y.
> >
> > config XEN_SHSTK
> > - bool "Supervisor Shadow Stacks"
> > + bool
On Tue, 26 Jan 2021, Jan Beulich wrote:
> On 26.01.2021 12:17, Bertrand Marquis wrote:
> >
> >
> >> On 26 Jan 2021, at 11:11, Jan Beulich wrote:
> >>
> >> On 26.01.2021 12:06, Bertrand Marquis wrote:
> On 26 Jan 2021, at 09:22, Jan Beulich wrote:
> On 25.01.2021 22:27, Stefano
On Tue, 26 Jan 2021, Julien Grall wrote:
> Hi Stefano,
>
> On 25/01/2021 21:27, Stefano Stabellini wrote:
> > config ARM_SSBD
> > - bool "Speculative Store Bypass Disable" if EXPERT
> > + bool "Speculative Store Bypass Disable (UNSUPPORTED)" if UNSUPPORTED
> > depends on HAS_ALTERNATIVE
Manuel Bouyer writes ("Re: [PATCH] Fix error: array subscript has type 'char'"):
> On Thu, Jan 14, 2021 at 03:16:15PM +0100, Manuel Bouyer wrote:
> > On Thu, Jan 14, 2021 at 02:25:05PM +0100, Jan Beulich wrote:
> > > Which means you're shifting the undefined-ness from the implementation
The
On Tue, Jan 26, 2021 at 12:08:15PM +0100, Jan Beulich wrote:
> On 25.01.2021 18:46, Elliott Mitchell wrote:
> > On Mon, Jan 25, 2021 at 10:56:25AM +0100, Jan Beulich wrote:
> >> On 24.01.2021 05:47, Elliott Mitchell wrote:
> >>>
> >>> ---
> >>> Changes in v2:
> >>> - Include the obvious removal of
On Thu, Jan 14, 2021 at 03:16:15PM +0100, Manuel Bouyer wrote:
> On Thu, Jan 14, 2021 at 02:25:05PM +0100, Jan Beulich wrote:
> > On 14.01.2021 13:29, Manuel Bouyer wrote:
> > > On Thu, Jan 14, 2021 at 11:53:20AM +0100, Jan Beulich wrote:
> > >> On 12.01.2021 19:12, Manuel Bouyer wrote:
> > >>>
On 07/01/2021 13:53, Jan Beulich wrote:
>> + !((hpet_cfg = hpet_read32(HPET_CFG)) & HPET_CFG_LEGACY) )
>> +{
>> +unsigned int c0_cfg, ticks, count;
>> +
>> +/* Stop the main counter. */
>> +hpet_write32(hpet_cfg & ~HPET_CFG_ENABLE, HPET_CFG);
>> +
>> +/*
On 20/01/2021 11:03, Greg KH wrote:
> On Mon, Jan 18, 2021 at 03:04:26PM +0100, Roger Pau Monne wrote:
>> commit ef3a575baf53571dc405ee4028e26f50856898e7 upstream
>>
>> Allow issuing an IOCTL_PRIVCMD_MMAP_RESOURCE ioctl with num = 0 and
>> addr = 0 in order to fetch the size of a specific
Ian,
On 26.01.2021 14:45, Roger Pau Monne wrote:
> The following series aims to fix some shortcomings of guest interrupt
> handling when using passthrough devices. The first 5 patches are
> bugfixes or cleanups, which I think should solve the issue(s) that
> caused the dpci EOI timer to be
On Mon, Jan 18, 2021 at 06:54:11PM +0100, Roger Pau Monné wrote:
> On Tue, Jan 12, 2021 at 07:12:32PM +0100, Manuel Bouyer wrote:
> > From: Manuel Bouyer
> >
> > Implement gnttab interface on NetBSD.
> > The kernel interface is different from FreeBSD so we can't use the FreeBSD
> > version
>
>
On 1/25/21 5:11 PM, Dario Faggioli wrote:
On Fri, 2021-01-22 at 14:26 +, Julien Grall wrote:
Hi Anders,
On 22/01/2021 08:06, Anders Törnqvist wrote:
On 1/22/21 12:35 AM, Dario Faggioli wrote:
On Thu, 2021-01-21 at 19:40 +, Julien Grall wrote:
- booting with "sched=null vwfi=native"
From: David Woodhouse
In commit 3499ba8198ca ("xen: Fix event channel callback via INTX/GSI")
I reworked the triggering of xenbus_probe().
I tried to simplify things by taking out the workqueue based startup
triggered from wake_waiting(); the somewhat poorly named xenbus IRQ
handler.
I missed
On 26.01.2021 14:45, Roger Pau Monne wrote:
> When pins are cleared from either ISR or IRR as part of the
> initialization sequence forward the clearing of those pins to the dpci
> EOI handler, as it is equivalent to an EOI. Not doing so can bring the
> interrupt controller state out of sync with
On 26/01/2021 16:31, Jan Beulich wrote:
> When discussing the shrunk down version of the commit in question it
> was said (in reply to my conditional choosing of the width):
>
> "However, the 32bit case isn't actually interesting here. A
> guest can't execute a SYSCALL instruction on/across the
On 26.01.2021 14:45, Roger Pau Monne wrote:
> Wait until the end of the init sequence to trigger the unmask event.
> Note that it will be unconditionally triggered, but that's harmless if
> not unmask actually happened.
>
> While there change the variable type to bool.
>
> Requested-by: Jan
On 26.01.2021 14:45, Roger Pau Monne wrote:
> When the PIC is on the init sequence prevent interrupt delivery. The
> state of the registers is in the process of being set during the init
> phase, so it makes sense to prevent any int line changes during that
> process.
>
> Requested-by: Jan
On Fri, Jan 15, 2021 at 05:06:59PM +0100, Roger Pau Monné wrote:
> On Tue, Jan 12, 2021 at 07:12:25PM +0100, Manuel Bouyer wrote:
> > From: Manuel Bouyer
> >
> > Some Xen version didn't set the vifname in xenstore; just build one if
> > not present.
>
> I think the current version (what's going
On Fri, Jan 15, 2021 at 04:27:12PM +0100, Roger Pau Monné wrote:
> On Tue, Jan 12, 2021 at 07:12:24PM +0100, Manuel Bouyer wrote:
> > From: Manuel Bouyer
> >
> > When a domain is destroyed, xparams may not be available any more when
> > the block script is called to unconfigure the vnd.
> >
On 26.01.2021 17:02, Boris Ostrovsky wrote:
> On 21-01-26 10:05:47, Jan Beulich wrote:
>> On 25.01.2021 19:42, Boris Ostrovsky wrote:
>>> On 21-01-25 11:22:08, Jan Beulich wrote:
On 22.01.2021 20:52, Boris Ostrovsky wrote:
> "Sibling" in terms of name (yes, it would be) or something else?
When discussing the shrunk down version of the commit in question it
was said (in reply to my conditional choosing of the width):
"However, the 32bit case isn't actually interesting here. A
guest can't execute a SYSCALL instruction on/across the 4G->0 boundary
because the M2P is mapped NX up
On Tue, Jan 26, 2021 at 03:52:54PM +0100, Jan Beulich wrote:
> On 26.01.2021 12:06, Roger Pau Monne wrote:
> > When force unbinding a MSI the used IRQ would get added to the domain
> > irq-pirq tree as -irq -pirq,
>
> I think it's -pirq at index irq, i.e. I don't think IRQ gets
> negated as far
On 26.01.2021 17:08, Roger Pau Monné wrote:
> On Tue, Jan 26, 2021 at 03:38:27PM +0100, Jan Beulich wrote:
>> On 26.01.2021 12:06, Roger Pau Monne wrote:
>>> There are two duplicated calls to cleanup_domain_irq_pirq in
>>> unmap_domain_pirq.
>>>
>>> The first one in the for loop will be called
flight 158639 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158639/
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 Tue, Jan 26, 2021 at 03:38:27PM +0100, Jan Beulich wrote:
> On 26.01.2021 12:06, Roger Pau Monne wrote:
> > There are two duplicated calls to cleanup_domain_irq_pirq in
> > unmap_domain_pirq.
> >
> > The first one in the for loop will be called with exactly the same
> > arguments as the call
On 21-01-26 10:05:47, Jan Beulich wrote:
> On 25.01.2021 19:42, Boris Ostrovsky wrote:
> > On 21-01-25 11:22:08, Jan Beulich wrote:
> >> On 22.01.2021 20:52, Boris Ostrovsky wrote:
> >>> On 1/22/21 7:51 AM, Jan Beulich wrote:
> On 20.01.2021 23:49, Boris Ostrovsky wrote:
> > +
> > +
On 26/01/2021 13:32, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [PATCH v7 08/10] tools/misc: Add xen-vmtrace
> tool"):
>> On 26/01/2021 11:59, Ian Jackson wrote:
>>> [Andrew:]
This is example code, not a production utility.
>>> Perhaps the utility could print some kind of health warning
On Tue, Jan 26, 2021 at 04:17:59PM +0100, Jan Beulich wrote:
> On 26.01.2021 12:06, Roger Pau Monne wrote:
> > Plain MSI doesn't allow caching the MSI address and data fields while
> > the capability is enabled and not masked, hence we need to allow any
> > changes to those fields to update the
On Fri, Jan 22, 2021 at 04:14:30PM +0100, Jan Beulich wrote:
> While the lack of proper dependency tracking of #include-d files is
> wider than just the libs/ subtree, dealing with the problem universally
> there or in tools/Rules.mk is too much of a risk at this point in the
> release cycle. Add
On 26.01.2021 14:45, Roger Pau Monne wrote:
> When an IO-APIC pin is switched from level to edge trigger mode the
> IRR bit is cleared, so it can be used as a way to EOI an interrupt at
> the IO-APIC level.
>
> Such EOI however does not get forwarded to the dpci code like it's
> done for the
On 26.01.2021 14:45, Roger Pau Monne wrote:
> Top word writes just update the destination of the interrupt, but
> since there's no change on the masking or the triggering mode no
> guest interrupt injection can result of such write. Add an assert to
> that effect.
>
> Requested-by: Jan Beulich
>
On 26.01.2021 14:17, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH v4 1/2] xen: EXPERT clean-up and introduce
> UNSUPPORTED"):
>> On 26.01.2021 12:17, Bertrand Marquis wrote:
>>> Maybe something we could explain more clearly in the UNSUPPORTED/EXPERT
>>> config parameters instead ?
>>> We
On Tue, Jan 26, 2021 at 01:20:14PM +, Bertrand Marquis wrote:
>
>
> > On 26 Jan 2021, at 13:19, Jan Beulich wrote:
> >
> > On 26.01.2021 14:17, Ian Jackson wrote:
> >> Jan Beulich writes ("Re: [PATCH v4 1/2] xen: EXPERT clean-up and introduce
> >> UNSUPPORTED"):
> >>> On 26.01.2021 12:17,
On 26.01.2021 12:06, Roger Pau Monne wrote:
> Plain MSI doesn't allow caching the MSI address and data fields while
> the capability is enabled and not masked, hence we need to allow any
> changes to those fields to update the binding of the interrupt. For
> reference, the same doesn't apply to
On Tue, Jan 19, 2021 at 05:23:25PM +, Andrew Cooper wrote:
> On 19/01/2021 15:48, Roger Pau Monné wrote:
> > On Fri, Jan 15, 2021 at 11:10:46PM +, Andrew Cooper wrote:
> >> From: Norbert Kamiński
> >>
> >> For now, this is simply enough logic to let Xen come up after the
> >> bootloader
Le 18/01/2021 à 11:03, Roger Pau Monné a écrit :
On Fri, Jan 15, 2021 at 03:03:26PM +, Samuel Verschelde wrote:
Hi list,
Another "popular" thread on XCP-ng forum [1], started in october 2020,
allowed us to detect that patch 12 from the XSA-332 advisory [2] had a very
significant impact on
On Tue, Jan 26, 2021 at 12:58:29PM +0100, David Hildenbrand wrote:
> Let's make "MEMHP_MERGE_RESOURCE" consistent with "MHP_NONE", "mhp_t" and
> "mhp_flags". As discussed recently [1], "mhp" is our internal
> acronym for memory hotplug now.
>
> [1]
>
On 26.01.2021 12:06, Roger Pau Monne wrote:
> When force unbinding a MSI the used IRQ would get added to the domain
> irq-pirq tree as -irq -pirq,
I think it's -pirq at index irq, i.e. I don't think IRQ gets
negated as far as the radix tree goes. info->arch.irq gets a
negative value stored, yes.
Le 18/01/2021 à 11:03, Roger Pau Monné a écrit :
On Fri, Jan 15, 2021 at 03:03:26PM +, Samuel Verschelde wrote: >> Hi list, >> >>
Another "popular" thread on XCP-ng forum [1],
started in october >> 2020, allowed us to detect that patch 12 from the
XSA-332 advisory >> [2] had a very
On Tue, Jan 26, 2021 at 12:58:29PM +0100, David Hildenbrand wrote:
> Let's make "MEMHP_MERGE_RESOURCE" consistent with "MHP_NONE", "mhp_t" and
> "mhp_flags". As discussed recently [1], "mhp" is our internal
> acronym for memory hotplug now.
>
> [1]
>
On Tue, Jan 26, 2021 at 12:58:29PM +0100, David Hildenbrand wrote:
> Let's make "MEMHP_MERGE_RESOURCE" consistent with "MHP_NONE", "mhp_t" and
> "mhp_flags". As discussed recently [1], "mhp" is our internal
> acronym for memory hotplug now.
>
> [1]
>
On 26.01.2021 12:06, Roger Pau Monne wrote:
> There are two duplicated calls to cleanup_domain_irq_pirq in
> unmap_domain_pirq.
>
> The first one in the for loop will be called with exactly the same
> arguments as the call placed closer to the loop start.
I'm having trouble figuring out which
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_event_fill_regs(vm_event_request_t *req)
>
> req->data.regs.x86.shadow_gs = ctxt.shadow_gs;
> req->data.regs.x86.dr6 = ctxt.dr6;
> +
> +if (
Hi Julien,
> On 26 Jan 2021, at 13:51, Julien Grall wrote:
>
> Hi Stefano,
>
> On 25/01/2021 21:27, Stefano Stabellini wrote:
>> config ARM_SSBD
>> -bool "Speculative Store Bypass Disable" if EXPERT
>> +bool "Speculative Store Bypass Disable (UNSUPPORTED)" if UNSUPPORTED
>>
On 21.01.2021 22:27, Andrew Cooper wrote:
> From: Tamas K Lengyel
>
> Implement vmtrace_reset_pt function. Properly set IPT
> state for VM forks.
>
> Signed-off-by: Tamas K Lengyel
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
albeit it strikes me as somewhat odd that ...
> ---
On 21.01.2021 22:27, Andrew Cooper wrote:
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -155,6 +155,55 @@ void arch_get_domain_info(const struct domain *d,
> info->arch_config.emulation_flags = d->arch.emulation_flags;
> }
>
> +static int do_vmtrace_op(struct domain *d,
On Tue, Jan 26, 2021 at 12:59 PM Jukka Kaartinen
wrote:
>
>
> On Tue, Jan 26, 2021 at 2:54 AM Stefano Stabellini
> wrote:
>
>> On Sat, 23 Jan 2021, Jukka Kaartinen wrote:
>> > Thanks for the response!
>> >
>> > On Sat, Jan 23, 2021 at 2:27 AM Stefano Stabellini <
>> sstabell...@kernel.org>
Hi Stefano,
On 25/01/2021 21:27, Stefano Stabellini wrote:
config ARM_SSBD
- bool "Speculative Store Bypass Disable" if EXPERT
+ bool "Speculative Store Bypass Disable (UNSUPPORTED)" if UNSUPPORTED
depends on HAS_ALTERNATIVE
default y
help
@@ -87,7 +87,7 @@
On 26.01.2021 14:25, Ian Jackson wrote:
> I hope this explanation makes some kind of sense and sorry for the
> confusion.
It does and no, I don't think there was any confusion caused. Some
thinks merely needed clarifying, on my end at least. Thanks for
doing so.
Jan
Wait until the end of the init sequence to trigger the unmask event.
Note that it will be unconditionally triggered, but that's harmless if
not unmask actually happened.
While there change the variable type to bool.
Requested-by: Jan Beulich
Signed-off-by: Roger Pau Monné
---
Changes since v2:
Current interrupt pass though code will setup a timer for each
interrupt injected to the guest that requires an EOI from the guest.
Such timer would perform two actions if the guest doesn't EOI the
interrupt before a given period of time. The first one is deasserting
the virtual line, the second
When pins are cleared from either ISR or IRR as part of the
initialization sequence forward the clearing of those pins to the dpci
EOI handler, as it is equivalent to an EOI. Not doing so can bring the
interrupt controller state out of sync with the dpci handling logic,
that expects a notification
When the PIC is on the init sequence prevent interrupt delivery. The
state of the registers is in the process of being set during the init
phase, so it makes sense to prevent any int line changes during that
process.
Requested-by: Jan Beulich
Signed-off-by: Roger Pau Monné
---
Changes since v2:
When an IO-APIC pin is switched from level to edge trigger mode the
IRR bit is cleared, so it can be used as a way to EOI an interrupt at
the IO-APIC level.
Such EOI however does not get forwarded to the dpci code like it's
done for the local APIC initiated EOI. This change adds the code in
order
Top word writes just update the destination of the interrupt, but
since there's no change on the masking or the triggering mode no
guest interrupt injection can result of such write. Add an assert to
that effect.
Requested-by: Jan Beulich
Signed-off-by: Roger Pau Monné
---
Changes since v2:
-
Hello,
The following series aims to fix some shortcomings of guest interrupt
handling when using passthrough devices. The first 5 patches are
bugfixes or cleanups, which I think should solve the issue(s) that
caused the dpci EOI timer to be introduced. However neither me nor
others seem to be
On 21.01.2021 22:27, Andrew Cooper wrote:
> From: Michał Leszczyński
>
> Add CPUID/MSR enumeration details for Processor Trace. For now, we will only
> support its use inside VMX operation. Fill in the vmtrace_available boolean
> to activate the newly introduced common infrastructure for
Andrew Cooper writes ("Re: [PATCH v7 08/10] tools/misc: Add xen-vmtrace tool"):
> On 26/01/2021 11:59, Ian Jackson wrote:
> >[Andrew:]
> >> This is example code, not a production utility.
> > Perhaps the utility could print some kind of health warning about it
> > possibly leaving this
> -Original Message-
> From: Oleksandr Tyshchenko
> Sent: 25 January 2021 19:08
> To: xen-devel@lists.xenproject.org
> Cc: Julien Grall ; Jan Beulich ;
> Andrew Cooper
> ; Roger Pau Monné ; Wei Liu
> ; George
> Dunlap ; Ian Jackson ; Julien
> Grall ;
> Stefano Stabellini ; Paul Durrant
Jan Beulich writes ("Re: [PATCH v3 00/15] zstd decompression for DomU-s +
fallout / consolidation"):
> On 26.01.2021 13:05, Ian Jackson wrote:
> > I approve of cleanups of course. But:
> >
> > Which of these cleanups were posted before the LPD ? I'm not
> > currently aware of any reason for a
> On 26 Jan 2021, at 13:19, Jan Beulich wrote:
>
> On 26.01.2021 14:17, Ian Jackson wrote:
>> Jan Beulich writes ("Re: [PATCH v4 1/2] xen: EXPERT clean-up and introduce
>> UNSUPPORTED"):
>>> On 26.01.2021 12:17, Bertrand Marquis wrote:
Maybe something we could explain more clearly in
On 26.01.2021 14:17, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH v4 1/2] xen: EXPERT clean-up and introduce
> UNSUPPORTED"):
>> On 26.01.2021 12:17, Bertrand Marquis wrote:
>>> Maybe something we could explain more clearly in the UNSUPPORTED/EXPERT
>>> config parameters instead ?
>>> We
Jan Beulich writes ("Re: [PATCH v4 1/2] xen: EXPERT clean-up and introduce
UNSUPPORTED"):
> On 26.01.2021 12:17, Bertrand Marquis wrote:
> > Maybe something we could explain more clearly in the UNSUPPORTED/EXPERT
> > config parameters instead ?
> > We could also make that more clear in the help
flight 158627 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158627/
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 26.01.2021 12:17, Bertrand Marquis wrote:
>
>
>> On 26 Jan 2021, at 11:11, Jan Beulich wrote:
>>
>> On 26.01.2021 12:06, Bertrand Marquis wrote:
On 26 Jan 2021, at 09:22, Jan Beulich wrote:
On 25.01.2021 22:27, Stefano Stabellini wrote:
> @@ -77,7 +77,7 @@ config
On 26.01.2021 13:05, Ian Jackson wrote:
> Jan Beulich writes ("[PATCH v3 00/15] zstd decompression for DomU-s + fallout
> / consolidation"):
>> Only patches 1 and 2 are strictly intended for 4.15, paralleling
>> the recent Dom0 side work (and re-using many of the files
>> introduced there, for
1 - 100 of 154 matches
Mail list logo
