On 28.07.2021 12:27, Penny Zheng wrote:
> @@ -1065,6 +1069,73 @@ static struct page_info *alloc_heap_pages(
> return pg;
> }
>
> +#ifdef CONFIG_STATIC_MEMORY
> +/*
> + * Acquire nr_mfns contiguous reserved pages, starting at #smfn, of
> + * static memory.
> + */
> +static struct page_info *
On 28.07.2021 12:27, Penny Zheng wrote:
> In order to deal with the trouble of count-to-order conversion when page
> number
> is not in a power-of-two, this commit re-define assign_pages for nr pages and
> assign_page for original page with a single order.
>
> Backporting confusion could be helpe
On 04.08.2021 19:55, Dario Faggioli wrote:
> Commit 07b0eb5d0ef0 ("credit2: make sure we pick a runnable unit from the
> runq if there is one") did not fix completely the problem of potentially
> selecting a scheduling unit that will then not be able to run.
>
> In fact, in case caps are used and
On 05.08.2021 00:17, Jason Andryuk wrote:
> commit 0fdb48ffe7a1 "libxl: Make sure devices added by pci-attach are
> reflected in the config"
This should be in a Fixes: tag; whether you fully spell out the
reference here or instead refer to that tag would by up to you.
> broken stubdom PCI passthr
On 04.08.2021 21:18, Oleksandr wrote:
> On 03.08.21 15:53, Jan Beulich wrote:
>> On 30.07.2021 18:13, Oleksandr wrote:
>>> - Where that range should be located in guest address space, should that
>>> range be the same for all domains (how GUEST_GNTTAB_BASE(SIZE) for example)
>>> or it should be cal
flight 164104 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164104/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
flight 164103 qemu-mainline real [real]
flight 164107 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/164103/
http://logs.test-lab.xenproject.org/osstest/logs/164107/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-ar
flight 164102 linux-5.4 real [real]
flight 164105 linux-5.4 real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/164102/
http://logs.test-lab.xenproject.org/osstest/logs/164105/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386
commit 0fdb48ffe7a1 "libxl: Make sure devices added by pci-attach are
reflected in the config" broken stubdom PCI passthrough when it moved
libxl__create_pci_backend later in the function. xl pci-attach for a
running PV domain may also have been broken, but that was not verified.
The stubdomain i
On 04/08/2021 21:56, Oleksandr wrote:
Hi Julien, Stefano.
Hi Oleksandr,
On 02.08.21 22:12, Oleksandr wrote:
I have done some experiments with Xen and toolstack according to the
discussion above. So, I re-used DTB to pass a safe range to the domain.
For the range I borrowed some space f
Hi Stefano,
On 04/08/2021 21:57, Stefano Stabellini wrote:
Set/Way flushes never work correctly in a virtualized environment.
Our current implementation is based on clearing the valid bit in the p2m
pagetable to track guest memory accesses. This technique doesn't work
when the IOMMU is enabled
Set/Way flushes never work correctly in a virtualized environment.
Our current implementation is based on clearing the valid bit in the p2m
pagetable to track guest memory accesses. This technique doesn't work
when the IOMMU is enabled for the domain and the pagetable is shared
between IOMMU and M
Hi Julien, Stefano.
On 02.08.21 22:12, Oleksandr wrote:
Hi Stefano,
Thank you for the comments and ideas.
On 31.07.21 02:57, Stefano Stabellini wrote:
On Fri, 30 Jul 2021, Oleksandr wrote:
Hi Andrew, Julien.
@Andrew, I think that arguments you provided in your first answer
(why the
flight 164100 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164100/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
On 8/4/21 11:44 AM, Tianyu Lan wrote:
> +static int default_set_memory_enc(unsigned long addr, int numpages, bool
> enc);
> +DEFINE_STATIC_CALL(x86_set_memory_enc, default_set_memory_enc);
> +
> #define CPA_FLUSHTLB 1
> #define CPA_ARRAY 2
> #define CPA_PAGES_ARRAY 4
> @@ -1981,6 +1985,11 @@ in
CCing people working on Xen+VirtIO and IOREQs. Not trimming the original
email to let them read the full context.
My comments below are related to a potential Xen implementation, not
because it is the only implementation that matters, but because it is
the one I know best.
Also, please see this r
On 03.08.21 15:53, Jan Beulich wrote:
Hi, Jan
Thank you for the input.
On 30.07.2021 18:13, Oleksandr wrote:
Well, if new hypercall and, what is more, "the querying hypervisor at
runtime to find unused space" model itself is not welcome, I am ok,
let's try to create a working system,
may we
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
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
From: Tianyu Lan
In Hyper-V Isolation VM with AMD SEV, swiotlb boucne buffer
needs to be mapped into address space above vTOM and so
introduce dma_map_decrypted/dma_unmap_encrypted() to map/unmap
bounce buffer memory. The platform can populate man/unmap callback
in the dma memory decrypted ops.
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
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
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
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 | 43 +
arch/x86/include/asm/mshyperv.h | 1 +
dri
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
Mark vmbus ring buffer visible with set_memory_decrypted() when
establish gpadl handle.
Signed-off-by: Tianyu Lan
---
drivers/hv/channel.c | 44 --
include/linux/hyperv.h | 11 +++
2 files changed, 53 insertions(+), 2 deletions
From: Tianyu Lan
Add new hvcall guest address host visibility support to mark
memory visible to host. Override x86_set_memory_enc static
call with hv hook to mark memory visible to host via set_
memory_decrypted().
Signed-off-by: Tianyu Lan
---
Change since v1:
* Use new staic call x86_s
From: Tianyu Lan
Hyper-V and other platforms(e.g Intel and AMD) want to override
the __set_memory_enc_dec(). Add x86_set_memory_enc static
call here and platforms can hook their implementation.
Signed-off-by: Tianyu Lan
---
arch/x86/include/asm/set_memory.h | 4
arch/x86/mm/pat/set_memory
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 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 | 69
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
Hi Stefano,
On 04/08/2021 18:41, Stefano Stabellini wrote:
On Wed, 4 Aug 2021, Julien Grall wrote:
Hi Stefano,
On 04/08/2021 01:08, Stefano Stabellini wrote:
diff --git a/xen/arch/arm/arm64/vsysreg.c b/xen/arch/arm/arm64/vsysreg.c
index caf17174b8..125a9281fc 100644
--- a/xen/arch/arm/arm64/v
Commit 07b0eb5d0ef0 ("credit2: make sure we pick a runnable unit from the
runq if there is one") did not fix completely the problem of potentially
selecting a scheduling unit that will then not be able to run.
In fact, in case caps are used and the unit we are currently looking
at, during the runq
On Wed, 2021-08-04 at 17:13 +0200, Jan Beulich wrote:
> On 04.08.2021 15:28, Dario Faggioli wrote:
> >
> > So, was it this you were asking about and, if yes, does this answer
> > your concerns?
>
> Yes, it does.
>
Ok, great. :-)
> I continue to think though that the "yield" variable
> could do
On Wed, 4 Aug 2021, Julien Grall wrote:
> Hi Stefano,
>
> On 04/08/2021 01:08, Stefano Stabellini wrote:
> > > > diff --git a/xen/arch/arm/arm64/vsysreg.c b/xen/arch/arm/arm64/vsysreg.c
> > > > index caf17174b8..125a9281fc 100644
> > > > --- a/xen/arch/arm/arm64/vsysreg.c
> > > > +++ b/xen/arch/ar
This adds a boolean flag to the xl domain configuration syntax for
causing a guest's CPU allocations to be mirrored to its associated
device-model stubdomain. If enabled, the stubdomain will use the same
VCPU count, CPU pool, and CPU affinities as the guest. Otherwise, the
default allocations (one
On 28.07.2021 12:27, Penny Zheng wrote:
> This patch introduces static memory initialization, during system boot up.
>
> The new function init_staticmem_pages is responsible for static memory
> initialization.
>
> Helper free_staticmem_pages is the equivalent of free_heap_pages, to free
> nr_mfns
flight 164098 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164098/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail REGR. vs. 164095
test-armhf-armhf-xl-rtds
On 04.08.2021 15:28, Dario Faggioli wrote:
> On Wed, 2021-08-04 at 09:37 +0200, Jan Beulich wrote:
>> On 03.08.2021 19:36, Dario Faggioli wrote:
>>>
>>> Signed-off-by: Dario Faggioli
>>> Suggested-by: George Dunlap
>>
>> Minor remark: Generally I think the order of tags should follow the
>> timel
On Wed, 2021-08-04 at 09:37 +0200, Jan Beulich wrote:
> On 03.08.2021 19:36, Dario Faggioli wrote:
> >
> > Signed-off-by: Dario Faggioli
> > Suggested-by: George Dunlap
>
> Minor remark: Generally I think the order of tags should follow the
> timeline: Suggestions (or bug reports) come before p
flight 164097 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164097/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 164094
test-armhf-armhf-libvirt 16 save
The pause_flags field must always be modified atomically, as it is
manupulated (e.g., in schedule.c) without any lock held.
Credit2 code was not doing that, which causes races.
Specifically, we have see cases where the unprotected setting of the
_VPF_migrating flag in csched_credit2:migrate() was
Hi Stefano,
On 04/08/2021 01:08, Stefano Stabellini wrote:
diff --git a/xen/arch/arm/arm64/vsysreg.c b/xen/arch/arm/arm64/vsysreg.c
index caf17174b8..125a9281fc 100644
--- a/xen/arch/arm/arm64/vsysreg.c
+++ b/xen/arch/arm/arm64/vsysreg.c
@@ -105,6 +105,13 @@ void do_sysreg(struct cpu_user_regs *
flight 164099 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164099/
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 164101 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164101/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 2278d2cbb0b7c1b48b298c6c4c6a7de2271ac928
baseline version:
xen e066
On 03.08.2021 19:36, Dario Faggioli wrote:
> Commit 07b0eb5d0ef0 ("credit2: make sure we pick a runnable unit from the
> runq if there is one") did not fix completely the problem of potentially
> selecting a scheduling unit that will then not be able to run.
>
> In fact, in case caps are used and
flight 164096 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164096/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
48 matches
Mail list logo
