flight 125819 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125819/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
Regressions
flight 125797 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125797/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64
flight 125795 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125795/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64
flight 125788 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125788/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-pvops
flight 125816 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125816/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
Regressions
This run is configured for baseline tests only.
flight 75055 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75055/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75054
flight 125789 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125789/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-pvops
flight 125814 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125814/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
Regressions
flight 125803 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125803/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 9e6c4f1527e6f72d6ada10aa39854f2bdd40772f
baseline version:
ovmf
flight 125786 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125786/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken
build-arm64
flight 125810 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125810/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
Regressions
commit b3681dd548d06deb2e1573890829dff4b15abf46 upstream.
This version applies to v4.9.
From Andy Lutomirski, original author:
error_entry and error_exit communicate the user vs kernel status of
the frame using %ebx. This is unnecessary -- the information is in
regs->cs. Just use regs->cs.
On 08/08/2018 07:46 AM, Roger Pau Monne wrote:
> The current balloon code tries to calculate a delta factor for the
> balloon target when running in HVM mode in order to account for memory
> used by the firmware.
>
> This workaround for memory accounting doesn't work properly on a PVH
> Dom0, that
On Tue, Aug 07, 2018 at 01:51:07AM -0600, Jan Beulich wrote:
> >>> On 06.08.18 at 21:07, wrote:
> > On Thu, Aug 02, 2018 at 01:09:06AM -0600, Jan Beulich wrote:
> >> >>> On 02.08.18 at 00:20, wrote:
> >> > On Tue, Jul 31, 2018 at 05:25:27AM -0600, Jan Beulich wrote:
> >> >> Code structure wise
On Thu, Aug 02, 2018 at 12:24:35PM +0100, Anthony PERARD wrote:
> That replace a section of the OVMF binary called VarStore by that ELF
> header. It's empty and libxl doesn't know how to use it. (QEMU/KVM would
> have a flash device loading the store, so it can be written to.)
> ## Loading
On Wed, Aug 08, 2018 at 07:15:54AM -0600, Jan Beulich wrote:
> >>> On 08.08.18 at 12:07, wrote:
> > Several people have reported hardware issues (malfunctioning USB
> > controllers) due to iommu page faults on Intel hardware. Those faults
> > are caused by missing RMRR (VTd) entries in the ACPI
On Wed, Aug 08, 2018 at 06:32:00AM -0600, Jan Beulich wrote:
> >>> On 08.08.18 at 12:07, wrote:
> > Introduce a new dom0-iommu=inclusive generic option that supersedes
> > iommu_inclusive_mapping. The previous behaviour is preserved and the
> > option should only be enabled by default on Intel
On Thu, Aug 02, 2018 at 06:21:31PM +0200, Roger Pau Monné wrote:
> On Thu, Aug 02, 2018 at 12:24:35PM +0100, Anthony PERARD wrote:
> > ## New binary, separated from QEMU/KVM one.
> >
> > Right now, the rules to build the firmware are located in
> > `OvmfPkg/OvmfPkgX64.dsc`, a platform. I've
On Wed, Aug 08, 2018 at 06:10:39AM -0600, Jan Beulich wrote:
> >>> On 08.08.18 at 12:07, wrote:
> > +Note that all the above options are mutually exclusive. Specifying more
> > than
> > +one on the `dom0-iommu` command line will result in undefined behavior.
>
> Isn't this more strict than it
On Wed, Aug 08, 2018 at 04:25:27PM +0200, Juergen Gross wrote:
> The struct persistent_gnt flags member is meant to be a bitfield of
> different flags. There is only PERSISTENT_GNT_ACTIVE flag left, so
> convert it to a bool named "active".
>
> Signed-off-by: Juergen Gross
Reviewed-by: Roger
On Wed, Aug 08, 2018 at 04:25:25PM +0200, Juergen Gross wrote:
> Add a periodic cleanup function to remove old persistent grants which
> are no longer in use on the backend side. This avoids starvation in
> case there are lots of persistent grants for a device which no longer
> is involved in I/O
On Wed, Aug 08, 2018 at 04:25:24PM +0200, Juergen Gross wrote:
> Persistent grants are allocated until a threshold per ring is being
> reached. Those grants won't be freed until the ring is being destroyed
> meaning there will be resources kept busy which might no longer be
> used.
>
> Instead of
On Wed, Aug 08, 2018 at 04:02:09PM +0100, Anthony PERARD wrote:
> On Thu, Aug 02, 2018 at 04:44:56PM +0100, Wei Liu wrote:
> > On Thu, Aug 02, 2018 at 12:24:35PM +0100, Anthony PERARD wrote:
> > > ## Loading binary at 0x1 (1MB, like hvmloader on HVM)
> > >
> > > Right now, the OVMF blob is
x86 maintainers, this needs you ack too even though it has "xen" tag in
the subject, thanks.
On 08/08/2018 02:19 AM, Juergen Gross wrote:
> All functions in arch/x86/xen/irq.c and arch/x86/xen/xen-asm*.S are
> specific to PV guests. Include them in the kernel with
> CONFIG_XEN_PV only.
>
> Make
flight 125785 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125785/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken
build-arm64-xsm
On Thu, Aug 02, 2018 at 04:44:56PM +0100, Wei Liu wrote:
> On Thu, Aug 02, 2018 at 12:24:35PM +0100, Anthony PERARD wrote:
> > ## New binary, separated from QEMU/KVM one.
> >
> > Right now, the rules to build the firmware are located in
> > `OvmfPkg/OvmfPkgX64.dsc`, a platform. I've created a new
> 2. Is it possible that something else in that path writes into
> VM_ENTRY_INTR_INFO (which the vmx_intr_assist() logic can't possibly
> prevent)? For example, in my Xen 4.7.5 sources, there's a
> pt_restore_timer(v); call in hvm_do_resume() before the vm_event
> emulation code.
Actually even
In case we don't want pv block devices we should not test parameters
for sanity and eventually print out error messages. So test precluding
conditions before checking parameters.
Signed-off-by: Juergen Gross
Reviewed-by: Roger Pau Monné
---
drivers/block/xen-blkfront.c | 18 +-
Add a periodic cleanup function to remove old persistent grants which
are no longer in use on the backend side. This avoids starvation in
case there are lots of persistent grants for a device which no longer
is involved in I/O business.
Signed-off-by: Juergen Gross
---
Hello,
I'm seeing rare occasions where this backtrace occurs at a point in
__vmx_inject_exception() where there's already a valid interrupt set up
in VM_ENTRY_INTR_INFO (that is, once the value is __vmread(), intr_info
& INTR_INFO_VALID_MASK is non-zero):
Xen call trace:
[]
This run is configured for baseline tests only.
flight 75054 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75054/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail blocked in 75052
pers_gnts_lock isn't being used anywhere. Remove it.
Signed-off-by: Juergen Gross
Reviewed-by: Roger Pau Monné
---
drivers/block/xen-blkback/common.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/block/xen-blkback/common.h
b/drivers/block/xen-blkback/common.h
index
Persistent grants are allocated until a threshold per ring is being
reached. Those grants won't be freed until the ring is being destroyed
meaning there will be resources kept busy which might no longer be
used.
Instead of freeing only persistent grants until the threshold is
reached add a
The struct persistent_gnt flags member is meant to be a bitfield of
different flags. There is only PERSISTENT_GNT_ACTIVE flag left, so
convert it to a bool named "active".
Signed-off-by: Juergen Gross
---
drivers/block/xen-blkback/blkback.c | 13 ++---
drivers/block/xen-blkback/common.h
Persistent grants are used in the Xen's blkfront/blkback drivers to
avoid mapping/unmapping of I/O buffers in the backend for each I/O.
While this speeds up processing quite a bit there are problems related
to persistent grants in some configurations: domains with multiple
block devices making
On Thu, Aug 02, 2018 at 06:23:54AM -0600, Jan Beulich wrote:
> >>> On 02.08.18 at 13:24, wrote:
> > ## Loading binary at 0x1 (1MB, like hvmloader on HVM)
> >
> > Right now, the OVMF blob is loaded (by hvmloader) just below 4GB, with
> > hvmloader moving some RAM around to allow that. But
A previous patch added support for priv-mapping guest resources directly
(rather than having to foreign-map, which requires P2M modification for
HVM guests).
This patch makes use of the new API to seed the guest grant table unless
the underlying infrastructure (i.e. privcmd) doesn't support it,
These patches are the patches from my original resource mapping series
that did not make it into 4.11.
Paul Durrant (2):
common: add a new mappable resource type: XENMEM_resource_grant_table
tools/libxenctrl: use new xenforeignmemory API to seed grant table
tools/libxc/include/xc_dom.h
This patch allows grant table frames to be mapped using the
XENMEM_acquire_resource memory op.
NOTE: This patch expands the on-stack mfn_list array in acquire_resource()
but it is still small enough to remain on-stack.
NOTE: This patch also removes a bogus comment above the
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 08 August 2018 14:39
> To: Paul Durrant
> Cc: Julien Grall ; Andrew Cooper
> ; Wei Liu ; George
> Dunlap ; Ian Jackson ;
> Stefano Stabellini ; xen-devel de...@lists.xenproject.org>; Konrad Rzeszutek Wilk
> ; Tim
flight 125802 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125802/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
Regressions
flight 125801 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125801/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-freebsd 7 freebsd-buildfail REGR. vs. 125317
Tests which did
flight 125784 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125784/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-pvops
>>> On 03.08.18 at 19:22, wrote:
> As noted in [1] the tri-state nature of need_iommu after commit 3e06b989 is
> confusing.
>
> Because arch_iommu_populate_page_table() removes pages from the page list
> as it maps them it is actually safe to re-invoke multiple times without
> the need for any
On 08/08/18 14:15, Paul Durrant wrote:
>>
>> @@ -3906,6 +3943,38 @@ int gnttab_map_frame(struct domain *d,
> unsigned long idx, gfn_t gfn,
>> return rc;
>> }
>>
>> +int gnttab_get_shared_frame(struct domain *d, unsigned long idx,
>> +
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Paul Durrant
> Sent: 08 August 2018 12:33
> To: 'Jan Beulich'
> Cc: Stefano Stabellini ; Wei Liu
> ; Andrew Cooper ; Tim
> (Xen.org) ; George Dunlap ; Ian
> Jackson ; xen-devel
>>> On 08.08.18 at 12:07, wrote:
> Several people have reported hardware issues (malfunctioning USB
> controllers) due to iommu page faults on Intel hardware. Those faults
> are caused by missing RMRR (VTd) entries in the ACPI tables. Those can
> be worked around on VTd hardware by manually
> -Original Message-
> From: Andrew Cooper
> Sent: 08 August 2018 10:59
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Ian Jackson
> Subject: Re: [Xen-devel] [PATCH v21 2/2] tools/libxenctrl: use new
> xenforeignmemory API to seed grant table
>
> On 08/08/18 10:00, Paul
>>> On 08.08.18 at 12:07, wrote:
> So it's done before the iommu is initialized. This is required in
> order to be able to fetch the MMCFG regions from the domain struct.
Is this a useful change to make? Regions not reported through the MCFG
table will need punching holes anyway, so why not
>>> On 08.08.18 at 12:07, wrote:
> Introduce a new dom0-iommu=inclusive generic option that supersedes
> iommu_inclusive_mapping. The previous behaviour is preserved and the
> option should only be enabled by default on Intel hardware.
Why "should" instead of "is"?
> @@ -1221,6 +1221,18 @@ PV
flight 125790 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125790/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b6e48ec6412eab0f21fdff5a045a7ee516574d44
baseline version:
ovmf
>>> On 08.08.18 at 12:07, wrote:
> @@ -1198,6 +1204,23 @@ detection of systems known to misbehave upon accesses
> to that port.
>
> >> Enable IOMMU debugging code (implies `verbose`).
>
> +### dom0-iommu
This is now misplaced, as the file is (meant to be) alphabetically
sorted.
> +> `=
On 08/08/18 13:46, Roger Pau Monne wrote:
> The current balloon code tries to calculate a delta factor for the
> balloon target when running in HVM mode in order to account for memory
> used by the firmware.
>
> This workaround for memory accounting doesn't work properly on a PVH
> Dom0, that has
>>> On 08.08.18 at 13:38, wrote:
> On 08/08/18 11:48, Jan Beulich wrote:
> On 08.08.18 at 12:39, wrote:
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: 08 August 2018 11:11
>>> On 07.08.18 at 17:42, wrote:
> --- a/xen/include/public/hvm/params.h
> +++
The current balloon code tries to calculate a delta factor for the
balloon target when running in HVM mode in order to account for memory
used by the firmware.
This workaround for memory accounting doesn't work properly on a PVH
Dom0, that has a static-max value different from the target value
On 08/08/18 11:48, Jan Beulich wrote:
On 08.08.18 at 12:39, wrote:
>>> From: Jan Beulich [mailto:jbeul...@suse.com]
>>> Sent: 08 August 2018 11:11
>>>
>> On 07.08.18 at 17:42, wrote:
--- a/xen/include/public/hvm/params.h
+++ b/xen/include/public/hvm/params.h
@@ -81,9
> -Original Message-
> From: Andrew Cooper
> Sent: 08 August 2018 12:34
> To: Jan Beulich
> Cc: George Dunlap ; Ian Jackson
> ; Paul Durrant ; Wei Liu
> ; Stefano Stabellini ; xen-
> devel ; Konrad Rzeszutek Wilk
> ; Tim (Xen.org)
> Subject: Re: [PATCH v21 1/2] common: add a new mappable
On 08/08/18 11:55, Jan Beulich wrote:
On 08.08.18 at 12:46, wrote:
>> On 08/08/18 11:43, Jan Beulich wrote:
>> On 08.08.18 at 12:38, wrote:
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 08 August 2018 11:30
>
On 08.08.18 at 11:00, wrote:
>> +int
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 08 August 2018 11:43
> To: Paul Durrant
> Cc: Andrew Cooper ; George Dunlap
> ; Ian Jackson ; Wei Liu
> ; Stefano Stabellini ; xen-
> devel ; Konrad Rzeszutek Wilk
> ; Tim (Xen.org)
> Subject: RE: [PATCH v21 1/2]
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 08 August 2018 11:47
> To: Andrew Cooper ; Paul Durrant
>
> Cc: Wei Liu ; George Dunlap
> ; Ian Jackson ;
> Stefano Stabellini ; xen-devel de...@lists.xenproject.org>; Konrad Rzeszutek Wilk
> ; Tim (Xen.org)
>
>>> On 08.08.18 at 12:46, wrote:
> On 08/08/18 11:43, Jan Beulich wrote:
> On 08.08.18 at 12:38, wrote:
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: 08 August 2018 11:30
>>> On 08.08.18 at 11:00, wrote:
> +int gnttab_get_shared_frame(struct domain *d, unsigned
>>> On 08.08.18 at 12:39, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 08 August 2018 11:11
>>
>> >>> On 07.08.18 at 17:42, wrote:
>> > --- a/xen/include/public/hvm/params.h
>> > +++ b/xen/include/public/hvm/params.h
>> > @@ -81,9 +81,13 @@
>> > #define HVM_PARAM_PAE_ENABLED
>>> On 08.08.18 at 12:10, wrote:
> On 08/08/18 10:00, Paul Durrant wrote:
>> +static int gnttab_get_status_frame_mfn(struct domain *d,
>> + unsigned long idx, mfn_t *mfn)
>> +{
>> +struct grant_table *gt = d->grant_table;
>> +
>> +
On 08/08/18 11:43, Jan Beulich wrote:
On 08.08.18 at 12:38, wrote:
>>> From: Jan Beulich [mailto:jbeul...@suse.com]
>>> Sent: 08 August 2018 11:30
>>>
>> On 08.08.18 at 11:00, wrote:
@@ -3860,6 +3866,47 @@ int mem_sharing_gref_to_gfn(struct
>>> grant_table *gt, grant_ref_t ref,
On 08/08/18 11:19, Paul Durrant wrote:
>
>>> +static inline unsigned int status_to_grant_frames(unsigned int
>> status_frames)
>>> +{
>>> +return DIV_ROUND_UP(status_frames * GRANT_STATUS_PER_PAGE,
>> GRANT_PER_PAGE);
>>> +}
>>> +
>>> /* Check if the page has been paged out, or needs
>>> On 08.08.18 at 12:38, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 08 August 2018 11:30
>>
>> >>> On 08.08.18 at 11:00, wrote:
>> > @@ -3860,6 +3866,47 @@ int mem_sharing_gref_to_gfn(struct
>> grant_table *gt, grant_ref_t ref,
>> > }
>> > #endif
>> >
>> > +/* caller
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 08 August 2018 11:11
> To: Paul Durrant
> Cc: xen-devel
> Subject: Re: [PATCH v3] x86/hvm: remove default ioreq server
>
> >>> On 07.08.18 at 17:42, wrote:
> > My recent patch [1] to qemu-xen-traditional
flight 125798 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125798/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
Tests which
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 08 August 2018 11:30
> To: Paul Durrant
> Cc: Andrew Cooper ; Wei Liu
> ; George Dunlap ; Ian
> Jackson ; Stefano Stabellini
> ; xen-devel ;
> Konrad Rzeszutek Wilk ; Tim (Xen.org)
>
> Subject: Re: [PATCH v21
>>> On 08.08.18 at 11:00, wrote:
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -358,6 +358,12 @@ static inline unsigned int
> grant_to_status_frames(unsigned int grant_frames)
> return DIV_ROUND_UP(grant_frames * GRANT_PER_PAGE,
> GRANT_STATUS_PER_PAGE);
> }
>
>
> -Original Message-
> From: Andrew Cooper
> Sent: 08 August 2018 11:11
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Jan Beulich ; George Dunlap
> ; Ian Jackson ; Konrad
> Rzeszutek Wilk ; Stefano Stabellini
> ; Tim (Xen.org) ; Wei Liu
>
> Subject: Re: [PATCH v21 1/2] common:
On 08/08/2018 01:11 PM, Roger Pau Monné wrote:
On Wed, Aug 08, 2018 at 11:44:28AM +0200, Roger Pau Monné wrote:
I just realized that I've dropped a chunk from my series while
rebasing, could you please try again with the following diff applied
on top of my series?
diff --git
On Wed, Aug 08, 2018 at 11:44:28AM +0200, Roger Pau Monné wrote:
> I just realized that I've dropped a chunk from my series while
> rebasing, could you please try again with the following diff applied
> on top of my series?
>
> diff --git a/xen/drivers/passthrough/x86/iommu.c
>
>>> On 07.08.18 at 17:42, wrote:
> My recent patch [1] to qemu-xen-traditional removes the last use of the
> 'default' ioreq server in Xen. (This is a catch-all ioreq server that is
> used if no explicitly registered I/O range is targetted).
>
> This patch can be applied once that patch is
On 08/08/18 10:00, Paul Durrant wrote:
> diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
> index d9ec711c73..8e623ea08e 100644
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -358,6 +358,12 @@ static inline unsigned int
> grant_to_status_frames(unsigned int
Several people have reported hardware issues (malfunctioning USB
controllers) due to iommu page faults on Intel hardware. Those faults
are caused by missing RMRR (VTd) entries in the ACPI tables. Those can
be worked around on VTd hardware by manually adding RMRR entries on
the command line, this
Introduce a new dom0-iommu=inclusive generic option that supersedes
iommu_inclusive_mapping. The previous behaviour is preserved and the
option should only be enabled by default on Intel hardware.
No functional change intended.
Signed-off-by: Roger Pau Monné
Reviewed-by: Paul Durrant
---
Hello,
The following series implement a workaround for missing RMRR
entries for a PVH Dom0. It's based on the iommu_inclusive_mapping VTd
option.
The PVH workaround identity maps all regions marked as reserved in the
memory map.
Note that this workaround is enabled by default on Intel hardware.
To select the iommu configuration used by Dom0. This option supersedes
iommu=dom0-strict|dom0-passthrough.
No functional change.
Signed-off-by: Roger Pau Monné
Reviewed-by: Paul Durrant
---
Changes since v2:
- Change the style and text used in the xen command line document.
- Don't allow
So it's done before the iommu is initialized. This is required in
order to be able to fetch the MMCFG regions from the domain struct.
No functional change.
Signed-off-by: Roger Pau Monné
---
Changes since v1:
- New in this version.
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
>>> On 07.08.18 at 19:07, wrote:
> This patch adds driver for UART controller present on Amlogic S905 SoC.
> https://dn.odroid.com/S905/DataSheet/S905_Public_Datasheet_V1.1.4.pdf
>
> Signed-off-by: Amit Singh Tomar
> ---
> xen/drivers/char/Kconfig | 8 ++
> xen/drivers/char/Makefile
>>> On 08.08.18 at 10:51, wrote:
> On Wed, Aug 08, 2018 at 09:43:39AM +0100, Paul Durrant wrote:
>> > -Original Message-
>> > From: Roger Pau Monne
>> > Sent: 08 August 2018 09:08
>> > To: berca...@amazon.com
>> > Cc: Paul Durrant ; xen-devel > > de...@lists.xenproject.org>; David
On 08/08/18 10:00, Paul Durrant wrote:
> A previous patch added support for priv-mapping guest resources directly
> (rather than having to foreign-map, which requires P2M modification for
> HVM guests).
>
> This patch makes use of the new API to seed the guest grant table unless
> the underlying
> I'd like to ask about Xen's memory scrubbing, to better understand the
> changes made to it in recent versions of Xen (4.10+) and the community
> understanding of requirements on it.
That looks good. Will add
Lars
From: Christopher Clark
Date: Wednesday, 8 August 2018 at 01:28
To: Lars Kurth
>>> On 08.08.18 at 11:53, wrote:
> I've lost a chunk here during one of the rebases, so the following
> diff should be added to the patch in order to create maps if the iommu
> page tables are shared:
>
> diff --git a/xen/drivers/passthrough/x86/iommu.c
> b/xen/drivers/passthrough/x86/iommu.c
>
>>> On 08.08.18 at 10:25, wrote:
> On Tue, Aug 07, 2018 at 10:45:32AM -0600, Tamas K Lengyel wrote:
>> On Tue, Aug 7, 2018 at 10:04 AM Tamas K Lengyel
>> wrote:
>> (XEN) [VT-D]iommu.c:919: iommu_fault_status: Fault Overflow
>> (XEN) [VT-D]iommu.c:921: iommu_fault_status: Primary Pending Fault
>>
On Tue, Aug 07, 2018 at 04:02:43PM +0200, Roger Pau Monne wrote:
> @@ -149,36 +204,9 @@ void __hwdom_init arch_iommu_hwdom_init(struct domain *d)
> for ( i = 0; i < top; i++ )
> {
> unsigned long pfn = pdx_to_pfn(i);
> -bool map;
> int rc;
>
> -/*
> -
On Wed, Aug 08, 2018 at 11:54:40AM +0300, berca...@amazon.com wrote:
> On 08/08/2018 11:51 AM, Roger Pau Monné wrote:
> > On Wed, Aug 08, 2018 at 09:43:39AM +0100, Paul Durrant wrote:
> > > > -Original Message-
> > > > From: Roger Pau Monne
> > > > Sent: 08 August 2018 09:08
> > > > To:
>>> On 07.08.18 at 18:19, wrote:
> On Tue, Aug 07, 2018 at 05:33:35AM -0600, Jan Beulich wrote:
>> >>> On 07.08.18 at 12:00, wrote:
>> > This function is common to both PV and HVM. Move it to x86 common
>> > code.
>>
>> I'm afraid that's the wrong way round: p2m_memory_type_changed()
>> is HVM
These patches are the patches from my original resource mapping series
that did not make it into 4.11.
Paul Durrant (2):
common: add a new mappable resource type: XENMEM_resource_grant_table
tools/libxenctrl: use new xenforeignmemory API to seed grant table
tools/libxc/include/xc_dom.h
This patch allows grant table frames to be mapped using the
XENMEM_acquire_resource memory op.
NOTE: This patch expands the on-stack mfn_list array in acquire_resource()
but it is still small enough to remain on-stack.
Signed-off-by: Paul Durrant
---
Cc: Jan Beulich
Cc: Andrew Cooper
A previous patch added support for priv-mapping guest resources directly
(rather than having to foreign-map, which requires P2M modification for
HVM guests).
This patch makes use of the new API to seed the guest grant table unless
the underlying infrastructure (i.e. privcmd) doesn't support it,
On 08/08/2018 11:51 AM, Roger Pau Monné wrote:
On Wed, Aug 08, 2018 at 09:43:39AM +0100, Paul Durrant wrote:
-Original Message-
From: Roger Pau Monne
Sent: 08 August 2018 09:08
To: berca...@amazon.com
Cc: Paul Durrant ; xen-devel ; David Woodhouse ;
Jan Beulich ; Belgun, Adrian
On Wed, Aug 08, 2018 at 09:43:39AM +0100, Paul Durrant wrote:
> > -Original Message-
> > From: Roger Pau Monne
> > Sent: 08 August 2018 09:08
> > To: berca...@amazon.com
> > Cc: Paul Durrant ; xen-devel > de...@lists.xenproject.org>; David Woodhouse ;
> > Jan Beulich ; Belgun, Adrian
> >
> -Original Message-
> From: Roger Pau Monne
> Sent: 08 August 2018 09:08
> To: berca...@amazon.com
> Cc: Paul Durrant ; xen-devel de...@lists.xenproject.org>; David Woodhouse ;
> Jan Beulich ; Belgun, Adrian
> Subject: Re: [Xen-devel] PVH dom0 creation fails - the system freezes
>
> On
On 08/08/2018 11:08 AM, Roger Pau Monné wrote:
On Wed, Aug 08, 2018 at 10:46:40AM +0300, berca...@amazon.com wrote:
On 08/02/2018 04:55 PM, Roger Pau Monné wrote:
Please try to avoid top posting.
On Thu, Aug 02, 2018 at 11:36:26AM +, Bercaru, Gabriel wrote:
I applied the match mentioned,
On Tue, Aug 07, 2018 at 05:56:38PM +0200, Juergen Gross wrote:
> On 07/08/18 16:14, Roger Pau Monné wrote:
> > On Tue, Aug 07, 2018 at 08:31:31AM +0200, Juergen Gross wrote:
> >> On 06/08/18 18:16, Roger Pau Monné wrote:
> >>> On Mon, Aug 06, 2018 at 01:34:01PM +0200, Juergen Gross wrote:
>
flight 75053 distros-debian-squeeze real [real]
http://osstest.xensource.com/osstest/logs/75053/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-i386-squeeze-netboot-pygrub 10 debian-di-install fail like
75033
On Tue, Aug 07, 2018 at 10:45:32AM -0600, Tamas K Lengyel wrote:
> On Tue, Aug 7, 2018 at 10:04 AM Tamas K Lengyel
> wrote:
> (XEN) [VT-D]iommu.c:919: iommu_fault_status: Fault Overflow
> (XEN) [VT-D]iommu.c:921: iommu_fault_status: Primary Pending Fault
> (XEN) [VT-D]DMAR:[DMA Read] Request
On Wed, Aug 08, 2018 at 10:46:40AM +0300, berca...@amazon.com wrote:
> On 08/02/2018 04:55 PM, Roger Pau Monné wrote:
> > Please try to avoid top posting.
> >
> > On Thu, Aug 02, 2018 at 11:36:26AM +, Bercaru, Gabriel wrote:
> > > I applied the match mentioned, but the system fails to boot.
1 - 100 of 104 matches
Mail list logo
