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
@@ -267,10 +267,10 @@ struct vc
On 14.05.2021 17:29, Roger Pau Monné wrote:
> On Thu, Apr 22, 2021 at 10:53:05AM +0200, Jan Beulich wrote:
>> On 21.04.2021 17:56, Julien Grall wrote:
>>>
>>>
>>> On 21/04/2021 16:23, Jan Beulich wrote:
On 27.01.2021 09:13, Jan Beulich wrote:
> These are grouped into a series largely becau
On 11.05.2021 18:41, Andrew Cooper wrote:
> On 03/05/2021 15:22, Jan Beulich wrote:
>>> Another consequence is that we need to rethink our hypercall behaviour.
>>> There is no such thing as supervisor states in an uncompressed XSAVE
>>> image, which means we can't continue with that being the ABI.
flight 161972 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161972/
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 13.05.2021 22:15, Andrew Cooper wrote:
> On 13/05/2021 04:56, osstest service owner wrote:
>> Tests which are failing intermittently (not blocking):
>> test-xtf-amd64-amd64-3 92 xtf/test-pv32pae-xsa-286 fail in 161909 pass in
>> 161917
>
> While noticing the ARM issue above, I also spotted th
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 port on the target machine. Recent kern
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 prevent use even if firmware (perhaps
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 pages) of the first 64-bit
+ BAR o
On 12.05.2021 18:48, Juergen Gross wrote:
> Add a new RING_RESPONSE_PROD_OVERFLOW() macro for being able to
> detect an ill-behaved backend tampering with the response producer
> index.
>
> Signed-off-by: Juergen Gross
Acked-by: Jan Beulich
> --- a/xen/include/public/io/ring.h
> +++ b/xen/incl
On 13.05.2021 12:24, Olaf Hering wrote:
> Recent pvops dom0 kernels fail to boot on this particular ProLiant BL465c G5
> box.
> It happens to work with every Xen and a 4.4 based sle12sp3 kernel, but fails
> with every Xen and a 4.12 based sle12sp4 (and every newer) kernel.
>
> Any idea what is g
flight 161974 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161974/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf e0cb5e1814a67bb12dd476a72d1698350633bcbb
baseline version:
ovmf 32928415e36b3e234efb5
On 17.05.2021 10:43, Jan Beulich wrote:
> On 13.05.2021 22:15, Andrew Cooper wrote:
>> Second, the unexplained OSSTest behaviour.
>>
>> When I repro'd this on pinot1, test-pv32pae-xsa-286 failing was totally
>> deterministic and repeatable (I tried 100 times because the test is a
>> fraction of a s
On 14.05.2021 15:50, Roger Pau Monne wrote:
> @@ -426,7 +426,7 @@ static elf_errorstatus elf_xen_addr_calc_check(struct
> elf_binary *elf,
> }
>
> /* Initial guess for virt_base is 0 if it is not explicitly defined. */
> -if ( parms->virt_base == UNSET_ADDR )
> +if ( parms->vir
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
> bool *dont_flush_p, dont_
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 be visible outside of this
> defini
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
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_
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 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
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?
>
>
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 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
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 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 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: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 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
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 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
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 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 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 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 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.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 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: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 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.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 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 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.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
>>>
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 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 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
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
@@ -
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
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
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 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
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
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 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 |
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
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
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 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
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 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
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
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
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
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
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 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
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 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 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 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 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 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 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
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
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
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
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.
Do
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
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_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
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
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
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
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
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
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
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
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
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
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: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
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
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
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 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
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
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
1 - 100 of 115 matches
Mail list logo
