On 09.11.2023 19:27, Stewart Hildebrand wrote:
> --- a/xen/include/xen/iommu.h
> +++ b/xen/include/xen/iommu.h
> @@ -245,6 +245,8 @@ int iommu_do_dt_domctl(struct xen_domctl *domctl, struct
> domain *d,
> */
> int iommu_remove_dt_device(struct dt_device_node *np);
>
> +#define NO_IOMMU1
>
On 09.11.2023 19:27, Stewart Hildebrand wrote:
> From: Oleksandr Tyshchenko
>
> The main purpose of this patch is to add a way to register PCI device
> (which is behind the IOMMU) using the generic PCI-IOMMU DT bindings [1]
> before assigning that device to a domain.
>
> This behaves similarly t
Add missing parameter names to address violations of
MISRA C:2012 Rule 8.2.
Resolve mismatches between parameter name "count" used in
"xen/lib/mem{cpy,move,set}.c" and parameter name "n" used in
"xen/arch/x86/string.c" to address violations of MISRA C:2012 Rule 8.3.
No functional change.
Signed-
On 09.11.2023 19:27, Stewart Hildebrand wrote:
> --- a/xen/drivers/pci/physdev.c
> +++ b/xen/drivers/pci/physdev.c
> @@ -18,9 +18,6 @@ ret_t pci_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void)
> arg)
> struct pci_dev_info pdev_info;
> nodeid_t node = NUMA_NO_NODE;
>
> -
Hi Luca,
On 09/11/2023 10:06, Luca Fancellu wrote:
>
>
> Introduce a Kconfig for the dom0less feature, enabled by default,
> to be able to choose if the feature should be compiled or not.
>
> Provide static inline stubs when the option is disabled for the
> functions externally visible.
>
> Us
Hi Stefano,
On 10/11/2023 00:29, Stefano Stabellini wrote:
On Thu, 9 Nov 2023, Julien Grall wrote:
On 09/11/2023 07:42, Jan Beulich wrote:
On 08.11.2023 14:33, Julien Grall wrote:
Hi Jan,
On 08/11/2023 11:19, Jan Beulich wrote:
On 08.11.2023 12:03, Nicola Vetrini wrote:
On 2023-11-08 09:24
Hi Michal,
>>
>> +config DOM0LESS_BOOT
>> + bool "Dom0less boot support" if EXPERT
>> + depends on ARM
> You're in the Arm Kconfig, so there should be no need for this dependency (it
> is implicit).
>
> Apart from that, we have 2 features: static mem and static shmem that are
> onl
On Thu, 2023-11-09 at 18:40 +0100, Thomas Huth wrote:
> Let's improve the wording here.
>
> Signed-off-by: Thomas Huth
Absolutely, but please can we change it in Xen first because these
headers are a direct import.
Acked-by: David Woodhouse
> ---
> include/hw/xen/interface/hvm/params.h | 2 +
On Fri, 2023-11-10 at 08:31 +0100, Philippe Mathieu-Daudé wrote:
>
> > + pci_dev = pci_new(devfn, model);
> > + qdev_set_nic_properties(&pci_dev->qdev, nd);
> > + pci_realize_and_unref(pci_dev, bus, &error_fatal);
>
> Could these functions be used with hotplug devices?
>
> If so we shou
Hi Stefano,
On 10/11/2023 01:44, Stefano Stabellini wrote:
Reported-by: Brian Woods
Signed-off-by: Stefano Stabellini
diff --git a/scripts/uboot-script-gen b/scripts/uboot-script-gen
index b284887..6e52da5 100755
--- a/scripts/uboot-script-gen
+++ b/scripts/uboot-script-gen
@@ -790,7 +790,7 @
On Fri, 2023-11-10 at 08:40 +0100, Philippe Mathieu-Daudé wrote:
> Hi David,
>
> +Markus/Bernhard
>
> On 6/11/23 20:49, David Woodhouse wrote:
> > From: David Woodhouse
> >
> > Eliminate direct access to nd_table[] and nb_nics by processing the the
> > Xen and ISA NICs first and then calling pc
Hi all,
On Tue, 2023-10-31 at 12:12 +0200, Oleksii Kurochko wrote:
> only declares udelay() function so udelay()
> declaration was moved to xen/delay.h.
>
> For x86, __udelay() was renamed to udelay() and removed
> inclusion of in x86 code.
>
> Signed-off-by: Oleksii Kurochko
> ---
> xen/a
> On 10 Nov 2023, at 09:05, Luca Fancellu wrote:
>
> Hi Michal,
>
>>>
>>> +config DOM0LESS_BOOT
>>> + bool "Dom0less boot support" if EXPERT
>>> + depends on ARM
>> You're in the Arm Kconfig, so there should be no need for this dependency
>> (it is implicit).
>>
>> Apart from th
Hi all,
On Tue, 2023-10-31 at 16:28 +0200, Oleksii Kurochko wrote:
> only declares udelay() function so udelay()
> declaration was moved to xen/delay.h.
>
> For x86, __udelay() was renamed to udelay() and removed
> inclusion of in x86 code.
>
> For ppc, udelay() stub definition was moved to pp
On 09.11.2023 18:40, Thomas Huth wrote:
> --- a/include/hw/xen/interface/hvm/params.h
> +++ b/include/hw/xen/interface/hvm/params.h
> @@ -255,7 +255,7 @@
> * Note that 'mixed' mode has not been evaluated for safety from a
> * security perspective. Before using this mode in a
> * security-cri
Hi all,
On Wed, 2023-11-01 at 12:15 +0200, Oleksii Kurochko wrote:
> Platforms which doesn't have HAS_PCI enabled it is needed to
> have , which contains only an empty definition of
> struct arch_pci_dev ( except ARM, it introduces several
> ARM-specific functions ).
>
> Also, for architectures (
On 10.11.2023 10:30, Oleksii wrote:
> On Tue, 2023-10-31 at 16:28 +0200, Oleksii Kurochko wrote:
>> only declares udelay() function so udelay()
>> declaration was moved to xen/delay.h.
>>
>> For x86, __udelay() was renamed to udelay() and removed
>> inclusion of in x86 code.
>>
>> For ppc, udelay
On 10.11.2023 10:30, Oleksii wrote:
> I forgot to update xen/arch/{arm,ppc}/include/asm/Makefile:
> generic-y += pci.h
>
> Should I send a new patch version or it can be updated durig merge?
See the reply regarding delay.h.
Jan
On 10/11/2023 10.30, Jan Beulich wrote:
On 09.11.2023 18:40, Thomas Huth wrote:
--- a/include/hw/xen/interface/hvm/params.h
+++ b/include/hw/xen/interface/hvm/params.h
@@ -255,7 +255,7 @@
* Note that 'mixed' mode has not been evaluated for safety from a
* security perspective. Before usin
Hi,
On 10/11/2023 10:30, Luca Fancellu wrote:
>
>
>> On 10 Nov 2023, at 09:05, Luca Fancellu wrote:
>>
>> Hi Michal,
>>
+config DOM0LESS_BOOT
+ bool "Dom0less boot support" if EXPERT
+ depends on ARM
>>> You're in the Arm Kconfig, so there should be no need for t
> On 10 Nov 2023, at 09:38, Michal Orzel wrote:
>
> Hi,
>
> On 10/11/2023 10:30, Luca Fancellu wrote:
>>
>>
>>> On 10 Nov 2023, at 09:05, Luca Fancellu wrote:
>>>
>>> Hi Michal,
>>>
>
> +config DOM0LESS_BOOT
> + bool "Dom0less boot support" if EXPERT
> + depen
On Mon, Oct 9, 2023 at 3:23 PM Federico Serafini
wrote:
>
> Add missing parameter names. No functional change.
>
> Signed-off-by: Federico Serafini
Acked-by: George Dunlap
Sorry for the delay.
Hi Julien,
On 10/11/2023 10:27, Julien Grall wrote:
>
>
> Hi Stefano,
>
> On 10/11/2023 01:44, Stefano Stabellini wrote:
>> Reported-by: Brian Woods
>> Signed-off-by: Stefano Stabellini
>>
>> diff --git a/scripts/uboot-script-gen b/scripts/uboot-script-gen
>> index b284887..6e52da5 100755
>>
On 10/11/2023 10:01, Michal Orzel wrote:
Hi Julien,
On 10/11/2023 10:27, Julien Grall wrote:
Hi Stefano,
On 10/11/2023 01:44, Stefano Stabellini wrote:
Reported-by: Brian Woods
Signed-off-by: Stefano Stabellini
diff --git a/scripts/uboot-script-gen b/scripts/uboot-script-gen
index b28
On Fri, 2023-11-10 at 10:33 +0100, Jan Beulich wrote:
> On 10.11.2023 10:30, Oleksii wrote:
> > On Tue, 2023-10-31 at 16:28 +0200, Oleksii Kurochko wrote:
> > > only declares udelay() function so udelay()
> > > declaration was moved to xen/delay.h.
> > >
> > > For x86, __udelay() was renamed to u
On Fri, 2023-11-10 at 10:30 +0100, Jan Beulich wrote:
> On 09.11.2023 18:40, Thomas Huth wrote:
> > --- a/include/hw/xen/interface/hvm/params.h
> > +++ b/include/hw/xen/interface/hvm/params.h
> > @@ -255,7 +255,7 @@
> > * Note that 'mixed' mode has not been evaluated for safety from a
> > * sec
flight 183726 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183726/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 6 xen-buildfail REGR. vs. 183718
Tests which did no
On 10/11/2023 10:08, Julien Grall wrote:
On 10/11/2023 10:01, Michal Orzel wrote:
Hi Julien,
On 10/11/2023 10:27, Julien Grall wrote:
Hi Stefano,
On 10/11/2023 01:44, Stefano Stabellini wrote:
Reported-by: Brian Woods
Signed-off-by: Stefano Stabellini
diff --git a/scripts/uboot-scr
Update ECLAIR configuration to take into account the standard search
procedure adopted by Unix linkers.
Signed-off-by: Federico Serafini
---
automation/eclair_analysis/ECLAIR/deviations.ecl | 9 +
1 file changed, 9 insertions(+)
diff --git a/automation/eclair_analysis/ECLAIR/deviations.
This small patch series is doing some preparations for being able to
use 9pfs in Xenstore-stubdom.
Changes in V2:
- added patches 2 and 5
Juergen Gross (5):
Mini-OS: make xenstore_buf externally visible
Mini-OS: get own domid
Mini-OS: don't crash if no shutdown node is available
Mini-OS:
Get the own domid via creation of a temporary event channel. There is
no "official" way to read the own domid in PV guests, so use the event
channel interface to get it:
- allocate an unbound event channel specifying DOMID_SELF for the
other end
- read the event channel status which will contai
For support of the 9pfs frontend in Xenstore-stubdom xenstore_buf
needs to be externally visible.
Signed-off-by: Juergen Gross
Reviewed-by: Jason Andryuk
---
include/xenbus.h | 2 ++
xenbus.c | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/xenbus.h b/includ
The format string of the received data for the 9pfs stat command is
missing the initial 2 byte total length specifier. Add it.
Fixes: 2d1dfccd3aa3 ("Mini-OS: add read and write support to 9pfsfront")
Signed-off-by: Juergen Gross
Reviewed-by: Jason Andryuk
---
9pfront.c | 9 +
1 file cha
It might be perfectly fine not to have a control/shutdown Xenstore
node. If this is the case, don't crash, but just terminate the
shutdown thread after issuing a message that shutdown isn't available.
In fini_shutdown() clearing the watch can result in an error now, in
case the early exit above wa
When copying a 9pfs response chunk from the ring buffer across the
ring end, the local ring pointer and length field are not updated
correctly. Fix that.
Fixes: 0924fec1de58 ("Mini-OS: add 9pfs transport layer")
Signed-off-by: Juergen Gross
---
V2:
- new patch
---
9pfront.c | 4 +++-
1 file chan
On Fri, Nov 10, 2023 at 12:34:32PM +0100, Juergen Gross wrote:
> Get the own domid via creation of a temporary event channel. There is
> no "official" way to read the own domid in PV guests, so use the event
> channel interface to get it:
>
> - allocate an unbound event channel specifying DOMID_SE
On 10.11.23 13:23, Roger Pau Monné wrote:
On Fri, Nov 10, 2023 at 12:34:32PM +0100, Juergen Gross wrote:
Get the own domid via creation of a temporary event channel. There is
no "official" way to read the own domid in PV guests, so use the event
channel interface to get it:
- allocate an unboun
On 10.11.2023 12:23, Federico Serafini wrote:
> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> @@ -214,6 +214,15 @@ definition is compiled-out or optimized-out by the
> compiler)"
> -config=MC3R1.R8.6,reports+={deliberate, "first_
On 10.11.2023 13:23, Roger Pau Monné wrote:
> On Fri, Nov 10, 2023 at 12:34:32PM +0100, Juergen Gross wrote:
>> Get the own domid via creation of a temporary event channel. There is
>> no "official" way to read the own domid in PV guests, so use the event
>> channel interface to get it:
>>
>> - all
Remove !NEW_VGIC dependency from GICV3 config and add new GICv3 files to
the build system.
Signed-off-by: Mykyta Poturai
---
xen/arch/arm/Kconfig | 1 -
xen/arch/arm/vgic/Makefile | 2 ++
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kcon
The LPI pending status for a GICv3 redistributor is held in a table
in (guest) memory. To achieve reasonable performance, we cache the
pending bit in our struct vgic_irq. The initial pending state must be
read from guest memory upon enabling LPIs for this redistributor.
As we can't access the guest
Guests DT creation requires redist regions to be stored in the specific
variables in struct vgic_dist. But in new VGIC a linked list is used for
that. To not clutter the DT creation code with ifdefs, add alternative
storage for redist regions in struct vgic_dist.
Signed-off-by: Mykyta Poturai
---
As the GICv3 virtual interface registers differ from their GICv2
siblings, we need different handlers for processing maintenance
interrupts and reading/writing to the LRs.
Implement the respective handler functions and connect them to
existing code to be called if the host is using a GICv3.
This i
Currently the full register address is used in VGIC MMIO handlers. This
can cause issues when VGIC_ADDR_TO_IRQ_MASK overlaps with the base address.
For example the current GUEST_GICV3_GICD_BASE overlaps with addr to irq
mask for 64 bit registers, causing intids to be calculated incorrectly.
This p
Add emulation for some basic MMIO registers used in the ITS emulation.
This includes:
- GITS_{CTLR,TYPER,IIDR}
- ID registers
- GITS_{CBASER,CREADR,CWRITER}
(which implement the ITS command buffer handling)
- GITS_BASER
The registers holding base addresses and attributes are sanitised before
stori
We implement the only one ID register that is required by the
architecture, also this is the one that Linux actually checks.
Based on Linux commit 54f59d2b3a0a3d by Andre Przywara
Signed-off-by: Mykyta Poturai
---
xen/arch/arm/vgic/vgic-mmio-v3.c | 17 +++--
1 file changed, 15 inser
Implement handling of the ITS INT command.
With the help of the IO bus framework we learn the corresponding
ITS from the doorbell address. We then use our wrapper functions to
iterate the linked lists and find the proper Interrupt Translation Table
Entry (ITTE) and thus the corresponding struct vgi
In contrast to GICv2 SGIs in a GICv3 implementation are not triggered
by a MMIO write, but with a system register write. Xen knows about
that register already, we just need to implement the handler and wire
it up to the core Xen/ARM code.
Base on Linux commit 621ecd8d2123bc13 by Andre Przywara
Si
HW its directly uses struct pending_irq which makes it hard to swich to
a different VITS implementation if it doesn't use the same structure.
Rename struct its_device to struct vgic_its_device and move it to vgic.h,
so it can be defined by the VITS implementation. Add helper functions to
allow HW
Since GICv4.1, it has become legal for an implementation to advertise
GICR_{INVLPIR,INVALLR,SYNCR} while having an ITS, allowing for a more
efficient invalidation scheme (no guest command queue contention when
multiple CPUs are generating invalidations).
Provide the invalidation registers as a pri
Now that all ITS emulation functionality is in place, we advertise
the ITS device to the guest.
Based on Linux commit 0e4e82f154e38 by Andre Przywara
Signed-off-by: Mykyta Poturai
---
xen/arch/arm/vgic/vgic-init.c| 7 +
xen/arch/arm/vgic/vgic-its.c | 2 +-
xen/arch/arm/vgic/vgic-m
map_resources is the last initialization step needed before the first
VCPU is run. At that stage the code stores the MMIO base addresses used.
Also it registers the respective register frames with the MMIO framework.
This is based on Linux commit b0442ee227e826af by Eric Auger
Signed-off-by: Myky
The ARM GICv3 ITS emulation code goes into a separate file, but needs
to be connected to the GICv3 emulation, of which it is an option.
The ITS MMIO handlers require the respective ITS pointer to be passed in,
so we amend the existing VGIC MMIO framework to let it cope with that.
Also we introduce
Create a new file called vgic-mmio-v3.c and describe the GICv3
distributor and redistributor registers there.
Also we provide a function to deal with the registration of the
separate redistributor frames per VCPU and allocation of redistributor
regions.
Based on Linux commits:
ed9b8cefa91695 by An
Add the basic data structure that expresses an MSI to LPI
translation as well as the allocation/release hooks.
Implement cache invalidation, lookup and storage.
The size of the cache is arbitrarily defined as 16*nr_vcpus.
This is based on Linux commits 24cab82c34aa6f, 7d825fd6eaa7467,
89489ee9ce
Add the vgic_its_device structure and the list of devices to the vgic_its.
Implement the functions to allocate, free, add and delete the device from
the list. Add the function to find the device in the list by the device id.
And make them avaliable to the HW ITS code.
Signed-off-by: Mykyta Poturai
The (system-wide) LPI configuration table is held in a table in
(guest) memory. To achieve reasonable performance, we cache this data
in our struct vgic_irq. If the guest updates the configuration data
(which consists of the enable bit and the priority value), it issues
an INV or INVALL command to
The redistributor TYPER tells the OS about the associated MPIDR,
also the LAST bit is crucial to determine the number of redistributors.
Based on Linux commit 741972d8a69ce74 by Andre Przywara
Signed-off-by: Mykyta Poturai
---
xen/arch/arm/vgic/vgic-mmio-v3.c | 65 ++
Since GICv3 supports much more than the 8 CPUs the GICv2 ITARGETSR
register can handle, the new IROUTER register covers the whole range
of possible target (V)CPUs by using the same MPIDR that the cores
report themselves.
In addition to translating this MPIDR into a vcpu pointer we store
the origina
Add vgic-its.o to the build system.
Remove the dependency on !NEW_VGIC from CONFIG_HAS_ITS.
Signed-off-by: Mykyta Poturai
---
xen/arch/arm/Kconfig | 4 ++--
xen/arch/arm/vgic/Makefile | 1 +
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/
Hi All.
This series aims to add GICv3 support to the New VGIC. It adds support for
the GICv3 distributor, redistributor, sysreg and ITS interfaces. This will
allow Xen to emulate level-triggered interrupts with GICv3 and will make
the NEW_VGIC more complete and usable.
The series also introduces
As in the GICv2 emulation we handle those three registers in one
function.
Based on Linux commit fd59ed3be17e41 by Andre Przywara
Signed-off-by: Mykyta Poturai
---
xen/arch/arm/include/asm/gic_v3_defs.h | 2 +
xen/arch/arm/vgic/vgic-mmio-v3.c | 71 +-
xen/arch/arm
The connection between a device, an event ID, the LPI number and the
associated CPU is stored in in-memory tables in a GICv3, but their
format is not specified by the spec. Instead software uses a command
queue in a ring buffer to let an ITS implementation use its own
format.
Implement handlers for
In the GICv3 redistributor there are the PENDBASER and PROPBASER
registers which we did not emulate so far, as they only make sense
when having an ITS. In preparation for that emulate those MMIO
accesses by storing the 64-bit data written into it into a variable
which we later read in the ITS emula
Enable the VGIC operation by properly initialising the registers
in the hypervisor GIC interface.
This is based on Linux commit f7b6985cc3d0f by Eric Auger
Signed-off-by: Mykyta Poturai
---
xen/arch/arm/vgic/vgic-init.c | 5 +
xen/arch/arm/vgic/vgic-v3.c | 6 ++
xen/arch/arm/vgic/vgic
Add some optional additional backend paths for 9pfs PV devices. Those
paths will be supported by the new xenlogd 9pfs backend.
Signed-off-by: Juergen Gross
---
xen/include/public/io/9pfs.h | 34 ++
1 file changed, 34 insertions(+)
diff --git a/xen/include/public/
Add the code for connecting to frontends to xenlogd.
Signed-off-by: Juergen Gross
---
V2:
- support multiple rings per device (Jason Andryuk)
- don't set .revents initially (Jason Andryuk)
- call poll() with infinite timeout (Jason Andryuk)
- take mutex before calling pthread_cond_signal()
---
t
Add support for generation a 9pfs protocol response via a format based
approach.
Strings are stored in a per device string buffer and they are
referenced via their offset in this buffer. This allows to avoid
having to dynamically allocate memory for each single string.
As a first user of the resp
Add the attach request of the 9pfs protocol. This introduces the "fid"
scheme of the 9pfs protocol.
As this will be needed later, use a dedicated memory allocation
function in alloc_fid() and prepare a fid reference count.
For filling the qid data take the approach from the qemu 9pfs backend
impl
This series is adding 9pfs support to Xenstore-stubdom, enabling it
to do logging to a dom0 directory.
This is a prerequisite for the final goal to add live update support
to Xenstore-stubdom, as it enables the stubdom to store its state in
a dom0 file.
The 9pfs backend is a new daemon written fr
Add "xen-9pfsd", a new logging daemon meant to support infrastructure
domains (e.g. xenstore-stubdom) to access files in dom0.
For now only add the code needed for starting the daemon and
registering it with Xenstore via a new "libxl/xen-9pfs/state" node by
writing the "running" state to it.
Sign
Add the transport layer of 9pfs. This is basically the infrastructure
to receive requests from the frontend and to send the related answers
via the rings.
In order to avoid unaligned accesses e.g. on Arm, add the definition of
__packed to the common-macros.h header.
Signed-off-by: Juergen Gross
Add the open request of the 9pfs protocol.
Signed-off-by: Juergen Gross
---
V2:
- don't allow to open symbolic link
---
tools/xen-9pfsd/io.c| 144
tools/xen-9pfsd/xen-9pfsd.h | 4 +
2 files changed, 148 insertions(+)
diff --git a/tools/xen-9pfsd/io
Add the walk request of the 9pfs protocol.
Signed-off-by: Juergen Gross
---
V2:
- don't allow walking across symbolic links
---
tools/xen-9pfsd/io.c| 172
tools/xen-9pfsd/xen-9pfsd.h | 1 +
2 files changed, 173 insertions(+)
diff --git a/tools/xen-
Add the version request of the 9pfs protocol. For the version use the
"9P2000.u" variant, as it is supported by Mini-OS and Linux.
For the request parsing add all format items needed even in future in
order to avoid code churn for those additions later.
Signed-off-by: Juergen Gross
Reviewed-by:
Add the create request of the 9pfs protocol.
Signed-off-by: Juergen Gross
---
V2:
- set permissions correctly (Jason Andryuk)
---
tools/xen-9pfsd/io.c | 159 +++
1 file changed, 159 insertions(+)
diff --git a/tools/xen-9pfsd/io.c b/tools/xen-9pfsd/io.c
in
With 9pfs being fully available in Xenstore-stubdom now, there is no
reason to not fully support all logging capabilities in stubdom.
Open the logfile on stubdom only after the 9pfs file system has been
mounted.
Signed-off-by: Juergen Gross
Reviewed-by: Jason Andryuk
---
tools/hotplug/Linux/la
With 9pfs now available in Xenstore-stubdom, there is no reason to
have distinct do_control_memreport() variants for the daemon and the
stubdom implementations.
Signed-off-by: Juergen Gross
Reviewed-by: Jason Andryuk
---
tools/xenstored/control.c | 27 +++
1 file changed
Subject wants a log->9pfsd adjustment too
On 10/11/2023 4:07 pm, Juergen Gross wrote:
> diff --git a/tools/xen-9pfsd/xen-9pfsd.c b/tools/xen-9pfsd/xen-9pfsd.c
> new file mode 100644
> index 00..c365b35fe5
> --- /dev/null
> +++ b/tools/xen-9pfsd/xen-9pfsd.c
> @@ -0,0 +1,145 @@
> +/* SPDX-Li
Add the write request of the 9pfs protocol.
Signed-off-by: Juergen Gross
Reviewed-by: Jason Andryuk
---
tools/xen-9pfsd/io.c | 54
1 file changed, 54 insertions(+)
diff --git a/tools/xen-9pfsd/io.c b/tools/xen-9pfsd/io.c
index e5abd25857..f8d981c2a6
On 10.11.23 17:13, Andrew Cooper wrote:
Subject wants a log->9pfsd adjustment too
On 10/11/2023 4:07 pm, Juergen Gross wrote:
diff --git a/tools/xen-9pfsd/xen-9pfsd.c b/tools/xen-9pfsd/xen-9pfsd.c
new file mode 100644
index 00..c365b35fe5
--- /dev/null
+++ b/tools/xen-9pfsd/xen-9pfsd.c
Extend the config files of the Xenstore stubdoms to include XENBUS
and 9PFRONT items in order to support file based logging.
Signed-off-by: Juergen Gross
Reviewed-by: Jason Andryuk
---
stubdom/xenstore-minios.cfg| 2 +-
stubdom/xenstorepvh-minios.cfg | 2 +-
2 files changed, 2 insertions(+)
Today domain_init() is called either just before calling dom0_init()
in case no live update is being performed, or it is called after
reading the global state from read_state_global(), as the event
channel fd is needed.
Split up domain_init() into a preparation part which can be called
uncondition
When running as stubdom, map the stubdom's Xenstore ring page in order
to support using the 9pfs frontend.
Signed-off-by: Juergen Gross
---
tools/xenstored/core.c | 2 ++
tools/xenstored/domain.c | 27 ++-
tools/xenstored/domain.h | 1 +
3 files changed, 29 insertions
When [un]mapping the ring page of a Xenstore client, different actions
are required for "normal" guests and dom0. Today this distinction is
made at call site.
Move this distinction into [un]map_interface() instead, avoiding code
duplication and preparing special handling for [un]mapping the stub
d
Mount the 9pfs device in stubdom enabling it to use files.
This has to happen in a worker thread in order to allow the main thread
handling the required Xenstore accesses in parallel.
Signed-off-by: Juergen Gross
Reviewed-by: Jason Andryuk
---
tools/xenstored/core.h | 4
tools/xenstore
Some xenstored initialization needs to be done in the daemon case only,
so split it out into a new early_init() function being a stub in the
stubdom case.
Signed-off-by: Juergen Gross
Reviewed-by: Jason Andryuk
---
V2:
- rename function
- move patch earlier in the series
---
tools/xenstored/cor
Add support for the new 9pfs backend "xen-9pfsd". For this backend type
the tag defaults to "Xen" and the host side path to
"/var/log/xen/guests/".
Signed-off-by: Juergen Gross
---
V2:
- test max_files and max_open_files, too (Jason Andryuk)
---
docs/man/xl.cfg.5.pod.in | 36
Add the stat request of the 9pfs protocol.
Signed-off-by: Juergen Gross
Reviewed-by: Jason Andryuk
---
tools/xen-9pfsd/io.c | 92
1 file changed, 92 insertions(+)
diff --git a/tools/xen-9pfsd/io.c b/tools/xen-9pfsd/io.c
index a605f51dc6..e5abd25857
Add the clunk request of the 9pfs protocol.
Signed-off-by: Juergen Gross
---
tools/xen-9pfsd/io.c | 42 ++
1 file changed, 42 insertions(+)
diff --git a/tools/xen-9pfsd/io.c b/tools/xen-9pfsd/io.c
index bb9c78a1f5..c182ef0483 100644
--- a/tools/xen-9pfsd/
In order to prepare support of PV frontends in xenstore-stubdom, add
allocation of a Xenstore event channel to init-xenstore-domain.c.
Signed-off-by: Juergen Gross
Reviewed-by: Jason Andryuk
---
tools/helpers/init-xenstore-domain.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/tool
Add the read request of the 9pfs protocol.
For now support only reading plain files (no directories).
Signed-off-by: Juergen Gross
Reviewed-by: Jason Andryuk
---
V2:
- make error check more readable (Jason Andryuk)
---
tools/xen-9pfsd/io.c | 64
1 f
Make the backend type of 9pfs PV devices configurable. The default is
"qemu" with the related Xenstore backend-side directory being "9pfs".
Add another type "xen-9pfsd" with the related Xenstore backend-side
directory "xen_9pfs".
As additional security features it is possible to specify:
- "max-s
Rename the xenbus_evtchn() function to get_xenbus_evtchn() in order to
avoid two externally visible symbols with the same name when Xenstore-
stubdom is being built with a Mini-OS with CONFIG_XENBUS set.
Signed-off-by: Juergen Gross
Reviewed-by: Julien Grall
---
tools/xenstored/core.h | 2 +-
Obtain the own domid from the Xenstore special grant entry when running
as stubdom.
Signed-off-by: Juergen Gross
---
V2:
- replacement of V1 patch (ANdrew Cooper)
---
tools/xenstored/core.c | 1 +
tools/xenstored/core.h | 1 +
tools/xenstored/minios.c | 5 +
3 files changed, 7 insertions
Add some helpers for handling filenames which might need different
implementations between stubdom and daemon environments:
- expansion of relative filenames (those are not really defined today,
just expand them to be relative to /var/lib/xen/xenstore)
- expansion of xenstore_daemon_rundir() (us
Add a 9pfs device to Xenstore stubdom in order to allow it to do e.g.
logging into a dom0 file.
Use the following parameters for the new device:
- tag = "xen"
- type = "xen-9pfsd"
- path = "/var/lib/xen/xenstore"
- security-model = "none"
For now don't limit allowed file space or number of files
Hi everyone,
I trimmed the thread a bit, to make this more readable.
IMHO, the only viable option would be to have a configuration to
keep
ASSERT in production build for scanning tools.
But wouldn't that then likely mean scanning to be done on builds not
also
used in production? Would doing
Introduce an empty generic hypercall.h for archs which don't
implement it.
Signed-off-by: Oleksii Kurochko
---
Changes in V2:
- add check that isn't included directly.
---
xen/include/asm-generic/hypercall.h | 18 ++
1 file changed, 18 insertions(+)
create mode 100644 xen/incl
iocap.h is common for Arm, PPC and RISC-V architectures thereby
it was moved to asm-generic.
Signed-off-by: Oleksii Kurochko
---
The same question as with device.h. Should it be in asm-generic?
Changes in V2:
- update the commit message
---
xen/include/asm-generic/iocap.h | 17
1 - 100 of 140 matches
Mail list logo
