On 03.05.2023 00:40, Jennifer Herbert wrote:
> On 02/05/2023 12:54, Jan Beulich wrote:
>> On 25.04.2023 19:47, Jennifer Herbert wrote:
>>> --- a/tools/firmware/hvmloader/util.c
>>> +++ b/tools/firmware/hvmloader/util.c
>>> @@ -994,13 +994,22 @@ void hvmloader_acpi_build_tables(struct acpi_config
>
On 03.05.2023 01:29, Jennifer Herbert wrote:
> On 02/05/2023 14:41, Jan Beulich wrote:
>> On 25.04.2023 19:47, Jennifer Herbert wrote:
>>> --- a/tools/libacpi/acpi2_0.h
>>> +++ b/tools/libacpi/acpi2_0.h
>>> @@ -121,6 +121,36 @@ struct acpi_20_tcpa {
>>> };
>>> #define ACPI_2_0_TCPA_LAML_SIZE (6
Hi,
Title: Did you mean "Enable spin table"?
On 02/05/2023 11:58, Ayan Kumar Halder wrote:
On some of the Arm32 based systems (eg Cortex-R52), smpboot is supported.
Same here.
In these systems PSCI may not always be supported. In case of Cortex-R52, there
is no EL3 or secure mode. Thus, PSC
Commit 68823df358e8 ("acpi: Re-license ACPI builder files from GPLv2 to
LGPLv2.1") added references to a "special exception on linking described
in file LICENSE", without actually adding such a file. Quite likely
COPYING was meant instead, yet then its text matches LICENSES/LGPL-2.1
except for some
Hi Stefano,
On 03/05/2023 00:55, Stefano Stabellini wrote:
+{
+printk("CPU%d: No release addr\n", cpu);
+return -ENODEV;
+}
+
+release = ioremap_nocache(cpu_release_addr[cpu], 4);
+if ( !release )
+{
+dprintk(XENLOG_ERR, "CPU%d: Unable to map release a
On 03.05.2023 01:36, Vikram Garhwal wrote:
> --- a/xen/include/xen/iommu.h
> +++ b/xen/include/xen/iommu.h
> @@ -214,6 +214,7 @@ struct msi_msg;
> #include
>
> int iommu_assign_dt_device(struct domain *d, struct dt_device_node *dev);
> +bool_t iommu_dt_device_is_assigned_locked(const struct dt
On 03.05.2023 01:36, Vikram Garhwal wrote:
> --- a/xen/include/xen/iommu.h
> +++ b/xen/include/xen/iommu.h
> @@ -219,6 +219,8 @@ int iommu_deassign_dt_device(struct domain *d, struct
> dt_device_node *dev);
> int iommu_dt_domain_init(struct domain *d);
> int iommu_release_dt_devices(struct domai
On 03/05/2023 8:45 am, Jan Beulich wrote:
> Commit 68823df358e8 ("acpi: Re-license ACPI builder files from GPLv2 to
> LGPLv2.1") added references to a "special exception on linking described
> in file LICENSE", without actually adding such a file. Quite likely
> COPYING was meant instead, yet then
On Tue, May 02, 2023 at 04:40:17PM +, Ross Lagerwall wrote:
> > From: Roger Pau Monne
> > Sent: Tuesday, May 2, 2023 4:57 PM
> > To: Ross Lagerwall
> > Cc: xen-devel@lists.xenproject.org ;
> > jgr...@suse.com ; sstabell...@kernel.org
> > ; oleksandr_tyshche...@epam.com
> > ; ax...@kernel.d
On 03.05.2023 01:36, Vikram Garhwal wrote:
> --- a/xen/include/public/sysctl.h
> +++ b/xen/include/public/sysctl.h
> @@ -1057,6 +1057,24 @@ typedef struct xen_sysctl_cpu_policy
> xen_sysctl_cpu_policy_t;
> DEFINE_XEN_GUEST_HANDLE(xen_sysctl_cpu_policy_t);
> #endif
>
> +#if defined(__arm__) ||
Am 02.05.2023 um 20:56 hat Stefan Hajnoczi geschrieben:
> On Tue, May 02, 2023 at 05:19:46PM +0200, Kevin Wolf wrote:
> > Am 25.04.2023 um 19:26 hat Stefan Hajnoczi geschrieben:
> > > Only report a transport reset event to the guest after the SCSIDevice
> > > has been unrealized by qdev_simple_devi
On 03.05.2023 01:36, Vikram Garhwal wrote:
> Introduce sysctl XEN_SYSCTL_dt_overlay to remove device-tree nodes added using
> device tree overlay.
>
> xl dt-overlay remove file.dtbo:
> Removes all the nodes in a given dtbo.
> First, removes IRQ permissions and MMIO accesses. Next, it finds
Hi Juergen,
On 03/05/2023 06:13, Juergen Gross wrote:
On 02.05.23 20:55, Julien Grall wrote:
Hi Juergen,
On 05/04/2023 08:03, Juergen Gross wrote:
Add the node accounting to the accounting information buffering in
order to avoid having to undo it in case of failure.
Signed-off-by: Juergen Gr
On 02.05.2023 16:59, Roger Pau Monne wrote:
> Ensure that the base address is 2M aligned, or else the page table
> entries created would be corrupt as reserved bits on the PDE end up
> set.
>
> We have encountered a broken firmware where grub2 would end up loading
> Xen at a non 2M aligned region
Am 02.05.2023 um 22:06 hat Stefan Hajnoczi geschrieben:
> On Tue, May 02, 2023 at 06:04:24PM +0200, Kevin Wolf wrote:
> > Am 25.04.2023 um 19:27 hat Stefan Hajnoczi geschrieben:
> > > vhost-user activity must be suspended during bdrv_drained_begin/end().
> > > This prevents new requests from interf
On 03.05.23 10:02, Julien Grall wrote:
Hi Juergen,
On 03/05/2023 06:13, Juergen Gross wrote:
On 02.05.23 20:55, Julien Grall wrote:
Hi Juergen,
On 05/04/2023 08:03, Juergen Gross wrote:
Add the node accounting to the accounting information buffering in
order to avoid having to undo it in cas
On Thu, Apr 06, 2023 at 05:57:23AM +0200, Marek Marczykowski-Górecki wrote:
> QEMU needs to know whether clearing maskbit of a vector is really
> clearing, or was already cleared before. Currently Xen sends only
> clearing that bit to the device model, but not setting it, so QEMU
> cannot detect it
> On 2 May 2023, at 17:13, Anthony PERARD wrote:
>
> On Mon, Apr 24, 2023 at 07:02:45AM +0100, Luca Fancellu wrote:
>> diff --git a/tools/include/xen-tools/arm-arch-capabilities.h
>> b/tools/include/xen-tools/arm-arch-capabilities.h
>> new file mode 100644
>> index ..ac44c8b14344
>
On Wed, May 03, 2023 at 10:08:20AM +0200, Jan Beulich wrote:
> On 02.05.2023 16:59, Roger Pau Monne wrote:
> > Ensure that the base address is 2M aligned, or else the page table
> > entries created would be corrupt as reserved bits on the PDE end up
> > set.
> >
> > We have encountered a broken fi
flight 180509 linux-linus real [real]
flight 180515 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/180509/
http://logs.test-lab.xenproject.org/osstest/logs/180515/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run
..., first and foremost by using cache write-back operations instead
of flushing (evicting) ones when available and sufficient for the
purpose.
In the context of making the last patch I started wondering whether
for PV we don't flush (write back) too little for MMUEXT_FLUSH_CACHE:
Just like for HV
The majority of the present callers really aren't after invalidating
cache contents, but only after writeback. Make this available by simply
extending the FLUSH_CACHE handling accordingly. No feature checks are
required here: cache_writeback() falls back to cache_flush() as
necessary, while WBNOINV
We allow its use for writeback purposes only anyway, so let's also carry
these out that way on capable hardware.
With it now known that WBNOINVD uses the same VM exit code as WBINVD for
both SVM and VT-x, we can now also expose the feature that way without
further distinguishing the specific cases
We allow its use for writeback purposes only anyway, so let's also carry
these out that way on capable hardware.
We can then also expose the WBNOINVD feature, as there's no difference
to WBINVD anymore. Note that respective emulation logic has already been
in place since ad3abc47dd23 ("x86emul: su
We don't need to invalidate caches here; all we're after is that earlier
writes have made it to main memory (and aiui even that just in case).
Signed-off-by: Jan Beulich
---
This, aiui, being an analogue to uses of iommu_sync_cache() (just not
range restricted), I wonder whether it shouldn't be c
This is to make the difference to FLUSH_CACHE_WRITEBACK more explicit.
Requested-by: Andrew Cooper
Signed-off-by: Jan Beulich
---
Note that this (of course) collides with "x86/HVM: restrict use of
pinned cache attributes as well as associated flushing".
---
v2: New.
--- a/xen/arch/x86/flushtlb.
There's no need to write back caches on all CPUs upon seeing a WBINVD
exit; ones that a vCPU hasn't run on since the last writeback (or since
it was started) can't hold data which may need writing back.
Signed-off-by: Jan Beulich
---
With us not running AMD IOMMUs in non-coherent ways, I wonder w
Hi Juergen,
On 05/04/2023 08:03, Juergen Gross wrote:
Add saving the maximum values of the different accounting data seen
per domain and (for unprivileged domains) globally, and print those
values via the xenstore-control quota command. Add a sub-command for
resetting the global maximum values s
On 05/04/2023 08:03, Juergen Gross wrote:
The maxrequests, node size, number of node permissions, and path length
quota are a little bit special, as they are either active in
transactions only (maxrequests), or they are just per item instead of
count values. Nevertheless being able to know the
On Tue, May 2, 2023 at 12:19 PM Jan Beulich wrote:
> On 28.04.2023 10:12, George Dunlap wrote:
> > --- a/SUPPORT.md
> > +++ b/SUPPORT.md
> > @@ -17,6 +17,36 @@ for the definitions of the support status levels etc.
> > Release Notes
> > : https://wiki.xenproject.org/wiki/Xen_Project_X.YY_Release
On 15.03.2023 15:58, Jan Beulich wrote:
> With in-tree builds Config.mk includes a .config file (if present) from
> the top-level directory. Similar functionality is wanted with out-of-
> tree builds. Yet the concept of "top-level directory" becomes fuzzy in
> that case, because there is not really
On 29.03.2023 12:20, Jan Beulich wrote:
> The 1st patch is new, addressing comments on the previously standalone
> (and unchanged) 2nd patch in a way different from what was discussed.
>
> 1: don't export building_out_of_srctree
> 2: omit "source" symlink when building hypervisor in-tree
Ping?
T
On 19.04.2023 16:31, Roger Pau Monne wrote:
> The usage of VCPU_SSHOTTMR_future in Linux prior to 4.7 is bogus.
> When the hypervisor returns -ETIME (timeout in the past) Linux keeps
> retrying to setup the timer with a higher timeout instead of
> self-injecting a timer interrupt.
>
> On boxes wit
On 04.04.2023 12:40, Jan Beulich wrote:
> On 04.04.2023 12:34, Andrew Cooper wrote:
>> On 04/04/2023 10:20 am, Jan Beulich wrote:
>>> --- a/xen/arch/arm/include/asm/irq.h
>>> +++ b/xen/arch/arm/include/asm/irq.h
>>> @@ -52,7 +52,7 @@ struct arch_irq_desc {
>>>
>>> extern const unsigned int nr_ir
Hi Juergen,
On 05/04/2023 08:03, Juergen Gross wrote:
Instead of having individual quota variables switch to a table based
approach like the generic accounting. Include all the related data in
the same table and add accessor functions.
This enables to use the command line --quota parameter for
On Wed, May 03, 2023 at 12:38:59PM +0200, Jan Beulich wrote:
> On 19.04.2023 16:31, Roger Pau Monne wrote:
> > The usage of VCPU_SSHOTTMR_future in Linux prior to 4.7 is bogus.
> > When the hypervisor returns -ETIME (timeout in the past) Linux keeps
> > retrying to setup the timer with a higher tim
Hi Jan,
On 04/04/2023 10:20, Jan Beulich wrote:
PHYSDEVOP_pirq_eoi_gmfn_v accepting just a single GFN implies that no
more than 32k pIRQ-s can be used by a domain on x86. Document this upper
bound.
To also enforce the limit, (ab)use both arch_hwdom_irqs() (changing its
parameter type) and setup
Hi Jan,
On 03/05/2023 11:43, Jan Beulich wrote:
On 04.04.2023 12:40, Jan Beulich wrote:
On 04.04.2023 12:34, Andrew Cooper wrote:
On 04/04/2023 10:20 am, Jan Beulich wrote:
--- a/xen/arch/arm/include/asm/irq.h
+++ b/xen/arch/arm/include/asm/irq.h
@@ -52,7 +52,7 @@ struct arch_irq_desc {
Hi,
On 28/04/2023 18:55, Ayan Kumar Halder wrote:
The DT functions (dt_read_number(), device_tree_get_reg(), fdt_get_mem_rsv())
currently accept or return 64-bit values.
In future when we support 32-bit physical address, these DT functions are
expected to accept/return 32-bit or 64-bit values (
Hi Ayan,
On 28/04/2023 18:55, Ayan Kumar Halder wrote:
dt_device_get_address() can accept uint64_t only for address and size.
However, the address/size denotes physical addresses. Thus, they should
be represented by 'paddr_t'.
Consequently, we introduce a wrapper for dt_device_get_address() ie
d
Am 02.05.2023 um 22:02 hat Stefan Hajnoczi geschrieben:
> On Tue, May 02, 2023 at 03:19:52PM +0200, Kevin Wolf wrote:
> > Am 01.05.2023 um 17:09 hat Stefan Hajnoczi geschrieben:
> > > On Fri, Apr 28, 2023 at 04:22:55PM +0200, Kevin Wolf wrote:
> > > > Am 25.04.2023 um 19:27 hat Stefan Hajnoczi gesc
On 06.04.2023 10:58, Viresh Kumar wrote:
> The strings won't be an exact match, as we are only looking to match the
> prefix here, i.e. "virtio,device". This is already done properly in
> libxl_virtio.c file, lets do the same here too.
>
> Fixes: 43ba5202e2ee ("libxl: add support for generic virti
Hi Ayan,
On 28/04/2023 18:55, Ayan Kumar Halder wrote:
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 239d3aed3c..192582b61d 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -19,13 +19,41 @@ config ARM
select HAS_PMAP
select IOMMU_FORCE_PT_SHARE
Hi Jan,
On 03/05/2023 12:42, Jan Beulich wrote:
On 06.04.2023 10:58, Viresh Kumar wrote:
The strings won't be an exact match, as we are only looking to match the
prefix here, i.e. "virtio,device". This is already done properly in
libxl_virtio.c file, lets do the same here too.
Fixes: 43ba5202e
Hi,
On 28/04/2023 18:55, Ayan Kumar Halder wrote:
In the callback functions invoked by dt_for_each_range() ie handle_pci_range(),
map_range_to_domain(), 'u64' should be replaced with 'uint64_t' as the data type
for the parameters.
Please explain why this needs to be replaced. I.e. Xen coding s
Hi,
On 28/04/2023 18:55, Ayan Kumar Halder wrote:
handle_pci_range() and map_range_to_domain() take addr and len as uint64_t
parameters. Then frame numbers are obtained from addr and len by right shifting
with PAGE_SHIFT. The frame numbers are expressed using unsigned long.
Now if 64-bit >> PAG
Hi,
On 28/04/2023 18:55, Ayan Kumar Halder wrote:
Restructure the code so that one can use pa_range_info[] table for both
ARM_32 as well as ARM_64.
Also, removed the hardcoding for P2M_ROOT_ORDER and P2M_ROOT_LEVEL as
p2m_root_order can be obtained from the pa_range_info[].root_order and
p2m_ro
On 03.05.2023 14:04, Julien Grall wrote:
> On 03/05/2023 12:42, Jan Beulich wrote:
>> On 06.04.2023 10:58, Viresh Kumar wrote:
>>> The strings won't be an exact match, as we are only looking to match the
>>> prefix here, i.e. "virtio,device". This is already done properly in
>>> libxl_virtio.c file
On 03/05/2023 13:20, Julien Grall wrote:
Hi,
On 28/04/2023 18:55, Ayan Kumar Halder wrote:
Restructure the code so that one can use pa_range_info[] table for both
ARM_32 as well as ARM_64.
Also, removed the hardcoding for P2M_ROOT_ORDER and P2M_ROOT_LEVEL as
p2m_root_order can be obtained f
Hi Juergen,
On 30/03/2023 09:49, Juergen Gross wrote:
Add some more verification of command line parameters.
Signed-off-by: Juergen Gross
---
tools/xenstore/xenstored_core.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/tools/xenstore/xenstored_cor
Hi Juergen,
On 30/03/2023 09:50, Juergen Gross wrote:
Do the following cleanups:
- hashtable_count() isn't used at all, so remove it
- replace prime_table_length and max_load_factor with macros
- make hash() static
- add a loadlimit() helper function
- remove the /***/ lines between functions
-
On 03.05.2023 14:37, GitLab wrote:
>
>
> Pipeline #855820014 has failed!
>
> Project: xen ( https://gitlab.com/xen-project/xen )
> Branch: staging ( https://gitlab.com/xen-project/xen/-/commits/staging )
>
> Commit: 0956aa22 (
> https://gitlab.com/xen-project/xen/-/commit/0956aa2219745a198bb6a
Hi Juergen,
On 30/03/2023 09:50, Juergen Gross wrote:
The minsize parameter of create_hashtable() doesn't have any real use
case for Xenstore, so drop it.
For better talloc_report_full() diagnostic output add a name parameter
to create_hashtable().
Signed-off-by: Juergen Gross
---
tools/xen
On 03/05/2023 1:59 pm, Jan Beulich wrote:
> On 03.05.2023 14:37, GitLab wrote:
>>
>> Pipeline #855820014 has failed!
>>
>> Project: xen ( https://gitlab.com/xen-project/xen )
>> Branch: staging ( https://gitlab.com/xen-project/xen/-/commits/staging )
>>
>> Commit: 0956aa22 (
>> https://gitlab.com/
Hi,
On 30/03/2023 09:50, Juergen Gross wrote:
Today hashtable_insert() returns 0 in case of an error. Change that to
let it return an errno value in the error case and 0 in case of success.
I usually find such change risky because it makes the backport more
complex if we introduce a new call
On Wed, May 03, 2023 at 01:40:49PM +0200, Kevin Wolf wrote:
> Am 02.05.2023 um 22:02 hat Stefan Hajnoczi geschrieben:
> > On Tue, May 02, 2023 at 03:19:52PM +0200, Kevin Wolf wrote:
> > > Am 01.05.2023 um 17:09 hat Stefan Hajnoczi geschrieben:
> > > > On Fri, Apr 28, 2023 at 04:22:55PM +0200, Kevin
Hi Juergen,
On 30/03/2023 09:50, Juergen Gross wrote:
The TODO file is not really helpful any longer. It contains only
entries which no longer apply or it is unknown what they are meant
for ("Dynamic/supply nodes", "Remove assumption that rename doesn't
fail").
Signed-off-by: Juergen Gross
A
Hi Juergen,
On 30/03/2023 09:50, Juergen Gross wrote:
struct watch contains an used struct list_head events. Remove it.
Typo: s/used/unused/?
Signed-off-by: Juergen Gross
Acked-by: Julien Grall
Cheers,
---
tools/xenstore/xenstored_watch.c | 5 -
1 file changed, 5 deletions(-)
On Wed, May 03, 2023 at 10:08:46AM +0200, Kevin Wolf wrote:
> Am 02.05.2023 um 22:06 hat Stefan Hajnoczi geschrieben:
> > On Tue, May 02, 2023 at 06:04:24PM +0200, Kevin Wolf wrote:
> > > Am 25.04.2023 um 19:27 hat Stefan Hajnoczi geschrieben:
> > > > vhost-user activity must be suspended during bd
On Wed, May 03, 2023 at 10:00:57AM +0200, Kevin Wolf wrote:
> Am 02.05.2023 um 20:56 hat Stefan Hajnoczi geschrieben:
> > On Tue, May 02, 2023 at 05:19:46PM +0200, Kevin Wolf wrote:
> > > Am 25.04.2023 um 19:26 hat Stefan Hajnoczi geschrieben:
> > > > Only report a transport reset event to the gues
Commit bf5e758f02fc ("genirq/msi: Simplify sysfs handling") reworked the
creation of sysfs entries for MSI IRQs. The creation used to be in
msi_domain_alloc_irqs_descs_locked after calling ops->domain_alloc_irqs.
Then it moved into __msi_domain_alloc_irqs which is an implementation of
domain_alloc_
Am 03.05.2023 um 15:11 hat Stefan Hajnoczi geschrieben:
> On Wed, May 03, 2023 at 10:08:46AM +0200, Kevin Wolf wrote:
> > Am 02.05.2023 um 22:06 hat Stefan Hajnoczi geschrieben:
> > > On Tue, May 02, 2023 at 06:04:24PM +0200, Kevin Wolf wrote:
> > > > Am 25.04.2023 um 19:27 hat Stefan Hajnoczi gesc
On 03/05/2023 12:25, Julien Grall wrote:
Hi Ayan,
Hi Julien,
On 28/04/2023 18:55, Ayan Kumar Halder wrote:
dt_device_get_address() can accept uint64_t only for address and size.
However, the address/size denotes physical addresses. Thus, they should
be represented by 'paddr_t'.
Consequently
Hello,
After what seems like an unreasonable amount of debugging, we've tracked
down exactly what is going wrong here.
https://gitlab.com/xen-project/people/andyhhp/xen/-/jobs/4219721944
Of note is the smoke.serial log around:
io: IN 0x90fec250 d0 20230503 14:20:42 INTRODUCE (1 233
flight 180517 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180517/
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
On 03.05.23 12:18, Julien Grall wrote:
On 05/04/2023 08:03, Juergen Gross wrote:
The maxrequests, node size, number of node permissions, and path length
quota are a little bit special, as they are either active in
transactions only (maxrequests), or they are just per item instead of
count valu
On 03.05.23 12:53, Julien Grall wrote:
Hi Juergen,
On 05/04/2023 08:03, Juergen Gross wrote:
Instead of having individual quota variables switch to a table based
approach like the generic accounting. Include all the related data in
the same table and add accessor functions.
This enables to use
On 03.05.23 14:59, Julien Grall wrote:
Hi Juergen,
On 30/03/2023 09:50, Juergen Gross wrote:
The minsize parameter of create_hashtable() doesn't have any real use
case for Xenstore, so drop it.
For better talloc_report_full() diagnostic output add a name parameter
to create_hashtable().
Signe
On 03.05.23 14:55, Julien Grall wrote:
Hi Juergen,
On 30/03/2023 09:50, Juergen Gross wrote:
Do the following cleanups:
- hashtable_count() isn't used at all, so remove it
- replace prime_table_length and max_load_factor with macros
- make hash() static
- add a loadlimit() helper function
- rem
On 03.05.23 15:03, Julien Grall wrote:
Hi,
On 30/03/2023 09:50, Juergen Gross wrote:
Today hashtable_insert() returns 0 in case of an error. Change that to
let it return an errno value in the error case and 0 in case of success.
I usually find such change risky because it makes the backport m
On 03.05.23 15:08, Julien Grall wrote:
Hi Juergen,
On 30/03/2023 09:50, Juergen Gross wrote:
struct watch contains an used struct list_head events. Remove it.
Typo: s/used/unused/?
Yes.
Signed-off-by: Juergen Gross
Acked-by: Julien Grall
Thanks,
Juergen
OpenPGP_0xB0DE9DD628B
On 30/03/2023 9:50 am, Juergen Gross wrote:
> +static void wrl_xfer_credit(wrl_creditt *debit, wrl_creditt debit_floor,
> + wrl_creditt *credit, wrl_creditt credit_ceil)
> + /*
> + * Transfers zero or more credit from "debit" to "credit".
> + * Transfers as mu
On 03.05.23 16:51, Andrew Cooper wrote:
On 30/03/2023 9:50 am, Juergen Gross wrote:
+static void wrl_xfer_credit(wrl_creditt *debit, wrl_creditt debit_floor,
+ wrl_creditt *credit, wrl_creditt credit_ceil)
+ /*
+* Transfers zero or more credit from "debit
clang complains about the signed type:
implicit truncation from 'int' to a one-bit wide bit-field changes value from 1
to -1 [-Wsingle-bit-bitfield-constant-conversion]
The potential ABI change in libxenvchan is covered by the Xen version based
SONAME.
The xenalyze change follows the existing
flight 180511 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180511/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-livepatch 7 xen-install fail in 180506 pass in 180511
test-amd64-i386-xl-vhd 21
In the pvcalls_new_active_socket() function, most error paths call
pvcalls_back_release_active(fedata->dev, fedata, map) which calls
sock_release() on "sock". The bug is that the caller also frees sock.
Fix this by making every error path in pvcalls_new_active_socket()
release the sock, and don't
o: IN 0x90fec250 d0 20230503 14:20:42 INTRODUCE (1 233473 1 )
obj: CREATE connection 0x90fff1f0
*** d1 CONN RESET req_cons , req_prod 003a rsp_cons
, rsp_prod
io: OUT 0x9105cef0 d0 20230503 14:20:42 WATCH_EVENT
(@introduceDomain domlist )
XS_INTRODUCE
note is the smoke.serial log around:
io: IN 0x90fec250 d0 20230503 14:20:42 INTRODUCE (1 233473 1 )
obj: CREATE connection 0x90fff1f0
*** d1 CONN RESET req_cons , req_prod 003a rsp_cons
, rsp_prod
io: OUT 0x9105cef0 d0 20230503 14:20:42 WATCH_
The 1st patch (new in v2) has the effect of the 2nd one no longer
affecting Arm.
1: restrict concept of pIRQ to x86
2: cmdline: document and enforce "extra_guest_irqs" upper bounds
Jan
... by way of a new arch-selectable Kconfig control.
Note that some smaller pieces of code are left without #ifdef, to keep
things better readable. Hence items like ECS_PIRQ, nr_static_irqs, or
domain_pirq_to_irq() remain uniformly.
Signed-off-by: Jan Beulich
---
I'm not really certain about XEN
PHYSDEVOP_pirq_eoi_gmfn_v accepting just a single GFN implies that no
more than 32k pIRQ-s can be used by a domain on x86. Document this upper
bound.
To also enforce the limit, (ab)use both arch_hwdom_irqs() (changing its
parameter type) and setup_system_domains(). This is primarily to avoid
expos
>>> tracked
>>> down exactly what is going wrong here.
>>>
>>> https://gitlab.com/xen-project/people/andyhhp/xen/-/jobs/4219721944
>>>
>>> Of note is the smoke.serial log around:
>>>
>>> io: IN 0x90fec250 d0 20230503 14:20:42
Since it was indicated that introducing specific new vCPU ops may be
beneficial independent of the introduction of a fully physical-
address-based ABI flavor, here we go. There continue to be a number of
open questions throughout the series, resolving of which was one of the
main goals of the earli
Before adding a new vCPU operation to register the runstate area by
guest-physical address, add code to actually keep such areas up-to-date.
Note that updating of the area will be done exclusively following the
model enabled by VMASST_TYPE_runstate_update_flag for virtual-address
based registered
In preparation of the introduction of new vCPU operations allowing to
register the respective areas (one of the two is x86-specific) by
guest-physical address, add the necessary domain cleanup hooks.
Signed-off-by: Jan Beulich
Reviewed-by: Julien Grall
---
RFC: Zapping the areas in pv_shim_shutd
Before adding a new vCPU operation to register the secondary time area
by guest-physical address, add code to actually keep such areas up-to-
date.
Note that pages aren't marked dirty when written to (matching the
handling of space mapped by map_vcpu_info()), on the basis that the
registrations ar
In preparation of the introduction of new vCPU operations allowing to
register the respective areas (one of the two is x86-specific) by
guest-physical address, add the necessary fork handling (with the
backing function yet to be filled in).
Signed-off-by: Jan Beulich
---
v3: Extend comment.
---
The registration by virtual/linear address has downsides: At least on
x86 the access is expensive for HVM/PVH domains. Furthermore for 64-bit
PV domains the areas are inaccessible (and hence cannot be updated by
Xen) when in guest-user mode, and for HVM guests they may be
inaccessible when Meltdown
The registration by virtual/linear address has downsides: The access is
expensive for HVM/PVH domains. Furthermore for 64-bit PV domains the area
is inaccessible (and hence cannot be updated by Xen) when in guest-user
mode.
Introduce a new vCPU operation allowing to register the secondary time
are
The registration by virtual/linear address has downsides: At least on
x86 the access is expensive for HVM/PVH domains. Furthermore for 64-bit
PV domains the area is inaccessible (and hence cannot be updated by Xen)
when in guest-user mode.
Introduce a new vCPU operation allowing to register the ru
Switch to using map_guest_area(). Noteworthy differences from
map_vcpu_info():
- remote vCPU-s are paused rather than checked for being down (which in
principle can change right after the check),
- the domain lock is taken for a much smaller region,
- the error code for an attempt to re-register
Also it was added explanation about ignoring of top VA bits
Signed-off-by: Oleksii Kurochko
---
Changes in V6:
- update comment above the RISCV-64 layout table
- add Slot column to the table with RISCV-64 Layout
- update RV-64 layout table.
---
Changes in V5:
* the patch was introduced in the
The patch does two thing:
1. Setup initial pagetables.
2. Enable MMU which end up with code in
cont_after_mmu_is_enabled()
Signed-off-by: Oleksii Kurochko
---
Changes in V6:
- Nothing changed. Only rebase
---
Changes in V5:
- Nothing changed. Only rebase
---
Changes in V4:
- Nothing changed
The patch series introduces the following things:
1. Functionality to build the page tables for Xen that map
link-time to physical-time location.
2. Check that Xen is less then page size.
3. Check that load addresses don't overlap with linker addresses.
4. Prepare things for proper switch to vir
The idea was taken from xvisor but the following changes
were done:
* Use only a minimal part of the code enough to enable MMU
* rename {_}setup_initial_pagetables functions
* add an argument for setup_initial_mapping to have
an opportunity to make set PTE flags.
* update setup_initial_pagetables
After introduction of initial pagetables there is no any sense
in dummy_bss variable as bss section will not be empty anymore.
Signed-off-by: Oleksii Kurochko
---
Changes in V6:
- Nothing changed. Only rebase
---
Changes in V5:
- Nothing changed. Only rebase
---
Changes in V4:
- Nothing change
On Tue, May 02, 2023 at 12:13:36PM +0100, Alejandro Vallejo wrote:
> diff --git a/tools/libs/light/libxl_domain.c b/tools/libs/light/libxl_domain.c
> index 7f0986c185..5709b3e62f 100644
> --- a/tools/libs/light/libxl_domain.c
> +++ b/tools/libs/light/libxl_domain.c
> @@ -349,16 +349,12 @@ int libxl
On 03/05/2023 08:40, Julien Grall wrote:
Hi,
Hi Julien,
Title: Did you mean "Enable spin table"?
Yes, that would be more concrete.
On 02/05/2023 11:58, Ayan Kumar Halder wrote:
On some of the Arm32 based systems (eg Cortex-R52), smpboot is
supported.
Same here.
Yes
In these systems
On Tue, May 02, 2023 at 12:13:37PM +0100, Alejandro Vallejo wrote:
> diff --git a/tools/libs/light/libxl_x86_acpi.c
> b/tools/libs/light/libxl_x86_acpi.c
> index 22eb160659..796b009d0c 100644
> --- a/tools/libs/light/libxl_x86_acpi.c
> +++ b/tools/libs/light/libxl_x86_acpi.c
> @@ -87,14 +87,14 @@
On Tue, May 02, 2023 at 12:13:38PM +0100, Alejandro Vallejo wrote:
> It previously mimicked the getdomaininfo sysctl semantics by returning
> the first domid higher than the requested domid that does exist. This
> unintuitive behaviour causes quite a few mistakes and makes the call
> needlessly slo
1 - 100 of 127 matches
Mail list logo
