flight 140951 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140951/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 140282
test-amd64-amd64-
flight 140942 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140942/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 140778
Tests which did not
Several public headers of the hypervisor contain structures with
variable length arrays. In order to be usable with different compilers
those definitions are depending on the compiler type and the standard
supported by the compiler.
In order to avoid open coding the different variants in each head
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-pair
testid xen-boot/src_host
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree:
flight 140939 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140939/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 139876
test-amd64-amd64-x
flight 140949 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140949/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 17f8c9e97d770c74f84194576bcd97322fbed21e
baseline version:
ovmf 47f167f47e8e4b637411f
flight 140941 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140941/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 139910
build-amd64
flight 140943 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140943/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd f2d1759c50fb28fa0e2e1bd65e7bd49ee7ed4693
baseline version:
freebsd 32e0aaee879
On 02/09/2019 18:41, Andrew Cooper wrote:
> This logic is all terrible. This series should resolve the reported build
> failure, but definitely isn't a "proper" fix.
>
> Andrew Cooper (2):
> tools/shim: Fix race condition creating linkfarm.stamp
> tools/shim: Apply more duct tape to the linkf
flight 140952 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140952/
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 1
flight 140935 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140935/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 6 kernel-build fail REGR. vs. 129313
test-amd64-amd64-xl-
flight 140937 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140937/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 139698
build-amd64-xsm
I noticed that RDTSC emulation got turned on for a VM after a
suspend/host-reboot/resume cycle.
Xen currently expects an exact match between host CPU and saved guest CPU
frequency in KHz, otherwise it turns on RDTSC emulation if the CPU doesn't
support TSC scaling.
An exact match would require ~0.
On a Intel(R) Xeon(R) CPU E5-2697 v3 @ 2.60GHz the host frequency drifts:
```
(XEN) [6.607693] Detected 2600.004 MHz processor.
(XEN) [ 2674.213081] dom1(hvm): mode=0,ofs=0xfffee6f70b7faa48,khz=2600018,inc=3
(XEN) [ 2674.213087] dom2(hvm): mode=0,ofs=0xfffee6fd499835c0,khz=2600018,inc=2
```
Th
On 02/09/2019, 16:49, "Ian Jackson" wrote:
Lars Kurth writes ("Re: [Xen-devel] [RFC] Code of Conduct"):
> I attached a redline version of both the original (based on the LF events
CoC) and a redline version based on the covenant given the constraints we
agreed. Aka
> [1] Xen CoC
Andrew Cooper writes ("[PATCH 2/2] tools/shim: Apply more duct tape to the
linkfarm logic"):
> Sander reported a build failure which manifests as `make; make install`
> failing with:
Acked-by: Ian Jackson
> Update the linkfarm logic to not regenerate itself when build artefacts
> appear. This
Andrew Cooper writes ("[PATCH 1/2] tools/shim: Fix race condition creating
linkfarm.stamp"):
> In the case the while loop gets interrupted, the target musn't appear as
> up-to-date. The mov $X.tmp $X must be the last action of the rule.
>
> Signed-off-by: Andrew Cooper
Acked-by: Ian Jackson
This logic is all terrible. This series should resolve the reported build
failure, but definitely isn't a "proper" fix.
Andrew Cooper (2):
tools/shim: Fix race condition creating linkfarm.stamp
tools/shim: Apply more duct tape to the linkfarm logic
tools/firmware/xen-dir/Makefile | 27 +
Sander reported a build failure which manifests as `make; make install`
failing with:
/cross-install -m0644 -p xen-dir/xen-shim
//usr/local/lib/xen/boot/xen-shim
install: cannot stat 'xen-dir/xen-shim': No such file or directory
make[4]: *** [Makefile:52: install] Error 1
make[4]: Leaving
In the case the while loop gets interrupted, the target musn't appear as
up-to-date. The mov $X.tmp $X must be the last action of the rule.
Signed-off-by: Andrew Cooper
---
CC: Ian Jackson
CC: Wei Liu
CC: Jan Beulich
CC: Roger Pau Monné
CC: George Dunlap
CC: Sander Eikelenboom
---
tools/f
On Fri, Aug 30, 2019 at 07:40:42PM -0700, Stefano Stabellini wrote:
> + Juergen, Boris
>
> On Fri, 30 Aug 2019, Christoph Hellwig wrote:
> > Can we take a step back and figure out what we want to do here?
> >
> > AFAICS this function allocates memory for the swiotlb-xen buffer,
> > and that means
flight 140946 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140946/
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 1
Lars Kurth writes ("Re: [Xen-devel] [RFC] Code of Conduct"):
> I attached a redline version of both the original (based on the LF events
> CoC) and a redline version based on the covenant given the constraints we
> agreed. Aka
> [1] Xen CoC Contributor Covenant baseline (redline).pdf
> [2] Xen C
flight 140932 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140932/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 18 guest-localmigrate/x10 fail in 140905 REGR. vs.
140282
Tests whic
On 02.09.2019 17:13, Paul Durrant wrote:
>> From: Jan Beulich
>> Sent: 02 September 2019 15:54
>>
>> On 02.09.2019 16:21, Paul Durrant wrote:
>>> Yes, the hap part stays put. The 'oos_off' part moves to x86 and arm can
>>> be left alone because it already rejects flags != (hvm | hap).
>>
>> But it
Don't allow the hardware domain write access the PCI config space of
devices marked as read-only.
Signed-off-by: Roger Pau Monné
---
Changes since v1:
- Change the approach and allow full read access, while limiting
write access to devices marked RO.
---
xen/drivers/vpci/vpci.c | 16
flight 140930 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140930/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-examine 8 reboot fail REGR. vs. 133580
test-amd64-i386-xl-
> -Original Message-
> From: Jan Beulich
> Sent: 02 September 2019 15:54
> To: Paul Durrant
> Cc: Andrew Cooper ; George Dunlap
> ; Roger Pau
> Monne ; xen-devel@lists.xenproject.org; Tim (Xen.org)
> ; WeiLiu
>
> Subject: Re: [PATCH v7 1/6] x86/domain: remove the 'oos_off' flag
>
> On
On 02.09.2019 16:50, Paul Durrant wrote:
> The flag is not needed since the domain 'options' can now be tested
> directly.
>
> Signed-off-by: Paul Durrant
In principle
Reviewed-by: Jan Beulich
but
Julien, Stefano,
I'd like to to ask for an explicit opinion of at least one of you
regarding the
On 02.09.2019 16:36, Alexandru Stefan ISAILA wrote:
> Is there a way we can go on with this issue?
As long as Andrew wouldn't change his mind, all I can suggest is
that you avoid making your change dependent upon mine. If I (again)
end up reviewing it, I'll have to keep in mind to judge on it usin
On 02.09.2019 16:23, Roger Pau Monné wrote:
> So the problem I found, and that I was trying to address with this
> patch is that a PVH dom0 on AMD hardware finds the iommus by scanning
> the PCI bus, and a Linux dom0 seems to immediately turn off the MSI
> enable control bit on any devices it find
On 02.09.2019 16:21, Paul Durrant wrote:
> Yes, the hap part stays put. The 'oos_off' part moves to x86 and arm can
> be left alone because it already rejects flags != (hvm | hap).
But it may better reject the OOS flag _despite_ having only HVM guests,
as long as there's no shadow mode there in th
On 19.08.2019 20:26, Andrew Cooper wrote:
> Future changes are going to want to use cpu_bug_* in a mannor similar to
> Linux. Introduce one bug word, and generalise the calculation of
> NCAPINTS.
>
> Signed-off-by: Andrew Cooper
Pretty hesitantly
Acked-by: Jan Beulich
...and hence the ability to disable IOMMU mappings, and control EPT
sharing.
This patch introduces a new 'libxl_passthrough' enumeration into
libxl_domain_create_info. The value will be set by xl either when it parses
a new 'passthrough' option in xl.cfg, or implicitly if there is passthrough
hard
...rather than testing the global iommu_enabled flag and ops pointer.
Now that there is a per-domain flag indicating whether the domain is
permitted to use the IOMMU (which determines whether the ops pointer will
be set), many tests of the global iommu_enabled flag and ops pointer can
be translate
On 02.09.2019 16:15, Andrew Cooper wrote:
> On 29/08/2019 13:56, Jan Beulich wrote:
>> On 19.08.2019 20:26, Andrew Cooper wrote:
>>> AMD Pre-Fam17h CPUs "optimise" {F,}X{SAVE,RSTOR} by not saving/restoring
>>> FOP/FIP/FDP if an x87 exception isn't pending. This causes an information
>>> leak, CVE-
These are revisions of the remaining uncommitted patches from my
previous series:
https://lists.xenproject.org/archives/html/xen-devel/2019-08/msg01737.html
Paul Durrant (6):
x86/domain: remove the 'oos_off' flag
domain: introduce XEN_DOMCTL_CDF_iommu flag
use is_iommu_enabled() where appro
Now that there is a per-domain IOMMU-enable flag, which should be set if
any device is going to be passed through, stop deferring page table
construction until the assignment is done. Also don't tear down the tables
again when the last device is de-assigned; defer that task until domain
destruction
The flag is not needed since the domain 'options' can now be tested
directly.
Signed-off-by: Paul Durrant
---
Cc: Jan Beulich
Cc: Tim Deegan
Cc: George Dunlap
Cc: Andrew Cooper
Cc: Wei Liu
Cc: "Roger Pau Monné"
v8:
- Move setting CDF_oos_off into x86 arch_sanitise_domain_config()
- Dropp
This patch introduces a common domain creation flag to determine whether
the domain is permitted to make use of the IOMMU. Currently the flag is
always set (for both dom0 and domU) if the IOMMU is globally enabled
(i.e. iommu_enabled == 1). sanitise_domain_config() is modified to reject
the flag if
Thes macros really ought to live in the common xen/iommu.h header rather
then being distributed amongst architecture specific iommu headers and
xen/sched.h. This patch moves them there.
NOTE: Disabling 'sharept' in the command line iommu options should really
be hard error on ARM (as opposed
On 27.08.2019 11:26, Jan Beulich wrote:
> On 20.08.2019 22:11, Andrew Cooper wrote:
>> On 30/07/2019 15:54, Jan Beulich wrote:
@@ -622,14 +622,22 @@ static void *hvmemul_map_linear_addr(
}
if ( p2mt == p2m_ioreq_server )
- {
On Mon, Sep 02, 2019 at 04:15:02PM +0200, Jan Beulich wrote:
> On 02.09.2019 15:58, Roger Pau Monné wrote:
> > On Mon, Sep 02, 2019 at 01:58:07PM +0200, Jan Beulich wrote:
> >> On 02.09.2019 13:30, Roger Pau Monne wrote:
> >>> Don't allow the hardware domain to access the PCI config space of
> >>>
> -Original Message-
> From: Jan Beulich
> Sent: 02 September 2019 15:12
> To: Paul Durrant
> Cc: Andrew Cooper ; George Dunlap
> ; Roger Pau
> Monne ; xen-devel@lists.xenproject.org; Tim (Xen.org)
> ; WeiLiu
>
> Subject: Re: [PATCH v7 1/6] x86/domain: remove the 'oos_off' flag
>
> On
On 29/08/2019 13:56, Jan Beulich wrote:
> On 19.08.2019 20:26, Andrew Cooper wrote:
>> AMD Pre-Fam17h CPUs "optimise" {F,}X{SAVE,RSTOR} by not saving/restoring
>> FOP/FIP/FDP if an x87 exception isn't pending. This causes an information
>> leak, CVE-2006-1056, and worked around by several OSes, in
On 02.09.2019 15:58, Roger Pau Monné wrote:
> On Mon, Sep 02, 2019 at 01:58:07PM +0200, Jan Beulich wrote:
>> On 02.09.2019 13:30, Roger Pau Monne wrote:
>>> Don't allow the hardware domain to access the PCI config space of
>>> devices not assigned to it. Ie: the config space of iommu devices
>>>
On 02.09.2019 15:59, Paul Durrant wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 02 September 2019 14:46
>> To: Paul Durrant
>> Cc: Andrew Cooper ; George Dunlap
>> ; Roger Pau
>> Monne ; xen-devel@lists.xenproject.org; Tim (Xen.org)
>> ; WeiLiu
>>
>> Subject: Re: [PATCH v7
On 02.09.2019 15:52, David Woodhouse wrote:
> On Mon, 2019-09-02 at 15:47 +0200, Jan Beulich wrote:
>> On 02.09.2019 14:51, David Woodhouse wrote:
>>> On Mon, 2019-09-02 at 09:44 +0200, Jan Beulich wrote:
Right, just one pair should survive. And seeing how things work before
this series I
> -Original Message-
> From: Jan Beulich
> Sent: 02 September 2019 14:46
> To: Paul Durrant
> Cc: Andrew Cooper ; George Dunlap
> ; Roger Pau
> Monne ; xen-devel@lists.xenproject.org; Tim (Xen.org)
> ; WeiLiu
>
> Subject: Re: [PATCH v7 1/6] x86/domain: remove the 'oos_off' flag
>
> On
On Mon, Sep 02, 2019 at 01:58:07PM +0200, Jan Beulich wrote:
> On 02.09.2019 13:30, Roger Pau Monne wrote:
> > Don't allow the hardware domain to access the PCI config space of
> > devices not assigned to it. Ie: the config space of iommu devices
> > in use by Xen should not be accessible to the ha
On 02.09.2019 14:14, Andrew Cooper wrote:
> --- a/xen/arch/x86/acpi/power.c
> +++ b/xen/arch/x86/acpi/power.c
> @@ -33,8 +33,32 @@
>
> uint32_t system_reset_counter = 1;
>
> -static char __initdata opt_acpi_sleep[20];
> -string_param("acpi_sleep", opt_acpi_sleep);
> +static int __init parse_ac
On Mon, 2019-09-02 at 15:47 +0200, Jan Beulich wrote:
> On 02.09.2019 14:51, David Woodhouse wrote:
> > On Mon, 2019-09-02 at 09:44 +0200, Jan Beulich wrote:
> > > Right, just one pair should survive. And seeing how things work before
> > > this series I think it indeed should be linker script symb
On 02.09.2019 14:11, Andrew Cooper wrote:
> sleep_states[] is a write-only array, and despite the loop logic, the printed
> message is consistently "ACPI sleep modes: S3". Drop it all.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
Albeit FTR I'm not convinced removing the log message
On 02.09.2019 14:51, David Woodhouse wrote:
> On Mon, 2019-09-02 at 09:44 +0200, Jan Beulich wrote:
>> Right, just one pair should survive. And seeing how things work before
>> this series I think it indeed should be linker script symbols only.
>> And then the ALIGN() ahead of the "start" ones shou
On 02.09.2019 15:06, Paul Durrant wrote:
>> From: Jan Beulich
>> Sent: 02 September 2019 13:34
>>
>> On 30.08.2019 10:29, Paul Durrant wrote:
>>> --- a/xen/common/domain.c
>>> +++ b/xen/common/domain.c
>>> @@ -313,11 +313,19 @@ static int sanitise_domain_config(struct
>>> xen_domctl_createdomain
Now that the Xen special cases are gone nothing worth mentioning is
left in the arm64 file, so switch to use the
asm-generic version instead.
Signed-off-by: Christoph Hellwig
Acked-by: Will Deacon
Reviewed-by: Stefano Stabellini
---
arch/arm64/include/asm/Kbuild| 1 +
arch/arm64/incl
No need for a no-op wrapper.
Signed-off-by: Christoph Hellwig
Reviewed-by: Stefano Stabellini
---
drivers/xen/swiotlb-xen.c | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 95911ff9c11c..384304a77020
The only thing left of page-coherent.h is two functions implemented by
the architecture for non-coherent DMA support that are never called for
fully coherent architectures. Just move the prototypes for those to
swiotlb-xen.h instead.
Signed-off-by: Christoph Hellwig
Reviewed-by: Stefano Stabelli
Now that we know we always have the dma-noncoherent.h helpers available
if we are on an architecture with support for non-coherent devices,
we can just call them directly, and remove the calls to the dma-direct
routines, including the fact that we call the dma_direct_map_page
routines but ignore th
> -Original Message-
> From: Jan Beulich
> Sent: 02 September 2019 13:34
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
> ; Roger Pau Monne
> ; George Dunlap ; Tim
> (Xen.org) ; Wei Liu
>
> Subject: Re: [PATCH v7 1/6] x86/domain: remove the 'oos_off' flag
>
> O
xen_dma_map_page uses a different and more complicated check for foreign
pages than the other three cache maintainance helpers. Switch it to the
simpler pfn_valid method a well, and document the scheme with a single
improved comment in xen_dma_map_page.
Signed-off-by: Christoph Hellwig
Reviewed-
x86 currently calls alloc_pages, but using dma-direct works as well
there, with the added benefit of using the CMA pool if available.
The biggest advantage is of course to remove a pointless bit of
architecture specific code.
Signed-off-by: Christoph Hellwig
Reviewed-by: Stefano Stabellini
---
Calculate the required operation in the caller, and pass it directly
instead of recalculating it for each page, and use simple arithmetics
to get from the physical address to Xen page size aligned chunks.
Signed-off-by: Christoph Hellwig
Reviewed-by: Stefano Stabellini
---
arch/arm/xen/mm.c | 6
These routines are only used by swiotlb-xen, which cannot be modular.
Signed-off-by: Christoph Hellwig
Reviewed-by: Stefano Stabellini
---
arch/arm/xen/mm.c | 2 --
arch/x86/xen/mmu_pv.c | 2 --
2 files changed, 4 deletions(-)
diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index 11d5ad
Shared the duplicate arm/arm64 code in include/xen/arm/page-coherent.h.
Signed-off-by: Christoph Hellwig
---
arch/arm/include/asm/xen/page-coherent.h | 75
arch/arm64/include/asm/xen/page-coherent.h | 75
include/xen/arm/page-coherent.h| 80
arm and arm64 can just use xen_swiotlb_dma_ops directly like x86, no
need for a pointer indirection.
Signed-off-by: Christoph Hellwig
Reviewed-by: Julien Grall
Reviewed-by: Stefano Stabellini
---
arch/arm/mm/dma-mapping.c| 3 ++-
arch/arm/xen/mm.c| 4
arch/arm64/mm/dma-map
There is no need to wrap the common version, just wire them up directly.
Signed-off-by: Christoph Hellwig
Reviewed-by: Stefano Stabellini
---
drivers/xen/swiotlb-xen.c | 29 ++---
1 file changed, 2 insertions(+), 27 deletions(-)
diff --git a/drivers/xen/swiotlb-xen.c b/
Copy the arm64 code that uses the dma-direct/swiotlb helpers for DMA
on-coherent devices.
Signed-off-by: Christoph Hellwig
---
arch/arm/include/asm/device.h| 3 -
arch/arm/include/asm/xen/page-coherent.h | 72 +---
arch/arm/mm/dma-mapping.c| 8 +-
Hi Xen maintainers and friends,
please take a look at this series that cleans up the parts of swiotlb-xen
that deal with non-coherent caches.
Boris and Juergen, can you take a look at patch 8, which touches x86
a as well?
Changes since v2:
- further dma_cache_maint improvements
- split the pre
Use the dma-noncoherent dev_is_dma_coherent helper instead of the home
grown variant. Note that both are always initialized to the same
value in arch_setup_dma_ops.
Signed-off-by: Christoph Hellwig
Reviewed-by: Julien Grall
Reviewed-by: Stefano Stabellini
---
arch/arm/include/asm/dma-mapping.
On Mon, 2019-09-02 at 09:44 +0200, Jan Beulich wrote:
> Right, just one pair should survive. And seeing how things work before
> this series I think it indeed should be linker script symbols only.
> And then the ALIGN() ahead of the "start" ones should stay, but there's
> no need for one on the "en
On 30.08.2019 10:29, Paul Durrant wrote:
> The flag is not needed since the domain 'options' can now be tested
> directly.
>
> Signed-off-by: Paul Durrant
> Reviewed-by: Jan Beulich
> ---
> Cc: Tim Deegan
> Cc: George Dunlap
> Cc: Andrew Cooper
> Cc: Wei Liu
> Cc: "Roger Pau Monné"
>
> v3:
Perform parsing in a custom_param, rather than stashing the content in a
string and parsing in an initcall. Adjust the parsing to conform to current
standards.
No practical change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
The reason that flags is pull
sleep_states[] is a write-only array, and despite the loop logic, the printed
message is consistently "ACPI sleep modes: S3". Drop it all.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/acpi/power.c | 15 ---
1 file changed, 15 d
Perform parsing in a custom_param, rather than stashing the content in a
string and parsing in an initcall. Adjust the parsing to conform to current
standards.
No practical change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
The reason that flags is pull
> -Original Message-
> From: Jan Beulich
> Sent: 02 September 2019 12:10
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
> ; Roger Pau Monne
> ; Wei Liu
> Subject: Ping: [PATCH 1/6] x86emul: generalize wbinvd() hook
>
> On 01.07.2019 13:55, Jan Beulich wrote:
> >
On 02.09.2019 13:30, Roger Pau Monne wrote:
> Don't allow the hardware domain to access the PCI config space of
> devices not assigned to it. Ie: the config space of iommu devices
> in use by Xen should not be accessible to the hardware domain.
Well, I agree with what you say above, but the code c
Ahh, I see that I definitely should have made the patch notes more
descriptive. I could be wrong but I was under the impression that casting
the data type of wchar_t to efi_char16_t (unsigned short) was acceptable as
I've seen it in similar patches before, see here
https://lkml.org/lkml/2019/7/21/1
On 02.09.2019 13:23, Alexandru Stefan ISAILA wrote:
> On 29.08.2019 18:04, Jan Beulich wrote:
>> On 22.08.2019 16:02, Alexandru Stefan ISAILA wrote:
>>> This patch adds access control for NPT mode.
>>>
>>> The access rights are stored in the NPT p2m table 56:53.
>>
>> Why starting from bit 53? I ca
On 02.09.19 13:06, Jan Beulich wrote:
On 27.08.2019 14:40, Juergen Gross wrote:
On 27.08.19 14:37, Andrew Cooper wrote:
On 27/08/2019 11:59, Juergen Gross wrote:
+static void *
+sched_idle_alloc_vdata(const struct scheduler *ops, struct vcpu *v,
+ void *dd)
+{
+/* Any
Don't allow the hardware domain to access the PCI config space of
devices not assigned to it. Ie: the config space of iommu devices
in use by Xen should not be accessible to the hardware domain.
Note that access from the hardware domain to config space regions
where Xen hasn't detected any devices
On 29.08.2019 18:04, Jan Beulich wrote:
> On 22.08.2019 16:02, Alexandru Stefan ISAILA wrote:
>> This patch adds access control for NPT mode.
>>
>> The access rights are stored in the NPT p2m table 56:53.
>
> Why starting from bit 53? I can't seem to find any use of bit 52.
There is a comment i
On 01.07.2019 13:55, Jan Beulich wrote:
> The hook is already in use for other purposes, and emulating e.g.
> CLFLUSH by issuing WBINVD is, well, not very nice. Rename the hook and
> add parameters. Use lighter weight flushing insns when possible in
> hvmemul_cache_op().
>
> hvmemul_cache_op() tre
On 27.08.2019 14:40, Juergen Gross wrote:
> On 27.08.19 14:37, Andrew Cooper wrote:
>> On 27/08/2019 11:59, Juergen Gross wrote:
>>> +static void *
>>> +sched_idle_alloc_vdata(const struct scheduler *ops, struct vcpu *v,
>>> + void *dd)
>>> +{
>>> +/* Any non-NULL pointer
On 02.09.2019 12:42, Andrew Cooper wrote:
> On 30/08/2019 14:41, Jan Beulich wrote:
>> In order for "acpi_sleep=s3_mode" to have any effect, we should record
>> the video mode we switched to during boot. Since right now there's mode
>> setting code for VESA modes only in the resume case, record the
On 02.09.2019 12:37, Andrew Cooper wrote:
> On 30/08/2019 14:33, Jan Beulich wrote:
>> When disabling SMT at runtime, secondary threads should no longer be
>> candidates for bringing back up in response to _PUD ACPI events. Purge
>> them from the tracking array.
>
> I think I agree in principle, b
On 30/08/2019 14:42, Jan Beulich wrote:
> We really don't need them to be any wider.
>
> Also remove the C level declaration (and hence also the GLOBAL) of
> video_mode altogether; it's used in assembly code only.
>
> Suggested-by: Andrew Cooper
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew C
On 30/08/2019 14:41, Jan Beulich wrote:
> To "compensate" for the code size growth by an earlier change:
> - drop "trampoline" labels (in almost all cases the target label is
> reachable with an 8-bit-displacement branch anyway, and a single 16-
> bit-displacement branch is still better than a
On 30/08/2019 14:41, Jan Beulich wrote:
> In order for "acpi_sleep=s3_mode" to have any effect, we should record
> the video mode we switched to during boot. Since right now there's mode
> setting code for VESA modes only in the resume case, record the mode
> just in that one case.
>
> Signed-off-b
On 30/08/2019 14:33, Jan Beulich wrote:
> When disabling SMT at runtime, secondary threads should no longer be
> candidates for bringing back up in response to _PUD ACPI events. Purge
> them from the tracking array.
I think I agree in principle, but what are _PUD events? I can't find
any referenc
On 30/08/2019 14:33, Jan Beulich wrote:
> First and foremost make timer_softirq_action() avoid growing the heap
> if its new size can't be stored without truncation. 64k entries is a
> lot, and I don't think we're at risk of actually running into the issue,
> but I also think it's better not to all
On Mon, Sep 2, 2019 at 6:34 PM, Paul Durrant
wrote:
-Original Message-
From: Steven Haigh
Sent: 02 September 2019 09:32
To: Paul Durrant
Cc: Andrew Cooper ; Andreas Kinzler
; xen-
de...@lists.xenproject.org
Subject: Re: Windows HVM no longer boots with AMD Ryzen 3700X (and
flight 140924 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140924/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 16 guest-localmigrate fail in 140894 REGR. vs.
139910
Tests which are f
On 09.08.2019 16:57, Juergen Gross wrote:
> --- a/xen/common/schedule.c
> +++ b/xen/common/schedule.c
> @@ -87,13 +87,13 @@ sched_idle_switch_sched(struct scheduler *new_ops,
> unsigned int cpu,
> }
>
> static int
> -sched_idle_cpu_pick(const struct scheduler *ops, struct vcpu *v)
> +sched_idl
On 21.08.2019 18:35, David Woodhouse wrote:
> From: David Woodhouse
>
> Where booted from EFI or with no-real-mode, there is no need to stomp
> on low memory with the 16-boot code. Instead, just go straight to
> trampoline_protmode_entry() at its physical location within the Xen
> image, having a
On 02/09/2019, 09:08, "Jan Beulich" wrote:
On 30.08.2019 22:09, Lars Kurth wrote:
> Specifically:
> * Move check until after the MAINTAINERS file has been read
> * Add get_xen_maintainers_file_version() for check
> * Remove top_of_tree as not needed any more
> * Faiul w
Rather than using static int max_dma_bits, this
can be coverted to use as macro.
Signed-off-by: Souptick Joarder
Reviewed-by: Juergen Gross
---
drivers/xen/swiotlb-xen.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.
> -Original Message-
> From: Steven Haigh
> Sent: 02 September 2019 09:32
> To: Paul Durrant
> Cc: Andrew Cooper ; Andreas Kinzler
> ; xen-
> de...@lists.xenproject.org
> Subject: Re: Windows HVM no longer boots with AMD Ryzen 3700X (and 3900X)
>
> On 2019-09-02 18:25, Steven Haigh wrot
On 2019-09-02 18:25, Steven Haigh wrote:
On 2019-09-02 18:20, Paul Durrant wrote:
-Original Message-
From: Steven Haigh
Sent: 02 September 2019 09:09
To: Paul Durrant
Cc: Andreas Kinzler ; Andrew Cooper
; xen-
de...@lists.xenproject.org
Subject: Re: Windows HVM no longer boots with A
On 2019-09-02 18:20, Paul Durrant wrote:
-Original Message-
From: Steven Haigh
Sent: 02 September 2019 09:09
To: Paul Durrant
Cc: Andreas Kinzler ; Andrew Cooper
; xen-
de...@lists.xenproject.org
Subject: Re: Windows HVM no longer boots with AMD Ryzen 3700X (and
3900X)
On 2019-09-0
1 - 100 of 112 matches
Mail list logo
