On 17/05/2021 22:43, Marek Marczykowski-Górecki wrote:
On Tue, May 11, 2021 at 12:46:38PM +, Durrant, Paul wrote:
-Original Message-
From: Marek Marczykowski-Górecki
Sent: 11 May 2021 11:45
To: Durrant, Paul
Cc: Michael Brown ; p...@xen.org;
xen-devel@lists.xenproject.org;
net...@
v7: https://lore.kernel.org/patchwork/cover/1431031/
On Mon, May 10, 2021 at 5:50 PM Claire Chang wrote:
>
> From: Claire Chang
>
> This series implements mitigations for lack of DMA access control on
> systems without an IOMMU, which could result in the DMA accessing the
> system memory at unex
Regardless of swiotlb setting, the restricted DMA pool is preferred if
available.
The restricted DMA pools provide a basic level of protection against the
DMA overwriting buffer contents at unexpected times. However, to protect
against general data leakage and system memory corruption, the system
Update is_swiotlb_active to add a struct device argument. This will be
useful later to allow for restricted DMA pool.
Signed-off-by: Claire Chang
---
drivers/gpu/drm/i915/gem/i915_gem_internal.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_ttm.c| 2 +-
drivers/pci/xen-pcifront.c
Move the maintenance of alloc_size to find_slots for better code
reusability later.
Signed-off-by: Claire Chang
---
kernel/dma/swiotlb.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 95f482c4408c..2ec6711071de 100
Still keep this function because directly using dev->dma_io_tlb_mem
will cause issues for memory allocation for existing devices. The pool
can't support atomic coherent allocation so we need to distinguish the
per device pool and the default pool in swiotlb_alloc.
I didn't move this to a separate file because I feel it might be
confusing for swiotlb_alloc/free (and need more functions to be
non-static).
Maybe instead of moving to a separate file, we can try to come up with
a better naming?
If a device is not behind an IOMMU, we look up the device node and set
up the restricted DMA when the restricted-dma-pool is presented.
Signed-off-by: Claire Chang
---
drivers/of/address.c| 25 +
drivers/of/device.c | 3 +++
drivers/of/of_private.h | 5 +
3
Introduce the new compatible string, restricted-dma-pool, for restricted
DMA. One can specify the address and length of the restricted DMA memory
region by restricted-dma-pool in the reserved-memory node.
Signed-off-by: Claire Chang
---
.../reserved-memory/reserved-memory.txt | 27
The restricted DMA pool is preferred if available.
The restricted DMA pools provide a basic level of protection against the
DMA overwriting buffer contents at unexpected times. However, to protect
against general data leakage and system memory corruption, the system
needs to provide a way to lock
Add the functions, swiotlb_{alloc,free} to support the memory allocation
from restricted DMA pool.
Signed-off-by: Claire Chang
---
include/linux/swiotlb.h | 4
kernel/dma/swiotlb.c| 35 +--
2 files changed, 37 insertions(+), 2 deletions(-)
diff --git a/
Add a new wrapper __dma_direct_free_pages() that will be useful later
for swiotlb_free().
Signed-off-by: Claire Chang
---
kernel/dma/direct.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 078f7087e466..eb409832
Add a new function, release_slots, to make the code reusable for supporting
different bounce buffer pools, e.g. restricted DMA pool.
Signed-off-by: Claire Chang
---
kernel/dma/swiotlb.c | 35 ---
1 file changed, 20 insertions(+), 15 deletions(-)
diff --git a/kern
Add a new getter, get_io_tlb_mem, to help select the io_tlb_mem struct.
The restricted DMA pool is preferred if available.
Signed-off-by: Claire Chang
---
include/linux/swiotlb.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
in
Update is_swiotlb_buffer to add a struct device argument. This will be
useful later to allow for restricted DMA pool.
Signed-off-by: Claire Chang
---
drivers/iommu/dma-iommu.c | 12 ++--
drivers/xen/swiotlb-xen.c | 2 +-
include/linux/swiotlb.h | 6 +++---
kernel/dma/direct.c |
On 17.05.21 17:55, Julien Grall wrote:
Hi Juergen,
On 17/05/2021 07:47, Juergen Gross wrote:
On 14.05.21 22:19, Julien Grall wrote:
Hi Juergen,
On 14/05/2021 09:41, Juergen Gross wrote:
Xenstored is absolutely mandatory for a Xen host and it can't be
restarted, so being killed by OOM-killer
Add the initialization function to create restricted DMA pools from
matching reserved-memory nodes.
Signed-off-by: Claire Chang
---
include/linux/device.h | 4 +++
include/linux/swiotlb.h | 3 +-
kernel/dma/swiotlb.c| 76 +
3 files changed, 82 inser
Add a new kconfig symbol, DMA_RESTRICTED_POOL, for restricted DMA pool.
Signed-off-by: Claire Chang
---
kernel/dma/Kconfig | 14 ++
1 file changed, 14 insertions(+)
diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig
index 77b405508743..3e961dc39634 100644
--- a/kernel/dma/Kconfig
Split the debugfs creation to make the code reusable for supporting
different bounce buffer pools, e.g. restricted DMA pool.
Signed-off-by: Claire Chang
---
kernel/dma/swiotlb.c | 25 +++--
1 file changed, 19 insertions(+), 6 deletions(-)
diff --git a/kernel/dma/swiotlb.c b/
Add a new function, swiotlb_init_io_tlb_mem, for the io_tlb_mem struct
initialization to make the code reusable.
Note that we now also call set_memory_decrypted in swiotlb_init_with_tbl.
Signed-off-by: Claire Chang
---
kernel/dma/swiotlb.c | 51 ++--
1 fi
This series implements mitigations for lack of DMA access control on
systems without an IOMMU, which could result in the DMA accessing the
system memory at unexpected times and/or unexpected addresses, possibly
leading to data leakage or corruption.
For example, we plan to use the PCI-e bus for Wi
On 18.05.2021 06:58, Connor Davis wrote:
> On 5/17/21 5:51 AM, Jan Beulich wrote:
>> On 14.05.2021 20:53, Connor Davis wrote:
>>> --- /dev/null
>>> +++ b/xen/arch/riscv/configs/riscv64_defconfig
>>> @@ -0,0 +1,12 @@
>>> +# CONFIG_SCHED_CREDIT is not set
>>> +# CONFIG_SCHED_RTDS is not set
>>> +# CO
On 18.05.2021 05:58, Connor Davis wrote:
>
> On 5/17/21 5:22 AM, Jan Beulich wrote:
>> On 14.05.2021 20:53, Connor Davis wrote:
>>> Move struct grant_table; in grant_table.h above
>>> ifdef CONFIG_GRANT_TABLE. This fixes the following:
>>>
>>> /build/xen/include/xen/grant_table.h:84:50: error: 'st
On 18.05.2021 06:11, Connor Davis wrote:
>
> On 5/17/21 9:42 AM, Julien Grall wrote:
>> Hi Jan,
>>
>> On 17/05/2021 12:16, Jan Beulich wrote:
>>> On 14.05.2021 20:53, Connor Davis wrote:
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -294,7 +294,9 @@ int guest_remove_page(st
The main loop of xenstored is rather complicated due to different
handling of socket and ring-page interfaces. Unify that handling by
introducing interface type specific functions can_read() and
can_write().
Take the opportunity to remove the empty list check before calling
write_messages() becaus
Small series to make the main loop of xenstored more readable.
Changes in V2:
- split into two patches
- use const
- NO_SOCKETS handling
Changes in V3:
- guard extern declaration with NO_SOCKETS
Juergen Gross (2):
tools/xenstore: move per connection read and write func hooks into a
struct
Put the interface type specific functions into an own structure and let
struct connection contain only a pointer to that new function vector.
Don't even define the socket based functions in case of NO_SOCKETS
(Mini-OS).
Signed-off-by: Juergen Gross
Reviewed-by: Julien Grall
---
V2:
- split off
flight 161987 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161987/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 1fbf5e30ae8eb725f4e10984f7b0a208f78abbd0
baseline version:
ovmf d2e0c473e6f0d518e8acb
flight 161983 xen-unstable real [real]
flight 161989 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/161983/
http://logs.test-lab.xenproject.org/osstest/logs/161989/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be r
This commit introduces allocate_static_memory to allocate static memory as
guest RAM for domain on Static Allocation.
It uses alloc_domstatic_pages to allocate pre-defined static memory banks
for this domain, and uses guest_physmap_add_page to set up P2M table,
guest starting at fixed GUEST_RAM0_B
This commit parses `xen,static-mem` device tree property, to acquire
static memory info reserved for this domain, when constructing domain
during boot-up.
Related info shall be stored in new static_mem value under per domain
struct arch_domain.
Right now, the implementation of allocate_static_mem
Since page_list under struct domain refers to linked pages as gueast RAM
allocated from heap, it should not include reserved pages of static memory.
The number of PGC_reserved pages assigned to a domain is tracked in
a new 'reserved_pages' counter. Also introduce a new reserved_page_list
to link p
alloc_domstatic_pages is the equivalent of alloc_domheap_pages for
static mmeory, and it is to allocate nr_pfns pages of static memory
and assign them to one specific domain.
It uses alloc_staticmen_pages to get nr_pages pages of static memory,
then on success, it will use assign_pages to assign t
Function parameter order in assign_pages is always used as 1ul << order,
referring to 2@order pages.
Now, for better compatibility with new static memory, order shall
be replaced with nr_pfns pointing to page count with no constraint,
like 250MB.
Signed-off-by: Penny Zheng
---
xen/arch/x86/pv/d
alloc_staticmem_pages is designated to allocate nr_pfns contiguous
pages of static memory. And it is the equivalent of alloc_heap_pages
for static memory.
This commit only covers allocating at specified starting address.
For each page, it shall check if the page is reserved
(PGC_reserved) and free
static memory regions overlap with memory nodes. The
overlapping memory is reserved-memory and should be
handled accordingly:
dt_unreserved_regions should skip these regions the
same way they are already skipping mem-reserved regions.
Signed-off-by: Penny Zheng
---
xen/arch/arm/setup.c | 39
Static Allocation refers to system or sub-system(domains) for which memory
areas are pre-defined by configuration using physical address ranges.
Those pre-defined memory, -- Static Momery, as parts of RAM reserved in the
beginning, shall never go to heap allocator or boot allocator for any use.
Do
In order to differentiate pages of static memory, from those allocated from
heap, this patch introduces a new page flag PGC_reserved to tell.
New struct reserved in struct page_info is to describe reserved page info,
that is, which specific domain this page is reserved to.
Helper page_get_reserve
Static allocation refers to system or sub-system(domains) for which memory
areas are pre-defined by configuration using physical address ranges.
Those pre-defined memory, -- Static Momery, as parts of RAM reserved in the
beginning, shall never go to heap allocator or boot allocator for any use.
Th
This patch introduces static memory initialization, during system RAM boot up.
New func init_staticmem_pages is the equivalent of init_heap_pages, responsible
for static memory initialization.
Helper func free_staticmem_pages is the equivalent of free_heap_pages, to free
nr_pfns pages of static m
Create one design doc for 1:1 direct-map and static allocation.
It is the first draft and aims to describe why and how we allocate
1:1 direct-map(guest physical == physical) domains, and why and how
we let domains on static allocation.
Signed-off-by: Penny Zheng
---
docs/designs/static_alloc_and
On 5/17/21 5:51 AM, Jan Beulich wrote:
On 14.05.2021 20:53, Connor Davis wrote:
--- /dev/null
+++ b/config/riscv64.mk
@@ -0,0 +1,5 @@
+CONFIG_RISCV := y
+CONFIG_RISCV_64 := y
+CONFIG_RISCV_$(XEN_OS) := y
I wonder whether the last one actually gets used anywhere, but I do
realize that other a
On 5/17/21 9:42 AM, Julien Grall wrote:
Hi Jan,
On 17/05/2021 12:16, Jan Beulich wrote:
On 14.05.2021 20:53, Connor Davis wrote:
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -294,7 +294,9 @@ int guest_remove_page(struct domain *d, unsigned
long gmfn)
p2m_type_t p2mt;
#end
On 5/17/21 7:43 PM, Bob Eshleman wrote:
On 5/14/21 4:47 PM, Connor Davis wrote:
On 5/14/21 3:53 PM, Bob Eshleman wrote:
On 5/14/21 11:53 AM, Connor Davis wrote:
+
+#ifdef CONFIG_RISCV_64
+
+/*
+ * RISC-V Layout:
+ * 0x - 0x003f (256GB, L2 slots [0-255])
+ *
On 5/17/21 5:22 AM, Jan Beulich wrote:
On 14.05.2021 20:53, Connor Davis wrote:
Move struct grant_table; in grant_table.h above
ifdef CONFIG_GRANT_TABLE. This fixes the following:
/build/xen/include/xen/grant_table.h:84:50: error: 'struct grant_table'
declared inside parameter list will not b
On 5/14/21 4:47 PM, Connor Davis wrote:
>
> On 5/14/21 3:53 PM, Bob Eshleman wrote:
>> On 5/14/21 11:53 AM, Connor Davis wrote:
>>
>>> +
>>> +#ifdef CONFIG_RISCV_64
>>> +
>>> +/*
>>> + * RISC-V Layout:
>>> + * 0x - 0x003f (256GB, L2 slots [0-255])
>>> + * Unmapped
On Sat, 15 May 2021, Julien Grall wrote:
> Hi Stefano,
>
> On 15/05/2021 01:02, Stefano Stabellini wrote:
> > On Sun, 25 Apr 2021, Julien Grall wrote:
> > > From: Julien Grall
> > >
> > > Now that map_pages_to_xen() has been extended to support 2MB mappings,
> > > we can replace the create_mappi
On Sat, 15 May 2021, Julien Grall wrote:
> Hi,
>
> On 15/05/2021 00:51, Stefano Stabellini wrote:
> > On Sun, 25 Apr 2021, Julien Grall wrote:
> > > From: Julien Grall
> > >
> > > A few issues have been reported with setup_xenheap_mappings() over the
> > > last couple of years. The main ones are
On Sat, 15 May 2021, Julien Grall wrote:
> Hi Stefano,
>
> On 13/05/2021 23:27, Stefano Stabellini wrote:
> > On Thu, 13 May 2021, Julien Grall wrote:
> > > Hi Stefano,
> > >
> > > On 12/05/2021 23:44, Stefano Stabellini wrote:
> > > > On Sun, 25 Apr 2021, Julien Grall wrote:
> > > > > From: Juli
flight 161981 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161981/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-freebsd11-amd64 16 guest-saverestore fail REGR. vs.
152631
test-amd64-i3
On 5/17/21 5:22 AM, Jan Beulich wrote:
On 14.05.2021 20:53, Connor Davis wrote:
Move struct grant_table; in grant_table.h above
ifdef CONFIG_GRANT_TABLE. This fixes the following:
/build/xen/include/xen/grant_table.h:84:50: error: 'struct grant_table'
declared inside parameter list will not b
On 5/17/21 5:56 AM, Jan Beulich wrote:
--- a/xen/drivers/char/Kconfig
+++ b/xen/drivers/char/Kconfig
@@ -1,6 +1,6 @@
config HAS_NS16550
bool "NS16550 UART driver" if ARM
- default y
+ default y if (ARM || X86)
... this approach doesn't scale very well. You would likely ha
flight 161985 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161985/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
FWIW: for project EVE, the timing on this is perfect -- I've just
started a complete RISC-V port:
https://github.com/lf-edge/eve/pull/2083
Targeting KVM for now, but would be awesome to see at least some
rudimentary RISC-V support land in Xen.
Connor, I'll be merging your changes into my patc
On Mon, May 17, 2021 at 10:51:38PM +0100, Michael Brown wrote:
> On 17/05/2021 22:43, Marek Marczykowski-Górecki wrote:
> > In any case, the issue is not calling the hotplug script, responsible
> > for configuring newly created vif interface. Not kernel waiting for it.
> > So, I think both commits
On 17/05/2021 22:43, Marek Marczykowski-Górecki wrote:
In any case, the issue is not calling the hotplug script, responsible
for configuring newly created vif interface. Not kernel waiting for it.
So, I think both commits should still be reverted.
Did you also test the ability for a domU to hav
On Tue, May 11, 2021 at 12:46:38PM +, Durrant, Paul wrote:
> > -Original Message-
> > From: Marek Marczykowski-Górecki
> > Sent: 11 May 2021 11:45
> > To: Durrant, Paul
> > Cc: Michael Brown ; p...@xen.org;
> > xen-devel@lists.xenproject.org;
> > net...@vger.kernel.org; wei@kerne
flight 161982 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161982/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
On Mon, May 10, 2021 at 06:49:01PM +0100, Julien Grall wrote:
> Hi,
>
> Ian, Wei, Anthony, can I get some feedbacks on the tools side?
I think this is moving to the right direction so
Acked-by: Wei Liu
Hi Costin,
On 10/05/2021 09:35, Costin Lupu wrote:
If PAGE_SIZE is already defined in the system (e.g. in /usr/include/limits.h
header) then gcc will trigger a redefinition error because of -Werror. This
patch replaces usage of PAGE_* macros with XC_PAGE_* macros in order to avoid
confusion betw
flight 161977 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161977/
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-
Hi Costin,
On 10/05/2021 09:35, Costin Lupu wrote:
If PAGE_SIZE is already defined in the system (e.g. in /usr/include/limits.h
header) then gcc will trigger a redefinition error because of -Werror. This
patch replaces usage of PAGE_* macros with XC_PAGE_* macros in order to avoid
confusion betw
Hi Costin,
On 10/05/2021 09:35, Costin Lupu wrote:
@@ -168,7 +168,7 @@ void *osdep_xenforeignmemory_map(xenforeignmemory_handle
*fmem,
size_t i;
int rc;
-addr = mmap(addr, num << PAGE_SHIFT, prot, flags | MAP_SHARED,
+addr = mmap(addr, num << XC_PAGE_SHIFT, prot, flags |
On 14/05/2021 18:06, Julien Grall wrote:
Hi Juergen,
On 14/05/2021 10:01, Juergen Gross wrote:
The Makefile of xenstore and related to that the global .gitignore
file contain some leftovers from ancient times. Remove those.
While at it sort the tools/xenstore/* entries in .gitignore.
Signe
Hi Juergen,
On 17/05/2021 07:10, Juergen Gross wrote:
On 14.05.21 19:05, Julien Grall wrote:
Hi Juergen,
On 14/05/2021 12:56, Juergen Gross wrote:
The main loop of xenstored is rather complicated due to different
handling of socket and ring-page interfaces. Unify that handling by
introducing
flight 161979 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161979/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf d2e0c473e6f0d518e8acb187f99bb7e61f7df862
baseline version:
ovmf e0cb5e1814a67bb12dd47
flight 161980 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161980/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
flight 161976 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161976/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-freebsd11-amd64 16 guest-saverestore fail REGR. vs.
152631
test-amd64-i3
On 10.05.2021 17:47, Rahul Singh wrote:
> --- /dev/null
> +++ b/xen/drivers/passthrough/msi-intercept.c
> @@ -0,0 +1,55 @@
> +/*
> + * Copyright (C) 2008, Netronome Systems, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and condition
Hi Jan,
On 17/05/2021 08:01, Jan Beulich wrote:
On 12.05.2021 19:59, Julien Grall wrote:
Hi,
On 11/05/2021 07:37, Michal Orzel wrote:
On 05.05.2021 10:00, Jan Beulich wrote:
On 05.05.2021 09:43, Michal Orzel wrote:
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -
Hi Juergen,
On 17/05/2021 07:47, Juergen Gross wrote:
On 14.05.21 22:19, Julien Grall wrote:
Hi Juergen,
On 14/05/2021 09:41, Juergen Gross wrote:
Xenstored is absolutely mandatory for a Xen host and it can't be
restarted, so being killed by OOM-killer in case of memory shortage is
to be avoi
On 07.05.2021 13:04, Roger Pau Monne wrote:
> @@ -91,6 +91,21 @@ int x86_msr_copy_from_buffer(struct msr_policy *policy,
> const msr_entry_buffer_t msrs, uint32_t
> nr_entries,
> uint32_t *err_msr);
>
> +/**
> + * Get a MSR entry from a
Hi Jan,
On 17/05/2021 12:16, Jan Beulich wrote:
On 14.05.2021 20:53, Connor Davis wrote:
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -294,7 +294,9 @@ int guest_remove_page(struct domain *d, unsigned long gmfn)
p2m_type_t p2mt;
#endif
mfn_t mfn;
+#ifdef CONFIG_HAS_PASSTH
On 17.05.2021 17:22, Juergen Gross wrote:
> On 17.05.21 17:12, Jan Beulich wrote:
>> On 17.05.2021 16:23, Juergen Gross wrote:
>>> On 17.05.21 16:11, Jan Beulich wrote:
On 13.05.2021 12:02, Juergen Gross wrote:
> @@ -1574,10 +1580,16 @@ static irqreturn_t blkif_interrupt(int irq, void
>>>
On 13.05.2021 12:03, Juergen Gross wrote:
> @@ -429,6 +453,12 @@ static void xennet_tx_buf_gc(struct netfront_queue
> *queue)
> } while (more_to_do);
>
> xennet_maybe_wake_tx(queue);
> +
> + return;
> +
> + err:
> + queue->info->broken = true;
> + dev_alert(dev, "Disabled
On 17.05.21 17:12, Jan Beulich wrote:
On 17.05.2021 16:23, Juergen Gross wrote:
On 17.05.21 16:11, Jan Beulich wrote:
On 13.05.2021 12:02, Juergen Gross wrote:
@@ -1574,10 +1580,16 @@ static irqreturn_t blkif_interrupt(int irq, void
*dev_id)
spin_lock_irqsave(&rinfo->ring_lock, flags)
On 17.05.2021 16:23, Juergen Gross wrote:
> On 17.05.21 16:11, Jan Beulich wrote:
>> On 13.05.2021 12:02, Juergen Gross wrote:
>>> @@ -1574,10 +1580,16 @@ static irqreturn_t blkif_interrupt(int irq, void
>>> *dev_id)
>>> spin_lock_irqsave(&rinfo->ring_lock, flags);
>>>again:
>>> rp = r
On 13.05.2021 12:03, Juergen Gross wrote:
> In order to avoid a malicious backend being able to influence the local
> processing of a request build the request locally first and then copy
> it to the ring page. Any reading from the request needs to be done on
> the local instance.
"Any reading" is
On 17.05.21 16:20, Jan Beulich wrote:
On 13.05.2021 12:02, Juergen Gross wrote:
In order to avoid problems in case the backend is modifying a response
on the ring page while the frontend has already seen it, just read the
response into a local buffer in one go and then operate on that buffer
onl
On 5/17/21 8:13 AM, Jan Beulich wrote:
On 17.05.2021 15:48, Connor Davis wrote:
On 5/17/21 3:32 AM, Jan Beulich wrote:
On 14.05.2021 02:56, Connor Davis wrote:
Check if the debug capability is enabled in early_xdbc_parse_parameter,
and if it is, return with an error. This avoids collisions w
On 17.05.21 16:11, Jan Beulich wrote:
On 13.05.2021 12:02, Juergen Gross wrote:
@@ -1574,10 +1580,16 @@ static irqreturn_t blkif_interrupt(int irq, void
*dev_id)
spin_lock_irqsave(&rinfo->ring_lock, flags);
again:
rp = rinfo->ring.sring->rsp_prod;
+ if (RING_RESPONSE_PR
On 13.05.2021 12:02, Juergen Gross wrote:
> In order to avoid problems in case the backend is modifying a response
> on the ring page while the frontend has already seen it, just read the
> response into a local buffer in one go and then operate on that buffer
> only.
>
> Signed-off-by: Juergen Gr
On 17.05.2021 15:48, Connor Davis wrote:
>
> On 5/17/21 3:32 AM, Jan Beulich wrote:
>> On 14.05.2021 02:56, Connor Davis wrote:
>>> Check if the debug capability is enabled in early_xdbc_parse_parameter,
>>> and if it is, return with an error. This avoids collisions with whatever
>>> enabled the D
On 17.05.21 16:01, Jan Beulich wrote:
On 13.05.2021 12:02, Juergen Gross wrote:
In order to avoid a malicious backend being able to influence the local
copy of a request build the request locally first and then copy it to
the ring page instead of doing it the other way round as today.
Signed-of
On 13.05.2021 12:02, Juergen Gross wrote:
> @@ -1574,10 +1580,16 @@ static irqreturn_t blkif_interrupt(int irq, void
> *dev_id)
> spin_lock_irqsave(&rinfo->ring_lock, flags);
> again:
> rp = rinfo->ring.sring->rsp_prod;
> + if (RING_RESPONSE_PROD_OVERFLOW(&rinfo->ring, rp)) {
> +
On 13.05.2021 12:02, Juergen Gross wrote:
> In order to avoid a malicious backend being able to influence the local
> copy of a request build the request locally first and then copy it to
> the ring page instead of doing it the other way round as today.
>
> Signed-off-by: Juergen Gross
Reviewed-
On 5/17/21 5:16 AM, Jan Beulich wrote:
On 14.05.2021 20:53, Connor Davis wrote:
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -294,7 +294,9 @@ int guest_remove_page(struct domain *d, unsigned long gmfn)
p2m_type_t p2mt;
#endif
mfn_t mfn;
+#ifdef CONFIG_HAS_PASSTHROUGH
flight 161978 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161978/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf 5ead491e36af6cb8681fc1278bd36c756ad62ac2
baseline version:
xtf 880092854e5473558af772
On 13.05.2021 12:02, Juergen Gross wrote:
> In order to avoid problems in case the backend is modifying a response
> on the ring page while the frontend has already seen it, just read the
> response into a local buffer in one go and then operate on that buffer
> only.
>
> Signed-off-by: Juergen Gr
On 5/17/21 3:32 AM, Jan Beulich wrote:
On 14.05.2021 02:56, Connor Davis wrote:
Check if the debug capability is enabled in early_xdbc_parse_parameter,
and if it is, return with an error. This avoids collisions with whatever
enabled the DbC prior to linux starting.
Doesn't this go too far and
On 17.05.2021 15:40, Connor Davis wrote:
> On 5/17/21 3:27 AM, Jan Beulich wrote:
>> On 12.05.2021 02:12, Connor Davis wrote:
>>> --- a/docs/misc/xen-command-line.pandoc
>>> +++ b/docs/misc/xen-command-line.pandoc
>>> @@ -714,9 +714,26 @@ Available alternatives, with their meaning, are:
>>> ### d
On 5/17/21 3:36 AM, Julien Grall wrote:
Hi Connor,
On 12/05/2021 01:12, Connor Davis wrote:
+config XHCI_FIXMAP_PAGES
+ int "Number of fixmap entries to allocate for the xHC"
+ depends on HAS_XHCI_DBC
+ default 16
+ help
+ This should equal the size (in 4K pag
On 5/17/21 3:27 AM, Jan Beulich wrote:
On 12.05.2021 02:12, Connor Davis wrote:
Add support for the xHCI debug capability (DbC). The DbC provides
a SuperSpeed serial link between a debug target running Xen and a
debug host. To use it you will need a USB3 A/A debug cable plugged into
a root por
On 17.05.2021 15:20, Daniel Kiper wrote:
> On Mon, May 17, 2021 at 08:48:32AM +0200, Jan Beulich wrote:
>> On 07.05.2021 22:26, Bob Eshleman wrote:
>>> What is your intuition WRT the idea that instead of trying add a PE/COFF hdr
>>> in front of Xen's mb2 bin, we instead go the route of introducing
L3 entry updates aren't specified to take immediate effect in PAE mode:
On bare metal, only the next CR3 load actually loads the PDPTEs, and a
32-bit Xen also wouldn't immediately propagate new entries into the
PDPTEs. Them taking immediate effect (leaving aside the need to flush
the TLB) on 64-bit
On Mon, May 17, 2021 at 08:48:32AM +0200, Jan Beulich wrote:
> On 07.05.2021 22:26, Bob Eshleman wrote:
> > What is your intuition WRT the idea that instead of trying add a PE/COFF hdr
> > in front of Xen's mb2 bin, we instead go the route of introducing valid mb2
> > entry points into xen.efi?
>
>
On Wed, Apr 21, 2021 at 12:17:49PM +0200, Juergen Gross wrote:
> On 21.04.21 12:13, Wei Liu wrote:
> > On Mon, Apr 12, 2021 at 05:22:32PM +0200, Juergen Gross wrote:
> > > The core of a pv linux guest produced via "xl dump-core" is not usable
> > > as since kernel 4.14 only the linear p2m table is
flight 161973 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161973/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 20 guest-start/debianhvm.repeat
fail pass in 161964
Tests which d
On 14.05.2021 20:53, Connor Davis wrote:
> Defaulting to yes only for X86 and ARM reduces the requirements
> for a minimal build when porting new architectures.
While I agree with the statement, ...
> --- a/xen/drivers/char/Kconfig
> +++ b/xen/drivers/char/Kconfig
> @@ -1,6 +1,6 @@
> config HAS_
On 14.05.2021 20:53, Connor Davis wrote:
> --- /dev/null
> +++ b/config/riscv64.mk
> @@ -0,0 +1,5 @@
> +CONFIG_RISCV := y
> +CONFIG_RISCV_64 := y
> +CONFIG_RISCV_$(XEN_OS) := y
I wonder whether the last one actually gets used anywhere, but I do
realize that other architectures have similar definit
1 - 100 of 115 matches
Mail list logo
