Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-5.14-rc1-tag
xen: branch for v5.14-rc1
It contains only two minor patches this time: one cleanup patch and
one patch refreshing a Xen header.
Thanks.
Juergen
drivers/xen/pcpu.c
Make the go build use APPEND_{C/LD}FLAGS when necessary, just like
other parts of the build.
Reported-by: Ting-Wei Lan
Signed-off-by: Roger Pau Monné
---
Note sure if it's the best way to add the appended flags, I'm not
familiar with the go build system. In any case this fixes the build
when req
Ping?
On 08.06.21 07:58, Juergen Gross wrote:
Set some limits for xenstored in order to avoid it being killed by
OOM killer, or to run out of file descriptors.
Changes in V2:
- split into 2 patches
- set limits from start script
Juergen Gross (2):
tools/xenstore: set oom score for xenstore
On 06.07.2021 15:20, Julien Grall wrote:
> From: Julien Grall
>
> Commit 918b8842a852 ("arm64: Change type of hsr, cpsr, spsr_el1 to
> uint64_t") updated the size of the structure vcpu_guest_core_regs and
> indirectly vcpu_guest_context.
>
> On Arm, the two structures are only accessible to t
On 07.07.2021 03:02, Igor Druzhinin wrote:
> Current unit8_t for pirq argument in this interface is too restrictive
> causing failures on modern hardware with lots of GSIs. That extends down to
> XEN_DOMCTL_irq_permission ABI structure where it needs to be fixed up
> as well. Internal Xen structure
> 918b8842a852 changed CPSR and SPSR to be stored as 64bit values.
>
> This is fixing the print size in some tools to use 64bit type.
>
> Fixes: 918b8842a852 ("arm64: Change type of hsr, cpsr, spsr_el1 to
> uint64_t")
Thanks Bertrand.
> Signed-off-by: Bertrand Marquis
Reviewed-by: Michal Orzel
On 07.07.2021 04:32, Rroach wrote:
> After patching it, this works fine and UBSAN dose not have any error report
> about it.
Which I'm surprised about, because in Andrew's suggestion (sorry,
need to reproduce it manually, because quoting your HTML mail is
rendering unreadable results, as you can
flight 163385 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163385/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 163326
build-arm64-
On 7 Jul 2021, at 02:02, Igor Druzhinin
mailto:igor.druzhi...@citrix.com>> wrote:
Current unit8_t for pirq argument in this interface is too restrictive
causing failures on modern hardware with lots of GSIs. That extends down to
XEN_DOMCTL_irq_permission ABI structure where it needs to be fixed
flight 163382 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163382/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
flight 163369 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163369/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-freebsd11-amd64 13 guest-startfail REGR. vs. 163321
test-amd64-amd64-
Xen frontends shouldn't BUG() in case of illegal data received from
their backends. So replace the BUG_ON()s when reading illegal data from
the ring page with negative return values.
Signed-off-by: Juergen Gross
---
V2:
- drop BUG_ON() (Christophe Leroy, Greg Kroah-Hartmann)
- replace WARN_ONCE()
On 07/07/2021 08:46, Jan Beulich wrote:
>> --- a/tools/include/xenctrl.h
>> +++ b/tools/include/xenctrl.h
>> @@ -1385,7 +1385,7 @@ int xc_domain_ioport_permission(xc_interface *xch,
>>
>> int xc_domain_irq_permission(xc_interface *xch,
>> uint32_t domid,
>> -
flight 163396 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163396/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 4473f3601098a2c3cf5ab89d5a29504772985e3a
baseline version:
xen 74d0
On 07.07.2021 11:10, Juergen Gross wrote:
> Xen frontends shouldn't BUG() in case of illegal data received from
> their backends. So replace the BUG_ON()s when reading illegal data from
> the ring page with negative return values.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
> ---
flight 163393 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163393/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 163326
build-arm64-
On 07.07.21 11:57, Jan Beulich wrote:
On 07.07.2021 11:10, Juergen Gross wrote:
Xen frontends shouldn't BUG() in case of illegal data received from
their backends. So replace the BUG_ON()s when reading illegal data from
the ring page with negative return values.
Signed-off-by: Juergen Gross
On 07. 07. 21, 12:40, Juergen Gross wrote:
And btw, since I've got puzzled by the linuxppc-dev@ in the recipients
list, I did look up relevant entries in ./MAINTAINERS. Shouldn't the
file be part of "XEN HYPERVISOR INTERFACE"?
I wouldn't mind. Greg, Jiri, what do you think?
/me concurs.
than
flight 163398 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163398/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 163326
build-arm64-
Hi Igor,
On 07/07/2021 02:02, Igor Druzhinin wrote:
Current unit8_t for pirq argument in this interface is too restrictive
causing failures on modern hardware with lots of GSIs. That extends down to
XEN_DOMCTL_irq_permission ABI structure where it needs to be fixed up
as well. Internal Xen struc
Hi Michal,
On 06/07/2021 11:28, Michal Orzel wrote:
Function arch_initialise_vcpu is not reachable as the
VCPUOP_initialise is an unsupported operation on arm.
Modify the function by adding ASSERT_UNREACHABLE() and
returning -EOPNOTSUPP.
Suggested-by: Jan Beulich
Signed-off-by: Michal Orzel
On 07.07.2021 14:51, Julien Grall wrote:
> On 07/07/2021 02:02, Igor Druzhinin wrote:
>> Current unit8_t for pirq argument in this interface is too restrictive
>> causing failures on modern hardware with lots of GSIs. That extends down to
>> XEN_DOMCTL_irq_permission ABI structure where it needs to
On 07/07/2021 13:54, Jan Beulich wrote:
On 07.07.2021 14:51, Julien Grall wrote:
On 07/07/2021 02:02, Igor Druzhinin wrote:
Current unit8_t for pirq argument in this interface is too restrictive
causing failures on modern hardware with lots of GSIs. That extends down to
XEN_DOMCTL_irq_permis
flight 163387 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163387/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 162359
test-amd64-amd64-xl-qemuu
On 07/07/2021 13:53, Julien Grall wrote:
Hi Michal,
On 06/07/2021 11:28, Michal Orzel wrote:
Function arch_initialise_vcpu is not reachable as the
VCPUOP_initialise is an unsupported operation on arm.
Modify the function by adding ASSERT_UNREACHABLE() and
returning -EOPNOTSUPP.
Suggested-by
Hi Rahul,
On 06/07/2021 11:53, Rahul Singh wrote:
Switch from kzalloc_array(..) to devm_kcalloc(..) when allocating the
SMR to make code coherent.
Signed-off-by: Rahul Singh
Acked-by: Julien Grall
Cheers,
--
Julien Grall
On 07/07/2021 14:07, Julien Grall wrote:
Hi Rahul,
On 06/07/2021 11:53, Rahul Singh wrote:
Switch from kzalloc_array(..) to devm_kcalloc(..) when allocating the
SMR to make code coherent.
Signed-off-by: Rahul Singh
Acked-by: Julien Grall
And committed.
Cheers,
--
Julien Grall
Commit 438c5ffa44e99cceb574c0f9946aacacdedd2952 ("rpmball: Adjust to
new rpm, do not require --force") attempted to handle stricter
directory permissions in newer distributions.
This introduced a few issues:
- /boot used to be a constant prior commit
6475d700055fa952f7671cee982a23de2f5e4a7c ("us
On 07.07.2021 14:59, Julien Grall wrote:
> On 07/07/2021 13:54, Jan Beulich wrote:
>> On 07.07.2021 14:51, Julien Grall wrote:
>>> On 07/07/2021 02:02, Igor Druzhinin wrote:
Current unit8_t for pirq argument in this interface is too restrictive
causing failures on modern hardware with lot
Andrew has spotted a bug, and I've noticed that a changelog entry
might be a good idea.
1: IOMMU: correct parsing of "quarantine=scratch-page"
2: CHANGELOG: record changed PCI device quarantining default
Jan
On 07/07/2021 14:14, Jan Beulich wrote:
On 07.07.2021 14:59, Julien Grall wrote:
On 07/07/2021 13:54, Jan Beulich wrote:
On 07.07.2021 14:51, Julien Grall wrote:
On 07/07/2021 02:02, Igor Druzhinin wrote:
Current unit8_t for pirq argument in this interface is too restrictive
causing failur
During the multiple renames of the sub-option I apparently forgot to
update the left side of the &&, and this pretty consistently.
Fixes: 980d6acf1517 ("IOMMU: make DMA containment of quarantined devices
optional")
Reported-by: Andrew Cooper
Signed-off-by: Jan Beulich
--- a/xen/drivers/passth
This amends commit 980d6acf1517 ("IOMMU: make DMA containment of
quarantined devices optional").
Signed-off-by: Jan Beulich
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -10,6 +10,13 @@ The format is based on [Keep a Changelog
- XENSTORED_ROOTDIR environment variable from configuartion files and
Hi Luca,
On 06/07/2021 09:44, Luca Fancellu wrote:
On 5 Jul 2021, at 15:20, Julien Grall wrote:
Hi Luca,
On 05/07/2021 11:51, Luca Fancellu wrote:
Modification to include/public/grant_table.h:
1) Add doxygen tags to:
- Create Grant tables section
- include variables in the generated d
On 07.07.2021 15:21, Julien Grall wrote:
> On 07/07/2021 14:14, Jan Beulich wrote:
>> On 07.07.2021 14:59, Julien Grall wrote:
>>> The alternative suggestion is to keep a unsigned type but check the bit
>>> 31 is not set.
>>
>> Why? Why not bit 30 or bit 27? There's nothing special about
>> bit 31
During 'xl save -c|-p' the monitoring xl process will exit
because it gets a
LIBXL_EVENT_TYPE_DOMAIN_SHUTDOWN/LIBXL_SHUTDOWN_REASON_SUSPEND event.
While this is correct for plain 'xl save' usage, the result is that
other events such a shutdown/reboot/etc are not handled anymore for
the domU. In ca
Hi Jan,
On 05/07/2021 09:41, Jan Beulich wrote:
On 03.07.2021 19:11, Julien Grall wrote:
Changes in v5:
- Removed the #ifdef CONFIG_X86 as they are not necessary anymore
- Used paging_mode_translate() rather than is_pv_domain()
Is there a particular reason you use this in favor of s
On Wed, Jul 07, 2021 at 09:15:31AM +0200, Roger Pau Monne wrote:
> Make the go build use APPEND_{C/LD}FLAGS when necessary, just like
> other parts of the build.
>
> Reported-by: Ting-Wei Lan
> Signed-off-by: Roger Pau Monné
> ---
> Note sure if it's the best way to add the appended flags, I'm n
On 07.07.2021 15:39, Julien Grall wrote:
> On 05/07/2021 09:41, Jan Beulich wrote:
>> On 03.07.2021 19:11, Julien Grall wrote:
>>> Changes in v5:
>>> - Removed the #ifdef CONFIG_X86 as they are not necessary anymore
>>> - Used paging_mode_translate() rather than is_pv_domain()
>>
>> Is th
flight 163401 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163401/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 163326
build-arm64-
On 01.07.2021 16:09, Anthony PERARD wrote:
> Signed-off-by: Anthony PERARD
> ---
>
> Notes:
> v6:
> - switch to a macro as suggested
> which allows to be used with both a_flags and c_flags
>
> v5:
> - new patch
>
> xen/Rules.mk| 7 +--
> xen/ar
On 07/07/2021 15:06, Jan Beulich wrote:
On 07.07.2021 15:39, Julien Grall wrote:
On 05/07/2021 09:41, Jan Beulich wrote:
On 03.07.2021 19:11, Julien Grall wrote:
Changes in v5:
- Removed the #ifdef CONFIG_X86 as they are not necessary anymore
- Used paging_mode_translate() rathe
On 01.07.2021 16:09, Anthony PERARD wrote:
> In Arm and X86 makefile, generating the linker script is the same, so
> we can simply have both call the same macro.
>
> We need to add *.lds files into extra-y so that Rules.mk can find the
> .*.cmd dependency file and load it.
>
> Change made to the
Am Wed, 7 Jul 2021 15:34:27 +0200
schrieb Olaf Hering :
> This is incomplete because repeated checkpoint or pause operations are
> not handled.
Apparently they are, it is just not reported because there is no event when the
domU resumes execution.
Olaf
pgpdooQSDlFvS.pgp
Description: Digital
On 7/6/21 5:48 PM, Uwe Kleine-König wrote:
The driver core ignores the return value of this callback because there
is only little it can do when a device disappears.
This is the final bit of a long lasting cleanup quest where several
buses were converted to also return void from their remove cal
flight 163386 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163386/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 163362
test-armhf-armhf-libvirt 16 save
On 01.07.2021 16:09, Anthony PERARD wrote:
> This replace the use of a single .c file use for multiple .o file by
> creating multiple .c file including the first one.
>
> There's quite a few issues with trying to build more than one object
> file from a single source file: there's is a duplication
On 07.07.2021 16:21, Julien Grall wrote:
> On 07/07/2021 15:06, Jan Beulich wrote:
>> On 07.07.2021 15:39, Julien Grall wrote:
>>> On 05/07/2021 09:41, Jan Beulich wrote:
On 03.07.2021 19:11, Julien Grall wrote:
> Changes in v5:
> - Removed the #ifdef CONFIG_X86 as they are not n
On 01.07.2021 16:09, Anthony PERARD wrote:
> Improvement are:
> - give the path to xlat.lst as argument
> - include `grep -v` in compat-build-source.py script, we don't need to
> write this in several scripted language.
>
> Also remove dependency on Makefile as the file generation doesn't
> depe
On 01.07.2021 16:09, Anthony PERARD wrote:
> Signed-off-by: Anthony PERARD
Hmm, I was clearly under the impression (or at least assuming)
that $(targets) would be included in what gets cleaned by the
general rule. But it looks I was wrong with this:
Acked-by: Jan Beulich
Jan
On 01.07.2021 16:09, Anthony PERARD wrote:
> Signed-off-by: Anthony PERARD
Acked-by: Jan Beulich
On 01.07.2021 16:09, Anthony PERARD wrote:
> The make variable $(subdir-y) isn't used yet but will be in a
> following patch. Anything in $(subdir-y) doesn't to have a '/' as
> suffix as we already now it's a directory.
>
> Rework the rules so that it doesn't matter whether there is a '/' or
> not
On 01.07.2021 16:09, Anthony PERARD wrote:
> --- a/xen/test/Makefile
> +++ b/xen/test/Makefile
> @@ -4,15 +4,10 @@ tests all: build
>
> ifneq ($(XEN_TARGET_ARCH),x86_32)
> # Xen 32-bit x86 hypervisor no longer supported, so has no test livepatches
> -SUBDIRS += livepatch
> +subdir-y += livepatc
On 01.07.2021 16:09, Anthony PERARD wrote:
> No need to call $(MAKE) again.
>
> Signed-off-by: Anthony PERARD
Acked-by: Jan Beulich
From: Tianyu Lan
Hyper-V exposes shared memory boundary via cpuid
HYPERV_CPUID_ISOLATION_CONFIG and store it in the
shared_gpa_boundary of ms_hyperv struct. This prepares
to share memory with host for SNP guest.
Signed-off-by: Tianyu Lan
---
arch/x86/kernel/cpu/mshyperv.c | 2 ++
include/asm-
From: Tianyu Lan
Hyper-V provides two kinds of Isolation VMs. VBS(Virtualization-based
security) and AMD SEV-SNP unenlightened Isolation VMs. This patchset
is to add support for these Isolation VM support in Linux.
The memory of these vms are encrypted and host can't access guest
memory directly
From: Tianyu Lan
Add new hvcall guest address host visibility support to mark
memory visible to host. Call it inside set_memory_decrypted
/encrypted().
Signed-off-by: Tianyu Lan
---
arch/x86/hyperv/Makefile | 2 +-
arch/x86/hyperv/ivm.c | 112 ++
From: Tianyu Lan
Mark vmbus ring buffer visible with set_memory_decrypted() when
establish gpadl handle.
Signed-off-by: Tianyu Lan
---
drivers/hv/channel.c | 38 --
include/linux/hyperv.h | 10 ++
2 files changed, 46 insertions(+), 2 deletions(-)
From: Tianyu Lan
Hyper-V provides GHCB protocol to write Synthetic Interrupt
Controller MSR registers in Isolation VM with AMD SEV SNP
and these registers are emulated by hypervisor directly.
Hyper-V requires to write SINTx MSR registers twice. First
writes MSR via GHCB page to communicate with h
From: Tianyu Lan
Hyper-V provides ghcb hvcall to handle VMBus
HVCALL_SIGNAL_EVENT and HVCALL_POST_MESSAGE
msg in SNP Isolation VM. Add such support.
Signed-off-by: Tianyu Lan
---
arch/x86/hyperv/ivm.c | 42 +
arch/x86/include/asm/mshyperv.h | 1 +
dri
From: Tianyu Lan
The monitor pages in the CHANNELMSG_INITIATE_CONTACT msg are shared
with host in Isolation VM and so it's necessary to use hvcall to set
them visible to host. In Isolation VM with AMD SEV SNP, the access
address should be in the extra space which is above shared gpa
boundary. So
From: Tianyu Lan
VMbus ring buffer are shared with host and it's need to
be accessed via extra address space of Isolation VM with
SNP support. This patch is to map the ring buffer
address in extra address space via ioremap(). HV host
visibility hvcall smears data in the ring buffer and
so reset t
From: Tianyu Lan
In Isolation VM with AMD SEV, bounce buffer needs to be accessed via
extra address space which is above shared_gpa_boundary
(E.G 39 bit address line) reported by Hyper-V CPUID ISOLATION_CONFIG.
The access physical address will be original physical address +
shared_gpa_boundary. T
On 01.07.2021 16:09, Anthony PERARD wrote:
> And thus avoiding checking for those variable over and over again.
>
> Signed-off-by: Anthony PERARD
Acked-by: Jan Beulich
in its present shape since all you do is move existing logic. But I
wonder if I could talk you into ...
> --- a/xen/Makefile
>
From: Tianyu Lan
In Isolation VM, all shared memory with host needs to mark visible
to host via hvcall. vmbus_establish_gpadl() has already done it for
netvsc rx/tx ring buffer. The page buffer used by vmbus_sendpacket_
pagebuffer() still need to handle. Use DMA API to map/umap these
memory durin
From: Tianyu Lan
Hyper-V Isolation VM reuses set_memory_decrypted/encrypted function
and not needs to decrypt/encrypt memory in arch_kexec_post_alloc(pre_free)
_pages() just likes AMD SEV VM. So skip them.
Signed-off-by: Tianyu Lan
---
arch/x86/kernel/machine_kexec_64.c | 5 +++--
1 file chang
From: Tianyu Lan
In Isolation VM, all shared memory with host needs to mark visible
to host via hvcall. vmbus_establish_gpadl() has already done it for
storvsc rx/tx ring buffer. The page buffer used by vmbus_sendpacket_
mpb_desc() still need to handle. Use DMA API to map/umap these
memory during
From: Tianyu Lan
Hyper-V Isolation VM requires bounce buffer support to copy
data from/to encrypted memory and so enable swiotlb force
mode to use swiotlb bounce buffer for DMA transaction.
In Isolation VM with AMD SEV, the bounce buffer needs to be
accessed via extra address space which is abov
From: Tianyu Lan
Hyper-V provides two kinds of Isolation VMs. VBS(Virtualization-based
security) and AMD SEV-SNP unenlightened Isolation VMs. This patchset
is to add support for these Isolation VM support in Linux.
The memory of these vms are encrypted and host can't access guest
memory directly
From: Tianyu Lan
Hyper-V provides two kinds of Isolation VMs. VBS(Virtualization-based
security) and AMD SEV-SNP unenlightened Isolation VMs. This patchset
is to add support for these Isolation VM support in Linux.
The memory of these vms are encrypted and host can't access guest
memory directly
From: Tianyu Lan
Hyper-V exposes GHCB page via SEV ES GHCB MSR for SNP guest
to communicate with hypervisor. Map GHCB page for all
cpus to read/write MSR register and submit hvcall request
via GHCB.
Signed-off-by: Tianyu Lan
---
arch/x86/hyperv/hv_init.c | 64
From: Tianyu Lan
Hyper-V exposes shared memory boundary via cpuid
HYPERV_CPUID_ISOLATION_CONFIG and store it in the
shared_gpa_boundary of ms_hyperv struct. This prepares
to share memory with host for SNP guest.
Signed-off-by: Tianyu Lan
---
arch/x86/kernel/cpu/mshyperv.c | 2 ++
include/asm-
From: Tianyu Lan
Add new hvcall guest address host visibility support to mark
memory visible to host. Call it inside set_memory_decrypted
/encrypted().
Signed-off-by: Tianyu Lan
---
arch/x86/hyperv/Makefile | 2 +-
arch/x86/hyperv/ivm.c | 112 ++
From: Tianyu Lan
Mark vmbus ring buffer visible with set_memory_decrypted() when
establish gpadl handle.
Signed-off-by: Tianyu Lan
---
drivers/hv/channel.c | 38 --
include/linux/hyperv.h | 10 ++
2 files changed, 46 insertions(+), 2 deletions(-)
From: Tianyu Lan
Hyper-V provides GHCB protocol to write Synthetic Interrupt
Controller MSR registers in Isolation VM with AMD SEV SNP
and these registers are emulated by hypervisor directly.
Hyper-V requires to write SINTx MSR registers twice. First
writes MSR via GHCB page to communicate with h
From: Tianyu Lan
Hyper-V provides ghcb hvcall to handle VMBus
HVCALL_SIGNAL_EVENT and HVCALL_POST_MESSAGE
msg in SNP Isolation VM. Add such support.
Signed-off-by: Tianyu Lan
---
arch/x86/hyperv/ivm.c | 42 +
arch/x86/include/asm/mshyperv.h | 1 +
dri
From: Tianyu Lan
The monitor pages in the CHANNELMSG_INITIATE_CONTACT msg are shared
with host in Isolation VM and so it's necessary to use hvcall to set
them visible to host. In Isolation VM with AMD SEV SNP, the access
address should be in the extra space which is above shared gpa
boundary. So
On 01.07.2021 16:09, Anthony PERARD wrote:
> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -80,8 +80,12 @@ config.gz: $(CONF_FILE)
>
> config_data.o: config.gz
>
> -config_data.S: $(BASEDIR)/tools/binfile
> - $(SHELL) $(BASEDIR)/tools/binfile $@ config.gz xen_config_data
> +qu
From: Tianyu Lan
Hyper-V Isolation VM reuses set_memory_decrypted/encrypted function
and not needs to decrypted/encrypted in arch_kexec_post_alloc(pre_free)
_pages just likes AMD SEV VM. So skip them.
Signed-off-by: Tianyu Lan
---
arch/x86/kernel/machine_kexec_64.c | 5 +++--
1 file changed, 3
From: Tianyu Lan
In Isolation VM, all shared memory with host needs to mark visible
to host via hvcall. vmbus_establish_gpadl() has already done it for
storvsc rx/tx ring buffer. The page buffer used by vmbus_sendpacket_
mpb_desc() still need to handle. Use DMA API to map/umap these
memory during
From: Tianyu Lan
In Isolation VM with AMD SEV, bounce buffer needs to be accessed via
extra address space which is above shared_gpa_boundary
(E.G 39 bit address line) reported by Hyper-V CPUID ISOLATION_CONFIG.
The access physical address will be original physical address +
shared_gpa_boundary. T
From: Tianyu Lan
VMbus ring buffer are shared with host and it's need to
be accessed via extra address space of Isolation VM with
SNP support. This patch is to map the ring buffer
address in extra address space via ioremap(). HV host
visibility hvcall smears data in the ring buffer and
so reset t
From: Tianyu Lan
Hyper-V Isolation VM requires bounce buffer support to copy
data from/to encrypted memory and so enable swiotlb force
mode to use swiotlb bounce buffer for DMA transaction.
In Isolation VM with AMD SEV, the bounce buffer needs to be
accessed via extra address space which is abov
From: Tianyu Lan
In Isolation VM, all shared memory with host needs to mark visible
to host via hvcall. vmbus_establish_gpadl() has already done it for
netvsc rx/tx ring buffer. The page buffer used by vmbus_sendpacket_
pagebuffer() still need to handle. Use DMA API to map/umap these
memory durin
Hi, sorry about the late respond. I tried your suggestion, it works. I'm kind
of surprised too, since such problem should exposed long time ago.
I looked deep into your suggestion. I believe you were right about it, since p
- ctxt->io_emul_stub won't overflow and the pointer overflow is likel
On 07.07.2021 17:54, Rroach wrote:
> Hi, sorry about the late respond. I tried your suggestion, it works. I'm kind
> of surprised too, since such problem should exposed long time ago.
>
>
> I looked deep into your suggestion. I believe you were right about it, since
> p - ctxt->io_emul_stub w
On 01.07.2021 16:10, Anthony PERARD wrote:
> Avoid different spelling for the location of "xen-syms", and simply
> use the dependency variable. This avoid the assumption about $(TARGET)
> value.
>
> Signed-off-by: Anthony PERARD
Acked-by: Jan Beulich
with s/node/note/ in the title (I was very c
On 7/7/21 8:46 AM, Tianyu Lan wrote:
> @@ -598,7 +599,7 @@ void arch_kexec_unprotect_crashkres(void)
> */
> int arch_kexec_post_alloc_pages(void *vaddr, unsigned int pages, gfp_t gfp)
> {
> - if (sev_active())
> + if (sev_active() || hv_is_isolation_supported())
> return 0
This is to allow building the latest version of QEMU.
fedora/29:
In addition to adding "ninja", I've add to make some other
changes: some `go build` failed with `mkdir /.cache` no
permission, so I've created a user.
(this was discovered while testing the new container with the
Patch series available in this git branch:
https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git
br.automation-add-ninja-v1
Adding ninja-build pkg when possible.
I'll push new containers soon.
Anthony PERARD (2):
automation: Adding ninja-build to some docker images
automation: Ch
ninja is now required to build the latest version of QEMU, some
container still don't have ninja and attempting to add it breaks the
build for different reasons, so QEMU will be skip on those containers.
Failures:
- ubuntu/xenial:
fatal: ninja version (1.5.1) incompatible with build file
ninj
On Wed, Jul 07, 2021 at 05:39:59PM +0100, Anthony PERARD wrote:
> Adding ninja-build pkg when possible.
>
> I'll push new containers soon.
I've pushed:
registry.gitlab.com/xen-project/xen/fedora:29
registry.gitlab.com/xen-project/xen/ubuntu:bionic
registry.gitlab.com/xen-project/xen/u
On 07/07/2021 17:40, Anthony PERARD wrote:
> ninja is now required to build the latest version of QEMU, some
> container still don't have ninja and attempting to add it breaks the
> build for different reasons, so QEMU will be skip on those containers.
>
> Failures:
> - ubuntu/xenial:
> fatal:
flight 163408 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163408/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
The pull request you sent on Wed, 7 Jul 2021 09:01:39 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
> for-linus-5.14-rc1-tag
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/4ea90317956718e0648e1f87e56530db809a5a04
Thank you!
--
Deet-doot-dot, I
On Thu, Jul 01, 2021 at 02:09:47PM +, George Dunlap wrote:
>
>
> > On Jun 21, 2021, at 5:11 PM, Nick Rosbrook wrote:
> >
> > On Fri, Jun 18, 2021 at 11:00:26AM +, George Dunlap wrote:
> >>
> >>
> >>> On May 24, 2021, at 9:36 PM, Nick Rosbrook wrote:
> >>>
> >>> In gengotypes.py, the
flight 163389 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163389/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-coresched-i386-xl broken
test-amd64-i386-libvirt-xsm
Am Wed, 7 Jul 2021 18:46:03 +0100
schrieb Andrew Cooper :
> iPXE failure
it just needs to be updated to ipxe.git#master to make it compatible with gcc11.
Olaf
pgpzeULyg8uF4.pgp
Description: Digitale Signatur von OpenPGP
Am Wed, 7 Jul 2021 18:46:03 +0100
schrieb Andrew Cooper :
> Tumbleweed is generally broken and fails at ./configure due to missing
> compression libraries.
Something requests zlib-devel to be installed.
I suggest to provide all config.logs, not just the one from the top directory.
Also a "test
flight 163394 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163394/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-rtds broken
test-amd64-amd64-dom0pvh-xl-amd
1 - 100 of 128 matches
Mail list logo
