>>> On 04.12.18 at 22:47, wrote:
> --- a/xen/drivers/passthrough/amd/iommu_intr.c
> +++ b/xen/drivers/passthrough/amd/iommu_intr.c
> @@ -665,6 +665,24 @@ int __init amd_setup_hpet_msi(struct msi_desc *msi_desc)
> return rc;
> }
>
> +
> +static bool intremap_table_empty(const u32 *table)
Hello, Daniel!
Could you please ack/nack the patch, so either we can merge the
series or I can address your comments if any
Thank you,
Oleksandr
On 11/30/18 9:42 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Use page directory based shared buffer implementation
now
>>> On 04.12.18 at 22:35, wrote:
> The other thing I don't get is why advertise virtualized SSBD when the
> guest setting it does nothing? If ssbd_opt=true is set, as the code is
> now, why even advertise it to the guest? I'd suggest either allowing
> the guest to turn it off or not advertise
Refactor p2m_reset_altp2m() so that it can be used to remove
redundant codepaths, fixing the locking while we're at it.
The previous code now replaced by p2m_reset_altp2m(d, i,
ALTP2M_DEACTIVATE) calls did not set p2m->min_remapped_gfn
and p2m->max_remapped_gfn because in those cases the altp2m
change_type_range() invalidates gfn ranges to lazily change the type
of a range of gfns, and also modifies the logdirty rangesets of that
p2m. At the moment, it clips both down by the hostp2m.
While this will result in correct behavior, it's not entirely efficient,
since invalidated entries
When an new altp2m view is created very early on guest boot, the
display will freeze (although the guest will run normally). This
may also happen on resizing the display. The reason is the way
Xen currently (mis)handles logdirty VGA: it intentionally
misconfigures VGA pages so that they will
For now, only do allocation/deallocation; keeping them in sync
will be done in subsequent patches.
Logdirty synchronization will only be done for active altp2ms;
so allocate logdirty rangesets (copying the host logdirty
rangeset) when an altp2m is activated, and free it when
deactivated.
On Wed, Dec 05, 2018 at 10:19:17AM +0800, Chao Gao wrote:
> I find some pass-thru devices don't work any more across guest reboot.
> Assigning it to another guest also meets the same issue. And the only
> way to make it work again is un-binding and binding it to pciback.
> Someone reported this
>>> On 04.12.18 at 21:26, wrote:
> At the moment, the implementation of Set/Way operations will go through
> all the entries of the guest P2M and flush them. However, this is very
> expensive and may render unusable a guest OS using them.
>
> For instance, Linux 32-bit will use Set/Way
>>> On 04.12.18 at 18:50, wrote:
> On Tue, Dec 04, 2018 at 05:46:38AM +, Connor Davis wrote:
>> >>> > > - 0x70
>> >>> > > - 0x71
>>
>> These are accessed from reassert_nmi. This is only called from default_do_nmi
>> in the version the guest is based on (4.20-rc2).
>
> Ops, forgot to answer
Hi Stefano,
On 04/12/2018 23:50, Stefano Stabellini wrote:
On Tue, 4 Dec 2018, Julien Grall wrote:
The LPAE format allows to store information in an entry even with the
valid bit unset. In a follow-up patch, we will take advantage of this
feature to re-purpose the valid bit for generating a
> -Original Message-
> From: Woods, Brian [mailto:brian.wo...@amd.com]
> Sent: 04 December 2018 21:47
> To: xen-de...@lists.xen.org
> Cc: Suthikulpanit, Suravee ; Woods, Brian
> ; Paul Durrant ; Roger Pau
> Monne
> Subject: [PATCH] AMD IOMMU: fix debug console IOMMU intremap output
>
>
The logdirty rangesets of the altp2ms need to be kept in sync with the
hostp2m. This means when iterating through the altp2ms, we need to
use the host p2m to clip the rangeset, not the indiviual altp2m's
value.
This change also:
- Documents that the end is non-inclusive
- Calculates an
This series aims to prevent the display from freezing when
enabling altp2m and switching to a new view (and assorted problems
when resizing the display).
The series introduces p2m_{init,free}_logdirty(), allocates a new
logdirty rangeset for each new altp2m, and propagates (under lock)
changes
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict
testid debian-hvm-install
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu
> -Original Message-
> From: Woods, Brian [mailto:brian.wo...@amd.com]
> Sent: 04 December 2018 23:31
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Suthikulpanit, Suravee
> ; Woods, Brian
> Subject: Re: [PATCH v3] amd-iommu: remove page merging code
>
> On Wed, Nov 28, 2018
flight 131052 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131052/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 70739427f55d595ad1c575c47fef00c81881e9a2
baseline version:
xen
On 04/12/2018 23:59, Stefano Stabellini wrote:
On Tue, 4 Dec 2018, Julien Grall wrote:
A follow-up patch will re-purpose the valid bit of LPAE entries to
generate fault even on entry containing valid information.
This means that when translating a guest VA to guest PA (e.g IPA) will
fail if
Hello,
On the current
6d8ffac (xenbits/master) xen/arm: gic: Remove duplicated comment in do_sgi
and
7073942 (xenbits/staging, xenbits/smoke, xenbits/coverity-tested/smoke)
pci: apply workaround for Intel errata HSE43 and BDF2/BDX2
`xl vcpu-pin` leads to oom-killer becomes mad and
It happens with credit and credit2 schedulers, with old and new vgic.
On 05.12.18 12:26, Andrii Anisov wrote:
Hello,
On the current
6d8ffac (xenbits/master) xen/arm: gic: Remove duplicated comment in do_sgi
and
7073942 (xenbits/staging, xenbits/smoke, xenbits/coverity-tested/smoke)
On 05/12/2018 10:26, Andrii Anisov wrote:
Hello,
On the current
6d8ffac (xenbits/master) xen/arm: gic: Remove duplicated comment in do_sgi
and
7073942 (xenbits/staging, xenbits/smoke, xenbits/coverity-tested/smoke)
pci: apply workaround for Intel errata HSE43 and BDF2/BDX2
`xl
For some pci device, even its PCI_INTERRUPT_PIN is not 0, it actually
doesn't support INTx mode, so its machine irq read from host sysfs is 0.
In that case, report PCI_INTERRUPT_PIN as 0 to guest and let passthrough
continue.
Cc: Roger Pau Monné
Cc: Jan Beulich
Reviewed-by: Roger Pau Monné
flight 130980 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130980/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 129475
build-i386
Hello Julien,
On 05.12.18 12:49, Julien Grall wrote:
I am not sure to understand what is the relation between the two.
Me confused as well. I just notified about my observations.
What is the latest Xen commit where the oom-killer does not trigger?
I didn't bisect it nor digged into it. I'm
>>> On 04.12.18 at 20:38, wrote:
> On Tue, 4 Dec 2018, Jan Beulich wrote:
>> >>> On 03.12.18 at 22:03, wrote:
>> > To be used in constant initializations of mfn_t variables, such as:
>> >
>> > static mfn_t node = mfn_init(MM_ADDR);
>> >
>> > It is necessary because static inline functions
This patch removes any implicit flushing that occurs in the implementation
of map and unmap operations and adds new iommu_map/unmap() wrapper
functions. To maintain sematics of the iommu_legacy_map/unmap() wrapper
functions, these are modified to call the new wrapper functions and then
perform an
Paul Durrant (4):
amd-iommu: add flush iommu_ops
iommu: rename wrapper functions
iommu: elide flushing for higher order map/unmap operations
x86/mm/p2m: stop checking for IOMMU shared page tables in mmio_order()
xen/arch/arm/p2m.c| 11 ++-
xen/arch/x86/mm.c
A subsequent patch will add semantically different versions of
iommu_map/unmap() so, in advance of that change, this patch renames the
existing functions to iommu_legacy_map/unmap() and modifies all call-sites.
It also adjusts a comment that refers to iommu_map_page(), which was re-
named by a
Now that the iommu_map() and iommu_unmap() operations take an order
parameter and elide flushing there's no strong reason why modifying MMIO
ranges in the p2m should be restricted to a 4k granularity simply because
the IOMMU is enabled but shared page tables are not in operation.
Signed-off-by:
The iommu_ops structure contains two methods for flushing: 'iotlb_flush' and
'iotlb_flush_all'. This patch adds implementations of these for AMD IOMMUs.
The iotlb_flush method takes a base DFN and a (4k) page count, but the
flush needs to be done by page order (i.e. 0, 9 or 18). Because a flush
This run is configured for baseline tests only.
flight 75634 xen-4.9-testing real [real]
http://osstest.xensource.com/osstest/logs/75634/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-win10-i386 10
> -Original Message-
> From: Paul Durrant
> Sent: 05 December 2018 12:57
> To: 'Jan Beulich'
> Cc: Brian Woods ; Suravee Suthikulpanit
> ; Andrew Cooper
> ; Roger Pau Monne ; Wei
> Liu ; xen-devel
> Subject: RE: [PATCH v3 1/4] amd-iommu: add flush iommu_ops
>
> > -Original
>>> On 05.12.18 at 13:58, wrote:
>> From: Paul Durrant
>> Sent: 05 December 2018 12:57
>>
>> > From: Jan Beulich [mailto:jbeul...@suse.com]
>> > Sent: 05 December 2018 11:46
>> >
>> > >>> On 05.12.18 at 12:29, wrote:
>> > > --- a/xen/drivers/passthrough/amd/iommu_map.c
>> > > +++
On 05.12.18 13:45, Julien Grall wrote:
Well, at least the kernel thinks it does not have anymore memory (see the call
trace).
Yes, it thinks so. But it is not linked to domain .
What do you mean by all your routine?
I mean all things I'm playing with now. Running tbm baremetal app in
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 05 December 2018 13:13
> To: Paul Durrant
> Cc: Brian Woods ; Suravee Suthikulpanit
> ; Andrew Cooper
> ; Roger Pau Monne ; Wei
> Liu ; xen-devel
> Subject: RE: [PATCH v3 1/4] amd-iommu: add flush iommu_ops
>
>
On Wed, Dec 05, 2018 at 01:06:29PM +0100, Roger Pau Monne wrote:
> diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
> index 2af2bd8c3d..7217b2404a 100644
> --- a/xen/arch/x86/hvm/dom0_build.c
> +++ b/xen/arch/x86/hvm/dom0_build.c
> @@ -358,6 +358,9 @@ static int __init
On Wed, Dec 05, 2018 at 02:58:30AM -0500, Zhao Yan wrote:
> For some pci device, even its PCI_INTERRUPT_PIN is not 0, it actually
> doesn't support INTx mode, so its machine irq read from host sysfs is 0.
> In that case, report PCI_INTERRUPT_PIN as 0 to guest and let passthrough
> continue.
>
>
> -Original Message-
> From: Qemu-devel [mailto:qemu-devel-
> bounces+paul.durrant=citrix@nongnu.org] On Behalf Of Paul Durrant
> Sent: 05 December 2018 12:05
> To: Anthony Perard
> Cc: Kevin Wolf ; Stefano Stabellini
> ; qemu-bl...@nongnu.org; qemu-de...@nongnu.org;
> Max Reitz ;
>>> On 05.12.18 at 12:29, wrote:
> --- a/xen/drivers/passthrough/amd/iommu_map.c
> +++ b/xen/drivers/passthrough/amd/iommu_map.c
> @@ -634,6 +634,56 @@ int amd_iommu_unmap_page(struct domain *d, dfn_t dfn)
> spin_unlock(>arch.mapping_lock);
>
> amd_iommu_flush_pages(d, dfn_x(dfn), 0);
On 05/12/2018 10:59, Andrii Anisov wrote:
Hello Julien,
Hi,
On 05.12.18 12:49, Julien Grall wrote:
I am not sure to understand what is the relation between the two.
Me confused as well. I just notified about my observations.
What is the latest Xen commit where the oom-killer does not
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 05 December 2018 11:46
> To: Paul Durrant
> Cc: Brian Woods ; Suravee Suthikulpanit
> ; Andrew Cooper
> ; Roger Pau Monne ; Wei
> Liu ; xen-devel
> Subject: Re: [PATCH v3 1/4] amd-iommu: add flush iommu_ops
>
>
On 05/12/2018 12:40, Andrii Anisov wrote:
On 05.12.18 14:15, Julien Grall wrote:
Yes, it thinks so. But it is not linked to domain .
What do you mean?
It should be read as "But it is not linked to domain memory size".
So if you increase the memory of the dom0 you will still see the
Hello,
There have been several reports of PVH Dom0 builder running out of
memory due to bad paging memory approximation done in
dom0_compute_nr_pages. The most recent reports is:
https://lists.xenproject.org/archives/html/xen-devel/2018-11/msg03103.html
This series attempts to improve the
To note it's calculating the approximate amount of memory required by
shadow paging.
No functional change.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: andrei.seme...@bertin.fr
---
xen/arch/x86/dom0_build.c| 4 ++--
Current approximation of paging memory usage is based on the required
amount when running in shadow mode and doesn't take into account the
memory required by the IOMMU page tables.
Fix this by introducing a function to calculate the amount of memory
required by HAP/IOMMU page tables. The formula
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 29 November 2018 18:49
> To: Paul Durrant
> Cc: qemu-bl...@nongnu.org; qemu-de...@nongnu.org; xen-
> de...@lists.xenproject.org; Stefano Stabellini ;
> Kevin Wolf ; Max Reitz
> Subject: Re: [PATCH
>>> On 05.12.18 at 14:15, wrote:
> Ah ok... no, I got what you meant and just completely typo-ed it. I'll send
> v4 unless you're happy to fix on commit.
I'm fine adjusting this while committing; I hope I won't overlook the note
I've taken once I get there.
Jan
On Wed, Dec 05, 2018 at 12:43:57PM +, Paul Durrant wrote:
> > > > +value = g_strdup_vprintf(fmt, ap);
> > >
> > > Looks like g_vasprintf() would be better, since it returns the lenght as
> > > well.
> > >
> >
> > Yes.
>
> I tried this and it appears not to exist in the version of glib in
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 05 December 2018 13:59
> To: Paul Durrant
> Cc: Kevin Wolf ; Stefano Stabellini
> ; qemu-bl...@nongnu.org; qemu-de...@nongnu.org;
> Max Reitz ; xen-devel@lists.xenproject.org
> Subject: Re: [PATCH
On 05.12.18 15:13, Julien Grall wrote:
I need at least some sort of proof that Xen might corrupt the kernel. I don't
believe we manage to just corrupt the kernel memory subsystem with good enough
value reliably. So maybe we should start looking at more plausible cause.
I think I would be
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 03 December 2018 14:43
> To: Paul Durrant
> Cc: qemu-bl...@nongnu.org; qemu-de...@nongnu.org; xen-
> de...@lists.xenproject.org; Kevin Wolf ; Max Reitz
> ; Stefano Stabellini
> Subject: Re: [PATCH
On 12/5/18 4:32 AM, Roger Pau Monné wrote:
> On Wed, Dec 05, 2018 at 10:19:17AM +0800, Chao Gao wrote:
>> I find some pass-thru devices don't work any more across guest reboot.
>> Assigning it to another guest also meets the same issue. And the only
>> way to make it work again is un-binding and
flight 130970 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130970/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR.
vs. 130862
Current approximation of paging memory usage is based on the required
amount when running in shadow mode and doesn't take into account the
memory required by the IOMMU page tables.
Fix this by introducing a function to calculate the amount of memory
required by HAP/IOMMU page tables. The formula
To note it's calculating the approximate amount of memory required by
shadow paging.
No functional change.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: andrei.seme...@bertin.fr
---
xen/arch/x86/dom0_build.c| 4 ++--
flight 130971 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130971/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl broken
test-amd64-i386-xl-qemut-ws16-amd64
For (I hope) obvious reasons only the ones used at runtime get
converted.
Signed-off-by: Jan Beulich
Reviewed-by: Wei Liu
Acked-by: Andrew Cooper
---
v2: Drop open-coded numbers from macro invocations.
--- a/xen/arch/x86/smp.c
+++ b/xen/arch/x86/smp.c
@@ -29,12 +29,12 @@
void
This is intentionally not touching hooks used rarely (or not at all)
during the lifetime of a VM, unless perhaps sitting on an error path
next to a call which gets changed (in which case I think the error
path better remains consistent with the respective main path).
Signed-off-by: Jan Beulich
>>> On 05.12.18 at 03:19, wrote:
> --- a/drivers/xen/xen-pciback/pci_stub.c
> +++ b/drivers/xen/xen-pciback/pci_stub.c
> @@ -87,6 +87,55 @@ static struct pcistub_device *pcistub_device_alloc(struct
> pci_dev *dev)
> return psdev;
> }
>
> +/*
> + * Reset Xen internal MSI-X state by
On Wed, Dec 05, 2018 at 12:05:23PM +, Paul Durrant wrote:
> > > +value = xs_read(xsh, XBT_NULL, path, NULL);
> >
> > The xenstore.h isn't clear about failure of this function, it is
> > supposed to return a malloced value. Do we actually need to check if value
> > is NULL?
>
> The
>>> On 03.12.18 at 17:18, wrote:
> At the time of writing, the spec is available from:
>
>
> https://developer.amd.com/wp-content/resources/124441_AMD64_SpeculativeStoreB
> ypassDisable_Whitepaper_final.pdf
>
> Future hardware (Zen v2) is expect to have hardware MSR_SPEC_CTRL support,
>
CC: Juergen Gross
On 04/12/18 17:24, Jennifer Herbert wrote:
Since Linux 4.12, there has been a
commita1e23a42f1bdc00e32fc4869caef12e4e6272f26
“rtc: cmos: Do not assume irq 8 for rtc when there are no legacy irqs”
The commit effectively disabled requesting IRQ 8 for systems without PIC
>>> On 03.12.18 at 17:18, wrote:
> --- a/xen/arch/x86/cpu/amd.c
> +++ b/xen/arch/x86/cpu/amd.c
> @@ -419,6 +419,97 @@ static void __init noinline amd_probe_legacy_ssbd(void)
> }
>
> /*
> + * This is all a gross hack, but Xen really doesn't have flexible-enough
> + * per-cpu infrastructure to
While indirect calls have always been more expensive than direct ones,
their cost has further increased with the Spectre v2 mitigations. In a
number of cases we simply pointlessly use them in the first place. In
many other cases the indirection solely exists to abstract from e.g.
vendor specific
We don't need bigger alignment except when calling EFI boot or runtime
services functions (and we don't guarantee that either, as explained
close to the top of xen/common/efi/runtime.c in the struct efi_rs_state
declaration). Hence if the compiler supports reducing stack alignment
from the ABI
While not strictly necessary, change the VMX initialization logic to
update the function table in start_vmx() from NULL rather than to NULL,
to make more obvious that we won't ever change an already (explicitly)
initialized function pointer.
Signed-off-by: Jan Beulich
Acked-by: Kevin Tian
While we don't mean to run their objtool over our generated code, it
still seems desirable to avoid calls to further functions before a
function's frame pointer is set up.
Suggested-by: Andrew Cooper
Signed-off-by: Jan Beulich
Reviewed-by: Wei Liu
---
v6: Fix build issue with old gcc.
v5: New.
Even if unlikely, donate_page() should not ignore the possible need to
obtain a domain reference. To make people look more closely when they
add new uses of domain_adjust_tot_pages(), force its return value to be
checked. This in turn requires a benign change to assign_pages().
Signed-off-by: Jan
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 05 December 2018 16:26
> To: xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; Anthony Perard
> ; Ian Jackson ; Wei Liu
>
> Subject: [PATCH] tools/xenstore: Document failure for
>
>>> On 05.12.18 at 10:18, wrote:
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -1002,30 +1002,43 @@ int p2m_change_type_one(struct domain *d, unsigned
> long gfn_l,
> return rc;
> }
>
> -/* Modify the p2m type of a range of gfns from ot to nt. */
> +/* Modify the p2m
In a number of cases the targets of indirect calls get determined once
at boot time. In such cases we can replace those calls with direct ones
via our alternative instruction patching mechanism.
Some of the targets (in particular the hvm_funcs ones) get established
only in pre-SMP initcalls,
For now only the ones used during entering/exiting of idle states are
converted. Additionally pm_idle{,_save} and lapic_timer_{on,off} can't
be converted, as they may get established rather late (when Dom0 is
already active).
Note that for patching to be deferred until after the pre-SMP initcalls
This looks to be the only frequently executed hook; don't bother
patching any other ones.
Signed-off-by: Jan Beulich
Reviewed-by: Wei Liu
Acked-by: Andrew Cooper
---
v2: New.
--- a/xen/drivers/cpufreq/utility.c
+++ b/xen/drivers/cpufreq/utility.c
@@ -364,7 +364,8 @@ int
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 03 December 2018 15:46
> To: Paul Durrant
> Cc: qemu-bl...@nongnu.org; qemu-de...@nongnu.org; xen-
> de...@lists.xenproject.org; Stefano Stabellini
> Subject: Re: [PATCH 06/18] xen: add grant table
A few things I had run into while working on that issue:
1: x86: reduce code duplication in guest_remove_page()
2: make domain_adjust_tot_pages() __must_check
They don't depend on one another, they're grouped together
just because of their origin.
Jan
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 04 December 2018 14:25
> To: Paul Durrant
> Cc: qemu-bl...@nongnu.org; qemu-de...@nongnu.org; xen-
> de...@lists.xenproject.org; Stefano Stabellini
> Subject: Re: [PATCH 07/18] xen: add event channel
Those functions can return NULL on failure, document it in the public
header.
Signed-off-by: Anthony PERARD
---
tools/xenstore/include/xenstore.h | 7 +--
tools/xenstore/xs.c | 1 +
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git
This is intentionally not touching hooks used rarely (or not at all)
during the lifetime of a VM, like {domain,vcpu}_initialise or cpu_up,
as well as nested, VM event, and altp2m ones (they can all be done
later, if so desired). Virtual Interrupt delivery ones will be dealt
with in a subsequent
Quite a bit of duplicate code has accumulated on the "paging" types
special case path. Re-use what can be re-used from the common path.
Since it needs touching anyway, slightly re-format and extend the
gdprintk() on the common path as well.
Signed-off-by: Jan Beulich
---
v2: Re-base.
---
>>> On 03.12.18 at 17:18, wrote:
> +static void __init noinline amd_probe_legacy_ssbd(void)
> +{
> + uint64_t new;
> +
> + /*
> + * Search for mechanisms of controlling Memory Disambiguation.
> + *
> + * If the CPU reports that it is fixed, there is nothing to do. If we
>
On Wed, Dec 05, 2018 at 02:00:43AM -0700, Jan Beulich wrote:
> >>> On 04.12.18 at 22:47, wrote:
> > --- a/xen/drivers/passthrough/amd/iommu_intr.c
> > +++ b/xen/drivers/passthrough/amd/iommu_intr.c
> > @@ -665,6 +665,24 @@ int __init amd_setup_hpet_msi(struct msi_desc
> > *msi_desc)
> >
On Wed, 5 Dec 2018, Stefano Stabellini wrote:
> Hi,
>
> This series implements a new xl config entry. Users can use the new
> config entry to statically setup shared memory areas among VMs that
> don't have grant table support so that they could communicate with each
> other through the static
flight 130995 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130995/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 16
guest-start/debianhvm.repeat fail REGR. vs.
On Thu, Nov 22, 2018 at 03:49:02PM +, Wei Liu wrote:
> Also rename the old test to have -gcc suffix.
>
> Signed-off-by: Wei Liu
Acked-by: Doug Goldstein
Nice addition. Sorry for the delay.
___
Xen-devel mailing list
On 10/09/2018 11:13, Jan Beulich wrote:
>
>> Equally, it may still be able to service #MC's, so I can't see how it is
>> safe for us to ever free the percpu data.
> I'm having trouble seeing how this remark relates to the series here.
Because you've tried to make NMIs safe, but not made
flight 131053 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131053/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-freebsd broken
On Wed, Dec 5, 2018 at 9:20 AM Julien Grall wrote:
> On 04/12/2018 09:08, Christopher Clark wrote:
> > On Sun, Dec 2, 2018 at 12:11 PM Julien Grall wrote:
> >> On 01/12/2018 01:32, Christopher Clark wrote:
> >>> diff --git a/xen/include/public/argo.h b/xen/include/public/argo.h
> >>> ...
> >>>
flight 130989 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130989/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-cubietruck 16 guest-start/debian.repeat fail in 130904
pass in 130989
From: Zhongze Liu
Author: Zhongze Liu
Add docs to document the motivation, usage, use cases and other
relevant information about the static shared memory feature.
This is for the proposal "Allow setting up shared memory areas between VMs
from xl config file". See:
From: Zhongze Liu
Add the parsing utils for the newly introduced libxl_static_sshm struct
to the libxl/libxlu_* family. And add realated parsing code in xl to
parse the struct from xl config files. This is for the proposal "Allow
setting up shared memory areas between VMs from xl config file"
Shared memory regions need to be advertised to the guest. Fortunately, a
device tree binding for special memory regions already exist:
reserved-memory.
Add a reserved-memory node for each shared memory region, for both
owners and borrowers.
Signed-off-by: Stefano Stabellini
---
Changes in v9:
-
From: Zhongze Liu
The existing XENMAPSPACE_gmfn_foreign subop of XENMEM_add_to_physmap forbids
a Dom0 to map memory pages from one DomU to another, which restricts some useful
yet not dangerous use cases -- such as sharing pages among DomU's so that they
can do shm-based communication.
This
From: Zhongze Liu
Add libxl__sshm_add to map shared pages from one DomU to another, The mapping
process involves the following steps:
* Set defaults and check for further errors in the static_shm configs:
overlapping areas, invalid ranges, duplicated owner domain,
not page aligned, no
From: Zhongze Liu
Add a new structure to the IDL family to represent static shared memory regions
as proposed in the proposal "Allow setting up shared memory areas between VMs
from xl config file" (see [1]).
[1] https://lists.xen.org/archives/html/xen-devel/2017-08/msg03242.html
Signed-off-by:
From: Zhongze Liu
Add libxl__sshm_del to unmap static shared memory areas mapped by
libxl__sshm_add during domain creation. The unmapping process is:
* For a owner: decrease the refcount of the sshm region, if the refcount
reaches 0, cleanup the whole sshm path.
* For a borrower:
1) unmap
Hi all,
This series implements a new xl config entry. Users can use the new
config entry to statically setup shared memory areas among VMs that
don't have grant table support so that they could communicate with each
other through the static shared memory areas.
It was originally developed by
flight 131068 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131068/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl
On 05/12/2018 16:17, Jan Beulich wrote:
> Quite a bit of duplicate code has accumulated on the "paging" types
> special case path. Re-use what can be re-used from the common path.
>
> Since it needs touching anyway, slightly re-format and extend the
> gdprintk() on the common path as well.
>
>
flight 75636 distros-debian-squeeze real [real]
http://osstest.xensource.com/osstest/logs/75636/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-amd64-squeeze-netboot-pygrub 10 debian-di-install fail like
75624
Patchew URL:
https://patchew.org/QEMU/1544049446-6359-1-git-send-email-liam.merw...@oracle.com/
Hi,
This series failed the docker-mingw@fedora build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST
1 - 100 of 139 matches
Mail list logo
