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é
Sign
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 git://xenbits.xen.org/qemu-xen-traditiona
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 avail
>>> 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 canno
>>> 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 operations
>>> 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 it
>>> 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 t
> -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
>
> Wh
> -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 at
>>> 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)
u
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 to
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 "inclusiv
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
id
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 outsid
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 fault.
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.
Signed-o
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 iss
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 tra
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 8285
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 t
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 slash
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)
p
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
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 vcp
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 t
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: Pa
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
op
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 e
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 prev
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.
>
> Cc
>>> 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(&hd->arch.mapping_lock);
>
> amd_iommu_flush_pages(d, dfn_x(dfn),
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 tr
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 differ
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 windows-install
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 u
> -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 04/18
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 situat
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 ++--
xen/arch/x86/hvm/dom0_build.
On 05/12/2018 11:59, Andrii Anisov wrote:
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? A memory corruption by Xen is extremely unlikely. So
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 pvh
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".
A memory corruption by Xen is extremely unlikely.
I believe in that.
So it looks like to me this is a related t
> -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 ; xen-
> -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
>
> >
> -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 Message---
>>> 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
>> > > +++ b/xen/drivers/p
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 erro
> -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 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
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 bi
> -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 04/18]
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 abl
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
test-amd64-
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 ++--
xen/arch/x86/hvm/dom0_build.
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 situat
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 u
> -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 05/18
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 1
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 ha
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, makin
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 pat
Signed-off-by: Jan Beulich
Reviewed-by: Wei Liu
Reviewed-by: Andrew Cooper
---
v2: Drop open-coded number from macro invocation.
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -185,7 +185,7 @@ void ctxt_switch_levelling(const struct
}
if (ctxt_switch_maskin
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
Review
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 comp
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.
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 send_IPI_mask(
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 __cpufreq_driver_target
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 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
Re
> -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 inte
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
_
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.
--- a/xen/
> -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 in
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
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 a/tools/xenstore/include/xenstore.h
>>> 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 invoki
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 comment
> -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
> xs_{read,directory,re
>>> 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 ty
>>> 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,
> incl
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
contr
>>> 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 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 d
On 05/12/2018 16:57, Jan Beulich wrote:
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 f
On 05/12/2018 16:50, Jan Beulich wrote:
>
>> --- a/xen/include/asm-x86/cpufeatures.h
>> +++ b/xen/include/asm-x86/cpufeatures.h
>> @@ -25,6 +25,7 @@ XEN_CPUFEATURE(XEN_SMAP,(FSCAPINTS+0)*32+11) /*
>> SMAP gets used by Xen it
>> XEN_CPUFEATURE(LFENCE_DISPATCH, (FSCAPINTS+0)*32+12) /* lfenc
Hi Christoffer,
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
index 20dabc0..5ad8e2b 100644
--- a/xen/include/public/argo.h
+
Signed-off-by: Stefano Stabellini
---
docs/misc/arm/device-tree/booting.txt | 108 ++
1 file changed, 108 insertions(+)
diff --git a/docs/misc/arm/device-tree/booting.txt
b/docs/misc/arm/device-tree/booting.txt
index 317a9e9..f5aaf8f 100644
--- a/docs/misc/arm/de
Read the dtb fragment corresponding to a passthrough device from memory
at the location referred to by the "multiboot,dtb" compatible node.
Copy the fragment to the guest dtb.
Add a dtb_bootmodule field to struct kernel_info to find the dtb
fragment for a guest.
Signed-off-by: Stefano Stabellini
Scan the user provided dtb fragment at boot. For each device node, map
memory to guests, and route interrupts and setup the iommu.
Device memory is only mapped 1:1. It is not possible to assign devices at
locations that conflict with the DomU memory map.
The iommu is setup by passing the to the d
Hi all,
This small patch series adds device assignment support to Dom0less.
The last patch is the documentation.
Cheers,
Stefano
The following changes since commit 70739427f55d595ad1c575c47fef00c81881e9a2:
pci: apply workaround for Intel errata HSE43 and BDF2/BDX2 (2018-12-04
14:04:54 +01
We don't have a clear way to know how many virtual SPIs we need for the
boot domains. For simplicity, allocate as many as natively supported,
just like for dom0.
Signed-off-by: Stefano Stabellini
---
xen/arch/arm/domain_build.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git
Detect "multiboot,dtb" compatible nodes. Add them to the bootmod array
as BOOTMOD_DTB. In kernel_probe, find the right BOOTMOD_DTB and store a
pointer to it in dtb_bootmodule.
Signed-off-by: Stefano Stabellini
---
xen/arch/arm/bootfdt.c | 2 ++
xen/arch/arm/kernel.c | 12 +++
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 04 December 2018 12:11
> To: Paul Durrant
> Cc: qemu-bl...@nongnu.org; qemu-de...@nongnu.org; xen-
> de...@lists.xenproject.org; Stefano Stabellini ;
> Stefan Hajnoczi ; Kevin Wolf ; Max
> Reitz
> Subje
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 03 December 2018 18:09
> To: Paul Durrant
> Cc: qemu-bl...@nongnu.org; qemu-de...@nongnu.org; xen-
> de...@lists.xenproject.org; Stefan Hajnoczi ; Kevin
> Wolf ; Max Reitz ; Stefano Stabellini
>
> Subje
On 05/12/2018 16:39, Jan Beulich wrote:
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 exp
On 05/12/2018 08:41, Jan Beulich wrote:
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
>>
flight 130985 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130985/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-pygrub 7 xen-boot fail in 130895 pass in 130985
test-armhf-armhf-xl-rtds 6
"3rd slot" is confusing, because it is only correct if you start counting from
the 0-th slot. Most people would expect this to be phrased as "4th slot", but
switch to the entirely unambiguous "slot 3" which is also in line with the
adjacent code.
While fixing that, update the comment to indicate
On 22/11/2018 15:01, Jan Beulich wrote:
On 21.11.18 at 14:21, wrote:
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -2184,24 +2184,29 @@ bool_t p2m_altp2m_lazy_copy(struct vcpu *v, paddr_t
>> gpa,
>> unsigned long mask;
>> mfn_t mfn;
>> int rv;
>> +boo
1 - 100 of 143 matches
Mail list logo
