Re: exynos-mixer 14450000.mixer: [drm:exynos_drm_register_dma] *ERROR* Device 14450000.mixer lacks support for IOMMU
On 10/31/2023 8:08 AM, Marek Szyprowski wrote: > Hi, > > On 31.10.2023 00:03, Mario Marietto wrote: >> We are a team of linux enthusiasts who are trying to boot Xen on a >> Samsung XE303C12 Chromebook aka "snow" following the suggestions in >> the slide show presentation here: >> https://www.slideshare.net/xen_com_mgr/xpds16-porting-xen-on-arm-to-a-new-soc-julien-grall-arm >> >> This device uses an exynos5250 SOC dual core 1.7 GHz with 2 MB RAM, it >> is a Samsung armv7 chip with virtualization extensions. In particular, >> we have it working fairly well both on the bare metal with a recent >> 6.1.59 Linux LTS kernel and also with a recent 5.4.257 LTS kernel with >> KVM, the older LTS kernel version is used to test KVM because support >> for KVM on arm v7 was removed from Linux around kernel version 5.7. So >> we know we have the hypervisor mode enabled because we were able to >> use it with KVM. For Xen, we are using the latest Debian build of Xen >> 4.17 for the Debian armhf architecture: (XEN) Xen version 4.17.2-pre >> (Debian 4.17.1+2-gb773c48e36-1) >> (pkg-xen-devel@xxx) (arm-linux-gnueabihf-gcc >> (Debian 12.2.0-14) 12.2.0) debug=n Thu May 18 19:26:30 UTC 2023 The >> Linux kernel is a custom build that adds the Xen config kernel options >> (CONFIG_XEN_DOM0, etc) on top of a kernel that works well on the same >> Chromebook model on the bare metal. I can provide the config options >> of the kernel that was used if that is helpful. Our method of booting >> is to have u-boot boot the Xen hypervisor and load the device tree >> after adding the dom0 to the otherwise unaltered device tree from the >> Linux kernel using u-boot fdt commands to add a /chosen node, as >> described on the Xen wiki and in the pages linked from there. We have >> also tried adding and loading an initrd.img using the device tree >> /chosen node but that made no difference in our tests. We actually >> have the Linux LTS kernel version 6.1.59 working as dom0 with Xen >> using the same version of u-boot that we used for KVM, but with a big >> problem. The problem we see is that when booting the 6.1.59 kernel >> version as dom0 with Xen, the screen is totally dark and the only way >> to access the system is remotely through ssh. Logs indicate most >> everything else is working, such as the wifi card so we can access it >> remotely via ssh and a USB optical mouse lights up when connected so >> USB is also working. Obviously, the disk is also working. The >> Chromebook is configured to boot from the device's SD card slot by >> turning on Chrome OS developer mode options to enable booting from the >> SD card slot. The mystery is that when booting the exact same 6.1.59 >> kernel on the bare metal instead of booting it as dom0 on Xen, it >> boots up with full access to the screen and we can interact with the >> system using the X.org windows system. But booting as dom0 with Xen, >> the screen is totally dark and the only access we have to the system >> is through the network via ssh. Also, when booting the 5.4.257 kernel >> with KVM in hypervisor mode, the screen works and we can interact with >> the system through the X.org windows system. Exploring the log file,we >> have seen the errors below : >> >> Without Xen (or in bare metal): >> >> devuan-bunsen kernel: [drm] Exynos DRM: using 1440.fimd device for >> DMA mapping operations >> devuan-bunsen kernel: exynos-drm exynos-drm: bound 1440.fimd (ops >> 0xc0d96354) >> devuan-bunsen kernel: exynos-drm exynos-drm: bound 1445.mixer (ops >> 0xc0d97554) >> devuan-bunsen kernel: exynos-drm exynos-drm: bound >> 145b.dp-controller (ops 0xc0d97278) >> devuan-bunsen kernel: exynos-drm exynos-drm: bound 1453.hdmi (ops >> 0xc0d97bd0) >> ... >> devuan-bunsen kernel: Console: switching to colour frame buffer device >> 170x48 >> devuan-bunsen kernel: exynos-drm exynos-drm: [drm] fb0: exynosdrmfb >> frame buffer device >> devuan-bunsen kernel: [drm] Initialized exynos 1.1.0 20180330 for >> exynos-drm on minor 0 >> >> In this case,the kernel is able to use the exynos-drm kernel to start >> the fb0 device. But with Xen we get this error with exynos-drm: >> >> devuan-bunsen kernel: [drm] Exynos DRM: using 1440.fimd device for >> DMA mapping operations >> devuan-bunsen kernel: exynos-drm exynos-drm: bound 1440.fimd (ops >> 0xc0d96354) >> devuan-bunsen kernel: exynos-mixer 1445.mixer: >> [drm:exynos_drm_register_dma] *ERROR* Device 1445.mixer lacks >> support for IOMMU >> devuan-bunsen kernel: exynos-drm exynos-drm: failed to bind >> 1445.mixer (ops 0xc0d97554): -22 >> devuan-bunsen kernel: exynos-drm exynos-drm: adev bind failed: -22 >> devuan-bunsen kernel: exynos-dp: probe of 145b.dp-controller >> failed with error -22 >> >> I'm trying to find for a solution and I've googled a little bit and I >> found this web site : >> https://lore.kernel.org/linux-arm-kernel/20220208171823.226211-8-
[ovmf test] 183646: all pass - PUSHED
flight 183646 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/183646/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 1b1509abee839b74d3232bbd6a256a1bdc230925 baseline version: ovmf ccbe2e938386ed1ec49b3ad8ed6d107e7416e273 Last test of basis 183643 2023-10-31 21:14:30 Z0 days Testing same since 183646 2023-11-01 03:11:04 Z0 days1 attempts People who touched revisions under test: Mike Maslenkin Nickle Wang jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git ccbe2e9383..1b1509abee 1b1509abee839b74d3232bbd6a256a1bdc230925 -> xen-tested-master
Re: exynos-mixer 14450000.mixer: [drm:exynos_drm_register_dma] *ERROR* Device 14450000.mixer lacks support for IOMMU
Hi, @Stefano, as you pointed out, there is already a thread on xen-users for this discussion. Could we use this thread for any discussion? This would make easier to follow. Some high level comment below. On 01/11/2023 02:50, Chuck Zmudzinski wrote: On 10/31/2023 7:45 PM, Stefano Stabellini wrote: Unfortunately there is no easy solution. Do you know the version of the SMMU available on the platform? I am trying to discern, but I doubt we have v3 because we are working on a very old chromebook from 2012, and I am finding patches for smmv3 in Linux not starting until 2015. It is good to know about this option, though, for future work we might do on newer devices. The chromebook is using the Exynos Sysmmu. So there is no SMMU. If it is a SMMUv3 you can try to use the nested SMMU patch series to enable a virtual SMMU in Dom0: https://marc.info/?l=xen-devel&m=166991020831005 That way, Xen can use the SMMU to protect VMs, and Dom0 can also use the SMMU for its own purposes at the same time. Alternatively, you can dig into the details of the exynos-drm driver to see what exactly is the dependency on the IOMMU framework in Linux and remove the dependency. Unfortunately none of us in this thread are expert on exynos-drm so it would be difficult to advise on how to do that. For example, I don't know how you could debug the x11 problem you described because I don't typically work with x11 or with the exynos. If there is an open source mailing list for exynos-drm development they might be able to advise on how to remove the IOMMU dependency there. We have received this message from Marek Szyprowski of Samsung: https://lore.kernel.org/lkml/7a71e348-f892-4fd4-8857-b72f35ab5...@samsung.com/ Marek recommends this patch to possibly help with this issue: https://github.com/torvalds/linux/commit/bbc4d205d93f52ee18dfa7858d51489c0506547f and also these kernel config settings: On 10/31/2023 8:08 AM, Marek Szyprowski wrote: If not, then as a temporary workaround please disable CONFIG_DRM_EXYNOS_MIXER and CONFIG_DRM_EXYNOS_HDMI in your kernel config and check what will happen (You will lose the HDMI output, but maybe this won't a big issue). Mario and I have preliminary evidence that applying both of Marek's recommendations to the 6.1.59 kernel have improved the situation to the point where now the Chromebook can run X.org on Xen. We are doing further tests to see how Marek's patch and/or the kernel config settings to disable the mixer and the HDMI affect the behavior of the GPU in dom0 on Xen. The final option, which is a gross hack, would be to let Dom0 use the IOMMU for its own gain. Xen doesn't use the IOMMU. If you do that you lose freedom from interference between the VMs and you cannot run driver domains or directly assign devices to DomUs. But if you are running a research project you might be OK with that. To get it to work, you need to hack Xen so that it remaps the IOMMU to Dom0 to let Dom0 program it directly. The attached patch (untested) would be a place to start. You also need to pass iommu=false to the Xen command line to prevent Xen from using the iommu itself. This is actually one of the reason why I am suggesting to do all the investigation in one thread. There, we already discovered that the IOMMU was assigned to dom0 because Xen doesn't have a driver and we don't hide them by default. I am interested to investigate if only the mixer and the HDMI is causing the trouble. Based on what you are telling me about Xen not exposing the IOMMU to dom0, I don't fully understand the original log messages I was getting when I followed Julien's suggestion to find the symbols associated with each address in the original message, and those seemed to indicate that the exynos_drm device was using the IOMMU in dom0, but the mixer was not, and the fact that they both were not using the IOMMU is what caused the test to fail and Linux refuse to initialize the GPU on dom0, whereas on bare metal, the logs indicated both the exynos mixer, which I think is a sub device of the exynos_drm, and the exynos_drm, use the IOMMU on bare metal. I also found this patch which suggests if we can get the devices to work we will be compromising the security and isolation between guests: If you don't assign any device to the guests, then you will not break any isolation between guests because dom0 will own all of them. But for passthrough, you would want to the IOMMU owned by Xen rather than dom0. Unless the Exynos sysmmu support 2-stages page-tables, then dom0 will not be able to use the IOMMU. Cheers, -- Julien Grall
Re: exynos-mixer 14450000.mixer: [drm:exynos_drm_register_dma] *ERROR* Device 14450000.mixer lacks support for IOMMU
On 11/1/2023 4:27 AM, Julien Grall wrote: > Hi, > > @Stefano, as you pointed out, there is already a thread on xen-users for > this discussion. Could we use this thread for any discussion? This would > make easier to follow. > > Some high level comment below. I agree to keep the discussion here and not at other places. I just want to add that the best results for Xen dom0 so far are by implementing Marek's suggestion to disable these two settings in the 6.1.59 kernel config, but leaving everything else the same, including keeping the EXYNOS_IOMMU support enabled: # CONFIG_DRM_EXYNOS_MIXER is not set Disabling the mixer also makes this unavailable: # CONFIG_HDMI With this change, the GPU is working well enough to allow the display manager and an X11 session to run normally on the built-in display of the Chromebook. The Wifi also works well. The patch from Linux 6.2 and above that fixes the exynos IOMMU initialization did not help at all, and the same error is reported that the mixer lacks support for IOMMU. > > On 01/11/2023 02:50, Chuck Zmudzinski wrote: >> On 10/31/2023 7:45 PM, Stefano Stabellini wrote: >>> Unfortunately there is no easy solution. >>> >>> Do you know the version of the SMMU available on the platform? >> >> I am trying to discern, but I doubt we have v3 because we are >> working on a very old chromebook from 2012, and I am finding >> patches for smmv3 in Linux not starting until 2015. It is good to >> know about this option, though, for future work we might do on newer >> devices. > > The chromebook is using the Exynos Sysmmu. So there is no SMMU. > >> >>> If it is a SMMUv3 you can try to use the nested SMMU patch series to >>> enable a virtual SMMU in Dom0: >>> https://marc.info/?l=xen-devel&m=166991020831005 >>> That way, Xen can use the SMMU to protect VMs, and Dom0 can also use the >>> SMMU for its own purposes at the same time. >>> >>> Alternatively, you can dig into the details of the exynos-drm driver to >>> see what exactly is the dependency on the IOMMU framework in Linux and >>> remove the dependency. Unfortunately none of us in this thread are >>> expert on exynos-drm so it would be difficult to advise on how to do >>> that. For example, I don't know how you could debug the x11 problem you >>> described because I don't typically work with x11 or with the exynos. If >>> there is an open source mailing list for exynos-drm development they >>> might be able to advise on how to remove the IOMMU dependency there. >> >> We have received this message from Marek Szyprowski of Samsung: >> >> https://lore.kernel.org/lkml/7a71e348-f892-4fd4-8857-b72f35ab5...@samsung.com/ >> >> Marek recommends this patch to possibly help with this issue: >> >> https://github.com/torvalds/linux/commit/bbc4d205d93f52ee18dfa7858d51489c0506547f >> >> and also these kernel config settings: >> >> On 10/31/2023 8:08 AM, Marek Szyprowski wrote: >>> If not, then as a temporary workaround please disable >>> CONFIG_DRM_EXYNOS_MIXER and CONFIG_DRM_EXYNOS_HDMI in your kernel config >>> and check what will happen (You will lose the HDMI output, but maybe >>> this won't a big issue). >> >> Mario and I have preliminary evidence that applying both of Marek's >> recommendations to the 6.1.59 kernel have improved the situation to >> the point where now the Chromebook can run X.org on Xen. We are doing >> further tests to see how Marek's patch and/or the kernel config settings >> to disable the mixer and the HDMI affect the behavior of the GPU in dom0 >> on Xen. >> >>> >>> The final option, which is a gross hack, would be to let Dom0 use the >>> IOMMU for its own gain. Xen doesn't use the IOMMU. If you do that you >>> lose freedom from interference between the VMs and you cannot run driver >>> domains or directly assign devices to DomUs. But if you are running a >>> research project you might be OK with that. To get it to work, you need >>> to hack Xen so that it remaps the IOMMU to Dom0 to let Dom0 program it >>> directly. The attached patch (untested) would be a place to start. You >>> also need to pass iommu=false to the Xen command line to prevent Xen >>> from using the iommu itself. > > This is actually one of the reason why I am suggesting to do all the > investigation in one thread. There, we already discovered that the IOMMU > was assigned to dom0 because Xen doesn't have a driver and we don't hide > them by default. > >> >> I am interested to investigate if only the mixer and the HDMI is causing >> the trouble. Based on what you are telling me about Xen not exposing the >> IOMMU to dom0, I don't fully understand the original log messages I was >> getting when I followed Julien's suggestion to find the symbols associated >> with each address in the original message, and those seemed to indicate that >> the exynos_drm device was using the IOMMU in dom0, but the mixer was not, >> and the fact that they both were not using the IOMMU is what caused the >> test to fail and Linux refuse to
[PATCH 0/3] Mini-OS: preparations for 9pfs in xenstore-stubdom
This small patch series is doing some preparations for being able to use 9pfs in Xenstore-stubdom. Juergen Gross (3): Mini-OS: make xenstore_buf externally visible Mini-OS: don't crash if no shutdown node is available Mini-OS: fix 9pfs stat receive format 9pfront.c| 9 + include/xenbus.h | 2 ++ shutdown.c | 12 xenbus.c | 2 +- 4 files changed, 12 insertions(+), 13 deletions(-) -- 2.35.3
Re: live migration fails: qemu placing pci devices at different locations
On Tue, Oct 31, 2023 at 10:07:29AM +, James Dingwall wrote:
> Hi,
>
> I'm having a bit of trouble performing live migration between hvm guests. The
> sending side is xen 4.14.5 (qemu 5.0), receiving 4.15.5 (qemu 5.1). The error
> message recorded in qemu-dm---incoming.log:
>
> qemu-system-i386: Unknown savevm section or instance ':00:04.0/vga' 0.
> Make sure that your current VM setup matches your saved VM setup, including
> any hotplugged devices
>
> I have patched libxl_dm.c to explicitly assign `addr=xx` values for various
> devices and when these are correct the domain migrates correctly. However
> the configuration differences between guests means that the values are not
> consistent. The domain config file doesn't allow the pci address to be
> expressed in the configuration for, e.g. `soundhw="DEVICE"`
>
> e.g.
>
> diff --git a/tools/libs/light/libxl_dm.c b/tools/libs/light/libxl_dm.c
> index 6e531863ac0..daa7c49846f 100644
> --- a/tools/libs/light/libxl_dm.c
> +++ b/tools/libs/light/libxl_dm.c
> @@ -1441,7 +1441,7 @@ static int libxl__build_device_model_args_new(libxl__gc
> *gc,
> flexarray_append(dm_args, "-spice");
> flexarray_append(dm_args, spiceoptions);
> if (libxl_defbool_val(b_info->u.hvm.spice.vdagent)) {
> -flexarray_vappend(dm_args, "-device", "virtio-serial",
> +flexarray_vappend(dm_args, "-device",
> "virtio-serial,addr=04",
> "-chardev", "spicevmc,id=vdagent,name=vdagent",
> "-device",
> "virtserialport,chardev=vdagent,name=com.redhat.spice.0",
> NULL);
>
> The order of devices on the qemu command line (below) appears to be the same
> so my assumption is that the internals of qemu have resulted in things being
> connected in a different order. The output of a Windows `lspci` tool is
> also included.
>
> Could anyone make any additional suggestions on how I could try to gain
> consistency between the different qemu versions?
After a bit more head scratching we worked out the cause and a solution for
our case. In xen 4.15.4 d65ebacb78901b695bc5e8a075ad1ad865a78928 was
introduced to stop using the deprecated qemu `-soundhw` option. The qemu
device initialisation code looks like:
...
soundhw_init(); // handles old -soundhw option
...
/* init generic devices */
rom_set_order_override(FW_CFG_ORDER_OVERRIDE_DEVICE);
qemu_opts_foreach(qemu_find_opts("device"),
device_init_func, NULL, &error_fatal);
...
So for the old -soundhw option this was processed before any -device options
and the sound card was assigned the next available slot on the bus and then
any further -devices were added according to the command line order. After
that xen change the sound card was added as a -device and depending on the
other emulated hardware would be added at a different point to the equivalent
-soundhw option. By re-ordering the qemu command line building in libxl_dm.c
we can make the sound card be the first -device which resolves the migration
problem.
I think this would also have been a problem for live migration between 4.15.3
and 4.15.4 for a vm with a sound card and not just the major version jump we
are doing.
James
[PATCH 3/3] Mini-OS: fix 9pfs stat receive format
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
---
9pfront.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/9pfront.c b/9pfront.c
index 5da8a365..43c7409f 100644
--- a/9pfront.c
+++ b/9pfront.c
@@ -711,6 +711,7 @@ static int p9_create(struct dev_9pfs *dev, uint32_t fid,
char *path,
static int p9_stat(struct dev_9pfs *dev, uint32_t fid, struct p9_stat *stat)
{
struct req *req = get_free_req(dev);
+uint16_t total;
int ret;
if ( !req )
@@ -719,10 +720,10 @@ static int p9_stat(struct dev_9pfs *dev, uint32_t fid,
struct p9_stat *stat)
memset(stat, 0, sizeof(*stat));
req->cmd = P9_CMD_STAT;
send_9p(dev, req, "U", fid);
-rcv_9p(dev, req, "uuUQUUULSUUU", &stat->size, &stat->type, &stat->dev,
- stat->qid, &stat->mode, &stat->atime, &stat->mtime, &stat->length,
- &stat->name, &stat->uid, &stat->gid, &stat->muid, &stat->extension,
- &stat->n_uid, &stat->n_gid, &stat->n_muid);
+rcv_9p(dev, req, "uuuUQUUULSUUU", &total, &stat->size, &stat->type,
+ &stat->dev, stat->qid, &stat->mode, &stat->atime, &stat->mtime,
+ &stat->length, &stat->name, &stat->uid, &stat->gid, &stat->muid,
+ &stat->extension, &stat->n_uid, &stat->n_gid, &stat->n_muid);
ret = req->result;
--
2.35.3
[PATCH 2/3] Mini-OS: don't crash if no shutdown node is available
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 was taken. Just ignore this error now.
Signed-off-by: Juergen Gross
---
shutdown.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/shutdown.c b/shutdown.c
index bb2c6f11..ded6b64d 100644
--- a/shutdown.c
+++ b/shutdown.c
@@ -75,7 +75,9 @@ static void shutdown_thread(void *p)
xenbus_wait_for_watch(&events);
if ((err = xenbus_read(XBT_NIL, path, &shutdown))) {
free(err);
-do_exit();
+free(xenbus_unwatch_path_token(XBT_NIL, path, token));
+printk("Shutdown Xenstore node not available.\n");
+return;
}
if (end_shutdown_thread)
@@ -117,15 +119,9 @@ void init_shutdown(void)
void fini_shutdown(void)
{
-char *err;
-
end_shutdown_thread = 1;
xenbus_release_wait_for_watch(&events);
-err = xenbus_unwatch_path_token(XBT_NIL, path, token);
-if (err) {
-free(err);
-do_exit();
-}
+free(xenbus_unwatch_path_token(XBT_NIL, path, token));
}
#endif
--
2.35.3
[PATCH 1/3] Mini-OS: make xenstore_buf externally visible
For support of the 9pfs frontend in Xenstore-stubdom xenstore_buf
needs to be externally visible.
Signed-off-by: Juergen Gross
---
include/xenbus.h | 2 ++
xenbus.c | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/xenbus.h b/include/xenbus.h
index c0fc0ac5..542ee456 100644
--- a/include/xenbus.h
+++ b/include/xenbus.h
@@ -8,12 +8,14 @@ typedef unsigned long xenbus_transaction_t;
#ifdef CONFIG_XENBUS
extern uint32_t xenbus_evtchn;
+extern struct xenstore_domain_interface *xenstore_buf;
/* Initialize the XenBus system. */
void init_xenbus(void);
void get_xenbus(void *p);
#else
#define xenbus_evtchn ~0
+#define xenstore_buf NULL
static inline void init_xenbus(void)
{
diff --git a/xenbus.c b/xenbus.c
index 923e8181..8bfd5bd4 100644
--- a/xenbus.c
+++ b/xenbus.c
@@ -44,7 +44,7 @@
#define DEBUG(_f, _a...)((void)0)
#endif
-static struct xenstore_domain_interface *xenstore_buf;
+struct xenstore_domain_interface *xenstore_buf;
static DECLARE_WAIT_QUEUE_HEAD(xb_waitq);
DECLARE_WAIT_QUEUE_HEAD(xenbus_watch_queue);
static __DECLARE_SEMAPHORE_GENERIC(xb_write_sem, 1);
--
2.35.3
Re: exynos-mixer 14450000.mixer: [drm:exynos_drm_register_dma] *ERROR* Device 14450000.mixer lacks support for IOMMU
On 01/11/2023 08:45, Chuck Zmudzinski wrote: On 11/1/2023 4:27 AM, Julien Grall wrote: Hi, @Stefano, as you pointed out, there is already a thread on xen-users for this discussion. Could we use this thread for any discussion? This would make easier to follow. Some high level comment below. I agree to keep the discussion here and not at other places. I was meant to suggest the other thread :). But either is fine with me. I just want to avoid avoid multiple seperate threads for the discussion. I just want to add that the best results for Xen dom0 so far are by implementing Marek's suggestion to disable these two settings in the 6.1.59 kernel config, but leaving everything else the same, including keeping the EXYNOS_IOMMU support enabled: That's good news! I would be interested to hear how this works once you start to have PV backend in dom0 (I expect that the IOMMU will get confused with grant mapping). Also, do you plan to passthrough any of the devices protected by IOMMU? # CONFIG_DRM_EXYNOS_MIXER is not set Disabling the mixer also makes this unavailable: # CONFIG_HDMI With this change, the GPU is working well enough to allow the display manager and an X11 session to run normally on the built-in display of the Chromebook. The Wifi also works well. I saw your other answer about the Wifi not working when the IOMMU is not used. I was about to reply there, but instead I will do it here. TBH, I am quite surprised this is the case. The only difference with baremetal would be the RAM regions. Do you know if the Wifi dongle only accept certain physical address? Cheers, -- Julien Grall
[XEN PATCH][for-4.19 v6 0/8] Fix or deviate various instances of missing declarations
The patches in this series aim to fix or deviate various instances where a function or variable do not have a declaration visible when such entity is defined (in violation of MISRA C:2012 Rule 8.4). An exception listed under docs/misra/rules.rst allows asm-only functions and variables to be exempted, while the other instances are either changed (e.g., making them static) or a missing header inclusion is added. Nicola Vetrini (8): xen: modify or add declarations for variables where needed x86: add deviation for asm-only functions x86: add asmlinkage macro to variables only used in asm code x86/grant: switch included header to make declarations visible x86/vm_event: add missing include for hvm_vm_event_do_resume xen/console: remove stub definition in consoled.h x86/mem_access: make function static docs/misra: exclude three more files automation/eclair_analysis/ECLAIR/deviations.ecl | 9 + docs/misra/deviations.rst| 6 ++ docs/misra/exclude-list.json | 12 xen/arch/arm/include/asm/setup.h | 3 +++ xen/arch/arm/include/asm/smp.h | 3 +++ xen/arch/arm/platform_hypercall.c| 2 +- xen/arch/x86/cpu/mcheck/mce.c| 7 --- xen/arch/x86/hvm/grant_table.c | 3 +-- xen/arch/x86/hvm/svm/intr.c | 2 +- xen/arch/x86/hvm/svm/nestedsvm.c | 2 +- xen/arch/x86/hvm/svm/svm.c | 4 ++-- xen/arch/x86/hvm/vm_event.c | 1 + xen/arch/x86/hvm/vmx/intr.c | 2 +- xen/arch/x86/hvm/vmx/vmx.c | 4 ++-- xen/arch/x86/hvm/vmx/vvmx.c | 2 +- xen/arch/x86/include/asm/hvm/grant_table.h | 2 ++ xen/arch/x86/irq.c | 2 +- xen/arch/x86/mm/mem_access.c | 6 +++--- xen/arch/x86/setup.c | 8 +--- xen/arch/x86/traps.c | 2 +- xen/arch/x86/x86_64/traps.c | 2 +- xen/include/xen/compiler.h | 5 + xen/include/xen/consoled.h | 7 --- xen/include/xen/symbols.h| 1 + 24 files changed, 67 insertions(+), 30 deletions(-) -- 2.34.1
Re: [RFC PATCH 02/22] x86/msr: implement MSR_SMI_COUNT for Dom0 on Intel
> On 31 Oct 2023, at 09:57, Jan Beulich wrote: > > On 31.10.2023 10:42, Edwin Torok wrote: >>> On 30 Oct 2023, at 16:20, Jan Beulich wrote: >>> On 25.10.2023 21:29, Edwin Török wrote: Dom0 should always be able to read this MSR: it is useful when investigating performance issues in production. >>> >>> While I'm not outright opposed, I'm also not convinced. At the very least >>> ... >>> Although the count is Thread scoped, in practice all cores were observed to return the same count (perhaps due to implementation details of SMM), so do not require the cpu to be pinned in order to read it. >>> >>> ... this, even if matching your observations, is going to be properly >>> misleading in case counts end up diverging. >>> This MSR exists on Intel since Nehalem. Backport: 4.15+ >>> >>> If this was a backporting candidate, I think a Fixes: tag would need >>> to indicate what's being fixed here. >> >> >> I used the Backport tag to indicate what is the oldest release that it is >> backportable to. >> IIRC the choices were: >> * 4.0+ for issues that were present for a long time (didn't look further >> back than that in history), so there isn't any particular commit that >> introduces the problem, it was like that from the very beginning, i.e. not a >> regression. >> >> * 4.13+ for issues affecting only new CPU support (I think that is the >> release that added Icelake support). I can attempt to find the commit that >> added Icelake support and mark them as Fixes: that commit (although there >> might be several of them) >> >> * 4.15+ for bugs introduced by the default read-write msr changes >> >> >>> Otherwise this is merely a new >>> feature. >>> >> >> Prior to the default rdwrmsr changes it was possible to read any MSR, so I >> consider it a bug that after the default rdwrmsr changes you can no longer >> do that, it takes away a valuable debugging tool. > > As said elsewhere, making MSRs generally inaccessible was a deliberate change. > I don't think any of us x86 maintainers has so far considered that as > introducing > a bug. MSRs being accessible as a debugging tool may be worthwhile to have as > an > optional feature (see my suggestion elsewhere as to a possible way to approach > this), but I don't think this can be taken as an indication that we should > revert > back to "blind" exposure. > This particular patch (unlike the other one that is more general for all MSRs) is about one specific MSR, and makes it accessible to Dom0 only in a read-only way. That is very different from blindly exposing it to all guests. Anyway let me get something ready for master first, and then distributions that package Xen can decide whether to backport this patch or not, I'll replace Backport: 4.X with Backportable: 4.X (and add a Fixes: line) to indicate that this patch is recommended to be backported (for anyone who uses that version of Xen in production). [I'm not saying that this patch is complete, as you've indicated there is more work required to make it work correctly wrt to pinning vs non-pinning, and I'll try to require a pinned Dom0 core in my next version] Best regards, --Edwin
Re: [PATCH v4 0/5] Kconfig for PCI passthrough on ARM
> On 30 Oct 2023, at 23:52, Stewart Hildebrand
> wrote:
>
> There are multiple series in development/review [1], [2] that will benefit
> from
> having a Kconfig option for PCI passthrough on ARM. Hence I have sent this
> series independent from any other series.
>
> v3->v4:
> * rename ("xen/arm: pci: plumb xen_arch_domainconfig with pci info")
> to ("xen/vpci: move xen_domctl_createdomain vPCI flag to common")
> * fold ("xen/arm: make has_vpci() depend on d->arch.has_vpci")
> into ("xen/vpci: move xen_domctl_createdomain vPCI flag to common")
> * split ("xen/arm: enable vPCI for domUs") into separate hypervisor and
> tools patches
>
> v2->v3:
> * add ("xen/arm: pci: plumb xen_arch_domainconfig with pci info")
> * rename ("xen/arm: make has_vpci depend on CONFIG_HAS_VPCI")
> to ("xen/arm: make has_vpci() depend on d->arch.has_vpci")
> * add ("xen/arm: enable vPCI for dom0")
>
> v1->v2:
> * add ("[FUTURE] xen/arm: enable vPCI for domUs")
>
> [1] https://lists.xenproject.org/archives/html/xen-devel/2023-08/msg02361.html
> [2] https://lists.xenproject.org/archives/html/xen-devel/2023-10/msg00210.html
>
> Rahul Singh (1):
> xen/arm: pci: introduce PCI_PASSTHROUGH Kconfig option
>
> Stewart Hildebrand (4):
> xen/vpci: move xen_domctl_createdomain vPCI flag to common
> xen/arm: enable vPCI for dom0
> [FUTURE] xen/arm: enable vPCI for domUs
> [FUTURE] tools/arm: enable vPCI for domUs
>
> tools/libs/light/libxl_arm.c | 3 +++
> tools/libs/light/libxl_x86.c | 5 -
> tools/ocaml/libs/xc/xenctrl.ml | 2 +-
> tools/ocaml/libs/xc/xenctrl.mli| 2 +-
> tools/python/xen/lowlevel/xc/xc.c | 5 -
> xen/arch/arm/Kconfig | 10 ++
> xen/arch/arm/domain.c | 3 ++-
> xen/arch/arm/domain_build.c| 6 ++
> xen/arch/arm/include/asm/domain.h | 3 ---
> xen/arch/arm/include/asm/pci.h | 9 +
> xen/arch/arm/pci/pci-host-common.c | 11 ---
> xen/arch/arm/vpci.c| 8
> xen/arch/x86/domain.c | 16 ++--
> xen/arch/x86/include/asm/domain.h | 6 +-
> xen/arch/x86/setup.c | 5 +++--
> xen/common/domain.c| 10 +-
> xen/drivers/passthrough/pci.c | 10 ++
> xen/include/public/arch-x86/xen.h | 5 +
> xen/include/public/domctl.h| 7 +--
> xen/include/xen/domain.h | 2 ++
> 20 files changed, 97 insertions(+), 31 deletions(-)
>
>
> base-commit: 9659b2a6d73b14620e187f9c626a09323853c459
> --
> 2.42.0
>
Acked-by: Christian Lindig
The changes for the OCaml part are incremental; is someone using the OCaml
bindings on ARM seriously?
— C
[XEN PATCH][for-4.19 v6 1/8] xen: modify or add declarations for variables where needed
Some variables with external linkage used in C code do not have
a visible declaration where they are defined. Other variables
can be made static, thereby eliminating the need for a declaration.
Doing so also resolves violations of MISRA C:2012 Rule 8.4.
Fix typo s/mcinfo_dumpped/mcinfo_dumped/ while making
the variable static.
Signed-off-by: Nicola Vetrini
Reviewed-by: Stefano Stabellini
Acked-by: Jan Beulich
---
Jan's ack is for the x86 part, but no other concerns have been
raised for the arm files.
Changes in v2:
- make xenpf_lock static on ARM
Changes in v3:
- moved back code from symbols.h to symbols.c
- dropped two declarations, now deviated
Changes in v4:
- revise commit message
---
xen/arch/arm/include/asm/setup.h | 3 +++
xen/arch/arm/include/asm/smp.h| 3 +++
xen/arch/arm/platform_hypercall.c | 2 +-
xen/arch/x86/cpu/mcheck/mce.c | 7 ---
xen/arch/x86/irq.c| 2 +-
xen/include/xen/symbols.h | 1 +
6 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h
index 98af6f55f5a0..2a2d6114f2eb 100644
--- a/xen/arch/arm/include/asm/setup.h
+++ b/xen/arch/arm/include/asm/setup.h
@@ -184,9 +184,12 @@ int map_range_to_domain(const struct dt_device_node *dev,
extern lpae_t boot_pgtable[XEN_PT_LPAE_ENTRIES];
#ifdef CONFIG_ARM_64
+extern lpae_t boot_first[XEN_PT_LPAE_ENTRIES];
extern lpae_t boot_first_id[XEN_PT_LPAE_ENTRIES];
#endif
+extern lpae_t boot_second[XEN_PT_LPAE_ENTRIES];
extern lpae_t boot_second_id[XEN_PT_LPAE_ENTRIES];
+extern lpae_t boot_third[XEN_PT_LPAE_ENTRIES * XEN_NR_ENTRIES(2)];
extern lpae_t boot_third_id[XEN_PT_LPAE_ENTRIES];
/* Find where Xen will be residing at runtime and return a PT entry */
diff --git a/xen/arch/arm/include/asm/smp.h b/xen/arch/arm/include/asm/smp.h
index 4fabdf5310d8..28bf24a01d95 100644
--- a/xen/arch/arm/include/asm/smp.h
+++ b/xen/arch/arm/include/asm/smp.h
@@ -6,6 +6,9 @@
#include
#endif
+extern struct init_info init_data;
+extern unsigned long smp_up_cpu;
+
DECLARE_PER_CPU(cpumask_var_t, cpu_sibling_mask);
DECLARE_PER_CPU(cpumask_var_t, cpu_core_mask);
diff --git a/xen/arch/arm/platform_hypercall.c
b/xen/arch/arm/platform_hypercall.c
index 743687a30390..fde4bc3e5809 100644
--- a/xen/arch/arm/platform_hypercall.c
+++ b/xen/arch/arm/platform_hypercall.c
@@ -17,7 +17,7 @@
#include
#include
-DEFINE_SPINLOCK(xenpf_lock);
+static DEFINE_SPINLOCK(xenpf_lock);
long do_platform_op(XEN_GUEST_HANDLE_PARAM(xen_platform_op_t) u_xenpf_op)
{
diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index 6141b7eb9cf1..779a458cd88f 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -1682,13 +1682,14 @@ long do_mca(XEN_GUEST_HANDLE_PARAM(xen_mc_t) u_xen_mc)
return ret;
}
-int mcinfo_dumpped;
+static int mcinfo_dumped;
+
static int cf_check x86_mcinfo_dump_panic(mctelem_cookie_t mctc)
{
struct mc_info *mcip = mctelem_dataptr(mctc);
x86_mcinfo_dump(mcip);
-mcinfo_dumpped++;
+mcinfo_dumped++;
return 0;
}
@@ -1702,7 +1703,7 @@ static void mc_panic_dump(void)
for_each_online_cpu(cpu)
mctelem_process_deferred(cpu, x86_mcinfo_dump_panic,
mctelem_has_deferred_lmce(cpu));
-dprintk(XENLOG_ERR, "End dump mc_info, %x mcinfo dumped\n",
mcinfo_dumpped);
+dprintk(XENLOG_ERR, "End dump mc_info, %x mcinfo dumped\n", mcinfo_dumped);
}
void mc_panic(const char *s)
diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c
index f42ad539dcd5..ecd67f7f8416 100644
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -43,7 +43,7 @@ int __read_mostly opt_irq_vector_map =
OPT_IRQ_VECTOR_MAP_DEFAULT;
static unsigned char __read_mostly irq_max_guests;
integer_param("irq-max-guests", irq_max_guests);
-vmask_t global_used_vector_map;
+static vmask_t global_used_vector_map;
struct irq_desc __read_mostly *irq_desc = NULL;
diff --git a/xen/include/xen/symbols.h b/xen/include/xen/symbols.h
index 20bbb28ef226..1b2863663aa0 100644
--- a/xen/include/xen/symbols.h
+++ b/xen/include/xen/symbols.h
@@ -33,4 +33,5 @@ struct symbol_offset {
uint32_t stream; /* .. in the compressed stream.*/
uint32_t addr; /* .. and in the fixed size address array. */
};
+
#endif /*_XEN_SYMBOLS_H*/
--
2.34.1
[XEN PATCH][for-4.19 v6 3/8] x86: add asmlinkage macro to variables only used in asm code
To avoid a violation of MISRA C:2012 Rule 8.4, as permitted
by docs/misra/rules.rst.
The current_stack_pointer is a declaration: mark it as such
for ECLAIR.
Signed-off-by: Nicola Vetrini
---
Changes in v3:
- Edited commit message
- Add two new variables
Changes in v5:
- Mark current_stack_pointer as a declaration.
- Use asmlinkage instead of SAF.
Changes in v6:
- moved asmlinkage after the type
---
xen/arch/x86/setup.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index a3d3f797bb1e..d70ad1e44a60 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -75,7 +75,8 @@ static bool __initdata opt_invpcid = true;
boolean_param("invpcid", opt_invpcid);
bool __read_mostly use_invpcid;
-unsigned long __read_mostly cr4_pv32_mask;
+/* Only used in asm code and within this source file */
+unsigned long asmlinkage __read_mostly cr4_pv32_mask;
/* Linux config option: propagated to domain0. */
/* "acpi=off":Sisables both ACPI table parsing and interpreter. */
@@ -146,14 +147,15 @@ cpumask_t __read_mostly cpu_present_map;
unsigned long __read_mostly xen_phys_start;
-char __section(".init.bss.stack_aligned") __aligned(STACK_SIZE)
+/* Only used in asm code and within this source file */
+char asmlinkage __section(".init.bss.stack_aligned") __aligned(STACK_SIZE)
cpu0_stack[STACK_SIZE];
/* Used by the BSP/AP paths to find the higher half stack mapping to use. */
void *stack_start = cpu0_stack + STACK_SIZE - sizeof(struct cpu_info);
/* Used by the boot asm to stash the relocated multiboot info pointer. */
-unsigned int __initdata multiboot_ptr;
+unsigned int asmlinkage __initdata multiboot_ptr;
struct cpuinfo_x86 __read_mostly boot_cpu_data = { 0, 0, 0, 0, -1 };
--
2.34.1
[XEN PATCH][for-4.19 v6 5/8] x86/vm_event: add missing include for hvm_vm_event_do_resume
The missing header makes the declaration visible when the function
is defined, thereby fixing a violation of MISRA C:2012 Rule 8.4.
Fixes: 1366a0e76db6 ("x86/vm_event: add hvm/vm_event.{h,c}")
Signed-off-by: Nicola Vetrini
Acked-by: Tamas K Lengyel
---
xen/arch/x86/hvm/vm_event.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/arch/x86/hvm/vm_event.c b/xen/arch/x86/hvm/vm_event.c
index 3b064bcfade5..c1af230e7aed 100644
--- a/xen/arch/x86/hvm/vm_event.c
+++ b/xen/arch/x86/hvm/vm_event.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
static void hvm_vm_event_set_registers(const struct vcpu *v)
--
2.34.1
[XEN PATCH][for-4.19 v6 7/8] x86/mem_access: make function static
The function is used only within this file, and therefore can be static.
No functional change.
Signed-off-by: Nicola Vetrini
Acked-by: Tamas K Lengyel
---
Changes in v3:
- style fix
---
xen/arch/x86/mm/mem_access.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c
index 3449e0ee85ff..60a0cce68aa3 100644
--- a/xen/arch/x86/mm/mem_access.c
+++ b/xen/arch/x86/mm/mem_access.c
@@ -249,9 +249,9 @@ bool p2m_mem_access_check(paddr_t gpa, unsigned long gla,
return (p2ma != p2m_access_n2rwx);
}
-int p2m_set_altp2m_mem_access(struct domain *d, struct p2m_domain *hp2m,
- struct p2m_domain *ap2m, p2m_access_t a,
- gfn_t gfn)
+static int p2m_set_altp2m_mem_access(struct domain *d, struct p2m_domain *hp2m,
+ struct p2m_domain *ap2m, p2m_access_t a,
+ gfn_t gfn)
{
mfn_t mfn;
p2m_type_t t;
--
2.34.1
[XEN PATCH][for-4.19 v6 2/8] x86: add deviation for asm-only functions
As stated in rules.rst, functions used only in asm modules
are allowed to have no prior declaration visible when being
defined, hence these functions are marked with an
'asmlinkage' macro, which is then deviated for MISRA C:2012
Rule 8.4.
Signed-off-by: Nicola Vetrini
---
Changes in v3:
- added SAF deviations for vmx counterparts to svm functions.
Changes in v5:
- drop SAF deviations in favour of the pseudo-attribute asmlinkage
Changes in v6:
- conditioned asmlinkage definition to make it overridable;
- move the pseudo-attribute after the return type
---
automation/eclair_analysis/ECLAIR/deviations.ecl | 9 +
docs/misra/deviations.rst| 6 ++
xen/arch/x86/hvm/svm/intr.c | 2 +-
xen/arch/x86/hvm/svm/nestedsvm.c | 2 +-
xen/arch/x86/hvm/svm/svm.c | 4 ++--
xen/arch/x86/hvm/vmx/intr.c | 2 +-
xen/arch/x86/hvm/vmx/vmx.c | 4 ++--
xen/arch/x86/hvm/vmx/vvmx.c | 2 +-
xen/arch/x86/traps.c | 2 +-
xen/arch/x86/x86_64/traps.c | 2 +-
xen/include/xen/compiler.h | 5 +
11 files changed, 30 insertions(+), 10 deletions(-)
diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl
b/automation/eclair_analysis/ECLAIR/deviations.ecl
index fa56e5c00a27..06619ecf7e8d 100644
--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
+++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
@@ -163,6 +163,15 @@ Therefore the absence of prior declarations is safe."
-config=MC3R1.R8.4,reports+={safe, "first_area(any_loc(file(gcov)))"}
-doc_end
+-doc_begin="Recognize the occurrence of current_stack_pointer as a
declaration."
+-file_tag+={asm_defns, "^xen/arch/x86/include/asm/asm_defns\\.h$"}
+-config=MC3R1.R8.4,declarations+={safe,
"loc(file(asm_defns))&&^current_stack_pointer$"}
+-doc_end
+
+-doc_begin="asmlinkage is a marker to indicate that the function is only used
to interface with asm modules."
+-config=MC3R1.R8.4,declarations+={safe,"loc(text(^(?s).*asmlinkage.*$,
-1..0))"}
+-doc_end
+
-doc_begin="The following variables are compiled in multiple translation units
belonging to different executables and therefore are safe."
-config=MC3R1.R8.6,declarations+={safe,
"name(current_stack_pointer||bsearch||sort)"}
diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
index 8511a189253b..d468da2f5ce9 100644
--- a/docs/misra/deviations.rst
+++ b/docs/misra/deviations.rst
@@ -133,6 +133,12 @@ Deviations related to MISRA C:2012 Rules:
configuration. Therefore, the absence of prior declarations is safe.
- Tagged as `safe` for ECLAIR.
+ * - R8.4
+ - Functions and variables used only by asm modules are either marked with
+ the `asmlinkage` macro or with a SAF-1-safe textual deviation
+ (see safe.json).
+ - Tagged as `safe` for ECLAIR.
+
* - R8.6
- The following variables are compiled in multiple translation units
belonging to different executables and therefore are safe.
diff --git a/xen/arch/x86/hvm/svm/intr.c b/xen/arch/x86/hvm/svm/intr.c
index 192e17ebbfbb..4805c5567213 100644
--- a/xen/arch/x86/hvm/svm/intr.c
+++ b/xen/arch/x86/hvm/svm/intr.c
@@ -123,7 +123,7 @@ static void svm_enable_intr_window(struct vcpu *v, struct
hvm_intack intack)
vmcb, general1_intercepts | GENERAL1_INTERCEPT_VINTR);
}
-void svm_intr_assist(void)
+void asmlinkage svm_intr_assist(void)
{
struct vcpu *v = current;
struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb;
diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c
index a09b6abaaeaf..fc7658d67d4e 100644
--- a/xen/arch/x86/hvm/svm/nestedsvm.c
+++ b/xen/arch/x86/hvm/svm/nestedsvm.c
@@ -1441,7 +1441,7 @@ nestedsvm_vcpu_vmexit(struct vcpu *v, struct
cpu_user_regs *regs,
}
/* VCPU switch */
-void nsvm_vcpu_switch(void)
+void asmlinkage nsvm_vcpu_switch(void)
{
struct cpu_user_regs *regs = guest_cpu_user_regs();
struct vcpu *v = current;
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 24c417ca7199..cb8abe7a0066 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1056,7 +1056,7 @@ static void noreturn cf_check svm_do_resume(void)
reset_stack_and_jump(svm_asm_do_resume);
}
-void svm_vmenter_helper(void)
+void asmlinkage svm_vmenter_helper(void)
{
const struct cpu_user_regs *regs = guest_cpu_user_regs();
struct vcpu *curr = current;
@@ -2586,7 +2586,7 @@ const struct hvm_function_table * __init start_svm(void)
return &svm_function_table;
}
-void svm_vmexit_handler(void)
+void asmlinkage svm_vmexit_handler(void)
{
struct cpu_user_regs *regs = guest_cpu_user_regs();
uint64_t exit_reason;
diff --git a/xen/arch/x86/hvm/vmx/intr.c b/xen/arch/x86/hvm/vmx/intr.c
index fd719c4c01d2..8beeaab1517b 100644
--- a/xen/arch/x86/hvm/vmx/intr.c
+++ b/xen/arch/x86/hvm/vmx/
[XEN PATCH][for-4.19 v6 6/8] xen/console: remove stub definition in consoled.h
The stub definition of 'consoled_guest_tx' can be removed, since its
its single caller uses the implementation built with PV_SHIM enabled.
Fixes: 5ef49f185c2d ("x86/pv-shim: shadow PV console's page for L2 DomU")
Signed-off-by: Nicola Vetrini
Reviewed-by: Stefano Stabellini
---
xen/include/xen/consoled.h | 7 ---
1 file changed, 7 deletions(-)
diff --git a/xen/include/xen/consoled.h b/xen/include/xen/consoled.h
index fd5d220a8aca..2b30516b3a0a 100644
--- a/xen/include/xen/consoled.h
+++ b/xen/include/xen/consoled.h
@@ -3,18 +3,11 @@
#include
-#ifdef CONFIG_PV_SHIM
-
void consoled_set_ring_addr(struct xencons_interface *ring);
struct xencons_interface *consoled_get_ring_addr(void);
size_t consoled_guest_rx(void);
size_t consoled_guest_tx(char c);
-#else
-
-size_t consoled_guest_tx(char c) { return 0; }
-
-#endif /* !CONFIG_PV_SHIM */
#endif /* __XEN_CONSOLED_H__ */
/*
* Local variables:
--
2.34.1
[XEN PATCH][for-4.19 v6 8/8] docs/misra: exclude three more files
These files should not conform to MISRA guidelines at the moment,
therefore they are added to the exclusion list.
Signed-off-by: Nicola Vetrini
Reviewed-by: Stefano Stabellini
---
These exclusions are automatically picked up by ECLAIR's automation
to hide reports originating from these files.
Changes in v4:
- Fixed typo
---
docs/misra/exclude-list.json | 12
1 file changed, 12 insertions(+)
diff --git a/docs/misra/exclude-list.json b/docs/misra/exclude-list.json
index 575ed22a7f67..b858a0baa106 100644
--- a/docs/misra/exclude-list.json
+++ b/docs/misra/exclude-list.json
@@ -145,6 +145,10 @@
"rel_path": "common/zstd/*",
"comment": "Imported from Linux, ignore for now"
},
+{
+"rel_path": "common/symbols-dummy.c",
+"comment": "The resulting code is not included in the final Xen
binary, ignore for now"
+},
{
"rel_path": "crypto/*",
"comment": "Origin is external and documented in
crypto/README.source"
@@ -189,6 +193,14 @@
"rel_path": "include/acpi/acpixf.h",
"comment": "Imported from Linux, ignore for now"
},
+{
+ "rel_path": "include/acpi/acexcep.h",
+ "comment": "Imported from Linux, ignore for now"
+},
+{
+ "rel_path": "include/acpi/acglobal.h",
+ "comment": "Imported from Linux, ignore for now"
+},
{
"rel_path": "include/xen/acpi.h",
"comment": "Imported from Linux, ignore for now"
--
2.34.1
[XEN PATCH][for-4.19 v6 4/8] x86/grant: switch included header to make declarations visible
The declarations for {create,replace}_grant_p2m_mapping are
not visible when these functions are defined, therefore the right
header needs to be included to allow them to be visible.
Signed-off-by: Nicola Vetrini
Reviewed-by: Stefano Stabellini
Acked-by: Jan Beulich
---
Changes in v3:
- asm/paging.h can be replaced with mm-frame.h, because just the
definition of mfn_t is needed.
---
xen/arch/x86/hvm/grant_table.c | 3 +--
xen/arch/x86/include/asm/hvm/grant_table.h | 2 ++
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/hvm/grant_table.c b/xen/arch/x86/hvm/grant_table.c
index 30d51d54a949..afe449d8882c 100644
--- a/xen/arch/x86/hvm/grant_table.c
+++ b/xen/arch/x86/hvm/grant_table.c
@@ -9,8 +9,7 @@
#include
-#include
-
+#include
#include
int create_grant_p2m_mapping(uint64_t addr, mfn_t frame,
diff --git a/xen/arch/x86/include/asm/hvm/grant_table.h
b/xen/arch/x86/include/asm/hvm/grant_table.h
index 33c1da1a25f3..01e23f79b8cf 100644
--- a/xen/arch/x86/include/asm/hvm/grant_table.h
+++ b/xen/arch/x86/include/asm/hvm/grant_table.h
@@ -10,6 +10,8 @@
#ifndef __X86_HVM_GRANT_TABLE_H__
#define __X86_HVM_GRANT_TABLE_H__
+#include
+
#ifdef CONFIG_HVM
int create_grant_p2m_mapping(uint64_t addr, mfn_t frame,
--
2.34.1
Re: [XEN PATCH][for-4.19 v6 0/8] Fix or deviate various instances of missing declarations
On 2023-11-01 10:15, Nicola Vetrini wrote: The patches in this series aim to fix or deviate various instances where a function or variable do not have a declaration visible when such entity is defined (in violation of MISRA C:2012 Rule 8.4). An exception listed under docs/misra/rules.rst allows asm-only functions and variables to be exempted, while the other instances are either changed (e.g., making them static) or a missing header inclusion is added. Nicola Vetrini (8): xen: modify or add declarations for variables where needed x86: add deviation for asm-only functions x86: add asmlinkage macro to variables only used in asm code x86/grant: switch included header to make declarations visible x86/vm_event: add missing include for hvm_vm_event_do_resume xen/console: remove stub definition in consoled.h x86/mem_access: make function static docs/misra: exclude three more files automation/eclair_analysis/ECLAIR/deviations.ecl | 9 + docs/misra/deviations.rst| 6 ++ docs/misra/exclude-list.json | 12 xen/arch/arm/include/asm/setup.h | 3 +++ xen/arch/arm/include/asm/smp.h | 3 +++ xen/arch/arm/platform_hypercall.c| 2 +- xen/arch/x86/cpu/mcheck/mce.c| 7 --- xen/arch/x86/hvm/grant_table.c | 3 +-- xen/arch/x86/hvm/svm/intr.c | 2 +- xen/arch/x86/hvm/svm/nestedsvm.c | 2 +- xen/arch/x86/hvm/svm/svm.c | 4 ++-- xen/arch/x86/hvm/vm_event.c | 1 + xen/arch/x86/hvm/vmx/intr.c | 2 +- xen/arch/x86/hvm/vmx/vmx.c | 4 ++-- xen/arch/x86/hvm/vmx/vvmx.c | 2 +- xen/arch/x86/include/asm/hvm/grant_table.h | 2 ++ xen/arch/x86/irq.c | 2 +- xen/arch/x86/mm/mem_access.c | 6 +++--- xen/arch/x86/setup.c | 8 +--- xen/arch/x86/traps.c | 2 +- xen/arch/x86/x86_64/traps.c | 2 +- xen/include/xen/compiler.h | 5 + xen/include/xen/consoled.h | 7 --- xen/include/xen/symbols.h| 1 + 24 files changed, 67 insertions(+), 30 deletions(-) Please ignore this email; the patch series v6 has been sent fully in a different email -- Nicola Vetrini, BSc Software Engineer, BUGSENG srl (https://bugseng.com)
[PATCH 01/29] xen/public: add some more 9pfs xenstore paths
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/io/9pfs.h b/xen/include/public/io/9pfs.h index 9ad2773082..ac4bf0434b 100644 --- a/xen/include/public/io/9pfs.h +++ b/xen/include/public/io/9pfs.h @@ -71,6 +71,40 @@ * created on the guest (no user ownership squash or remap) * Only "none" is supported in this version of the protocol. * + *max-files + * Values: + * + * The maximum number of files (including directories) allowed for + * this device. Backend support of this node is optional. If the node + * is not present or the value is zero the number of files is not + * limited. + * + *max-open-files + * Values: + * + * The maximum number of files the guest is allowed to have opened + * concurrently. Multiple concurrent opens of the same file are counted + * individually. Backend support of this node is optional. If the node + * is not present or the value is zero a backend specific default is + * applied. + * + *max-space + * Values: + * + * The maximum file space in MiBs the guest is allowed to use for this + * device. Backend support of this node is optional. If the node is + * not present or the value is zero the space is not limited. + * + *auto-delete + * Values: + * + * When set to "1" the backend will delete the file with the oldest + * modification date below in case the allowed maximum file + * space (see ) or file number (see ) is being + * exceeded due to guest activity (creation or extension of files). + * Files currently opened by the guest won't be deleted. Backend + * support of this node is optional. + * ** *Frontend XenBus Nodes ** -- 2.35.3
[PATCH 00/29] tools: enable xenstore-stubdom to use 9pfs
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 from scratch. Using a dedicated 9pfs daemon has several advantages: - it is using much less resources than a full blown qemu process - it can serve multiple guests (the idea is to use it for other infrastructure domains, like qemu-stubdom or driver domains, too) - it is designed to support several security enhancements, like limiting the number of files for a guest, or limiting the allocated file system space - it doesn't support file links (neither hard nor soft links) or referencing parent directories via "..", minimizing the risk that a guest can "escape" from its home directory Note that for now the daemon only contains the minimal needed functionality to do logging from Xenstore-stubdom. I didn't want to add all the 9pfs commands and security add-ons in the beginning, in order to avoid needless efforts in case the idea of the daemon is being rejected. Note that the series can only be committed after the related Mini-OS series [1] has gone in. [1]: https://lists.xen.org/archives/html/xen-devel/2023-11/threads.html#00010 Juergen Gross (29): xen/public: add some more 9pfs xenstore paths tools: add a new xen logging daemon tools/xenlogd: connect to frontend tools/xenlogd: add transport layer tools/xenlogd: add 9pfs response generation support tools/xenlogd: add 9pfs version request support tools/xenlogd: add 9pfs attach request support tools/xenlogd: add 9pfs walk request support tools/xenlogd: add 9pfs open request support tools/xenlogd: add 9pfs clunk request support tools/xenlogd: add 9pfs create request support tools/xenlogd: add 9pfs stat request support tools/xenlogd: add 9pfs write request support tools/xenlogd: add 9pfs read request support tools/libs/light: add backend type for 9pfs PV devices tools/xl: support new 9pfs backend xenlogd tools/helpers: allocate xenstore event channel for xenstore stubdom tools/xenstored: rename xenbus_evtchn() stubdom: extend xenstore stubdom configs tools: add 9pfs device to xenstore-stubdom tools: tell xenstore-stubdom its own domid tools/xenstored: tools/xenstored: split domain_init() tools/xenstored: map stubdom interface tools/xenstored: mount 9pfs device in stubdom tools/xenstored: add helpers for filename handling tools/xenstored: add daemon_init() function tools/xenstored: support complete log capabilities in stubdom tools/xenstored: have a single do_control_memreport() docs/man/xl.cfg.5.pod.in | 36 +- stubdom/xenstore-minios.cfg |2 +- stubdom/xenstorepvh-minios.cfg|2 +- tools/Makefile|1 + tools/helpers/init-xenstore-domain.c | 13 +- tools/hotplug/Linux/launch-xenstore.in|1 + tools/include/libxl.h | 17 + tools/include/xen-tools/common-macros.h |4 + tools/libs/light/libxl_9pfs.c | 172 ++- tools/libs/light/libxl_create.c |4 +- tools/libs/light/libxl_dm.c |2 +- tools/libs/light/libxl_types.idl | 11 + tools/libs/light/libxl_types_internal.idl |1 + tools/xenlogd/.gitignore |1 + tools/xenlogd/Makefile| 38 + tools/xenlogd/io.c| 1337 + tools/xenlogd/xenlogd.c | 715 +++ tools/xenlogd/xenlogd.h | 85 ++ tools/xenstored/control.c | 29 +- tools/xenstored/core.c| 28 +- tools/xenstored/core.h| 12 +- tools/xenstored/domain.c | 72 +- tools/xenstored/domain.h |2 + tools/xenstored/lu_daemon.c |4 +- tools/xenstored/minios.c | 49 +- tools/xenstored/posix.c | 18 +- tools/xl/xl_parse.c | 35 + xen/include/public/io/9pfs.h | 34 + 28 files changed, 2655 insertions(+), 70 deletions(-) create mode 100644 tools/xenlogd/.gitignore create mode 100644 tools/xenlogd/Makefile create mode 100644 tools/xenlogd/io.c create mode 100644 tools/xenlogd/xenlogd.c create mode 100644 tools/xenlogd/xenlogd.h -- 2.35.3
[PATCH 03/29] tools/xenlogd: connect to frontend
Add the code for connecting to frontends to xenlogd.
Signed-off-by: Juergen Gross
---
tools/xenlogd/Makefile | 2 +-
tools/xenlogd/io.c | 45
tools/xenlogd/xenlogd.c | 575 +++-
tools/xenlogd/xenlogd.h | 50
4 files changed, 668 insertions(+), 4 deletions(-)
create mode 100644 tools/xenlogd/io.c
create mode 100644 tools/xenlogd/xenlogd.h
diff --git a/tools/xenlogd/Makefile b/tools/xenlogd/Makefile
index 550e914f59..0d44cd0e85 100644
--- a/tools/xenlogd/Makefile
+++ b/tools/xenlogd/Makefile
@@ -10,7 +10,7 @@ LDFLAGS += $(PTHREAD_LDFLAGS)
TARGETS := xenlogd
-XENLOGD_OBJS = xenlogd.o
+XENLOGD_OBJS = xenlogd.o io.o
$(XENLOGD_OBJS): CFLAGS += $(CFLAGS_libxenstore)
$(XENLOGD_OBJS): CFLAGS += $(CFLAGS_libxenevtchn)
$(XENLOGD_OBJS): CFLAGS += $(CFLAGS_libxengnttab)
diff --git a/tools/xenlogd/io.c b/tools/xenlogd/io.c
new file mode 100644
index 00..ef0954d69d
--- /dev/null
+++ b/tools/xenlogd/io.c
@@ -0,0 +1,45 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+/*
+ * xenlogd - Xen logging daemon
+ *
+ * Copyright (C) 2023 Juergen Gross
+ *
+ * I/O thread handling.
+ */
+
+#include
+#include
+#include
+
+#include "xenlogd.h"
+
+static bool io_work_pending(device *device)
+{
+if ( device->stop_thread )
+return true;
+return false;
+}
+
+void *io_thread(void *arg)
+{
+device *device = arg;
+
+while ( !device->stop_thread )
+{
+pthread_mutex_lock(&device->mutex);
+if ( !io_work_pending(device) )
+{
+if ( xenevtchn_unmask(xe, device->evtchn) < 0 )
+syslog(LOG_WARNING, "xenevtchn_unmask() failed");
+pthread_cond_wait(&device->cond, &device->mutex);
+}
+pthread_mutex_unlock(&device->mutex);
+
+/* TODO: I/O handling. */
+}
+
+device->thread_active = false;
+
+return NULL;
+}
diff --git a/tools/xenlogd/xenlogd.c b/tools/xenlogd/xenlogd.c
index 792d1026a3..da0a09a122 100644
--- a/tools/xenlogd/xenlogd.c
+++ b/tools/xenlogd/xenlogd.c
@@ -24,34 +24,562 @@
#include
#include
+#include
+#include
#include
#include
#include
#include
#include
#include
+#include
#include
#include
#include
-#include
#include
#include
+#include "xenlogd.h"
+
+/*
+ * List of currently known devices.
+ * The list itself is modified only in the main thread. When a device is being
+ * removed its memory needs to be freed after the I/O thread (if existing)
+ * has stopped.
+ */
+static XEN_TAILQ_HEAD(devhead, device) devs = XEN_TAILQ_HEAD_INITIALIZER(devs);
+
+struct path {
+char path[100];
+};
+
static bool stop_me;
static bool daemon_running;
static struct xs_handle *xs;
static xengnttab_handle *xg;
-static xenevtchn_handle *xe;
+static unsigned int now;
+
+xenevtchn_handle *xe;
static void handle_stop(int sig)
{
stop_me = true;
}
+static int check_host_path(device *device)
+{
+struct stat statbuf;
+char *path, *p;
+int ret = 1;
+
+if ( !device->host_path )
+return 1;
+
+if ( device->host_path[0] != '/' )
+return 1;
+
+path = strdup(device->host_path);
+if ( !path )
+{
+syslog(LOG_CRIT, "memory allocation failure!");
+return 1;
+}
+
+for ( p = path; p; )
+{
+p = strchr(p + 1, '/');
+if ( p )
+*p = 0;
+if ( !stat(path, &statbuf) )
+{
+if ( !(statbuf.st_mode & S_IFDIR) )
+break;
+if ( !p )
+{
+ret = 0;
+break;
+}
+*p = '/';
+continue;
+}
+if ( mkdir(path, 0777) )
+break;
+if ( p )
+*p = '/';
+}
+
+free(path);
+return ret;
+}
+
+static void construct_frontend_path(device *device, const char *node,
+struct path *p)
+{
+snprintf(p->path, sizeof(p->path), "/local/domain/%u/device/9pfs/%u/%s",
+ device->domid, device->devid, node);
+}
+
+static void construct_backend_path(device *device, const char *node,
+ struct path *p)
+{
+snprintf(p->path, sizeof(p->path), "backend/xen_9pfs/%u/%u/%s",
+ device->domid, device->devid, node);
+}
+
+static char *read_backend_node(device *device, const char *node)
+{
+struct path p;
+char *val;
+unsigned int len;
+
+construct_backend_path(device, node, &p);
+val = xs_read(xs, XBT_NULL, p.path, &len);
+
+return val;
+}
+
+static unsigned int uint_from_string(char *string, unsigned int def)
+{
+unsigned long val;
+char *end;
+
+if ( !string )
+return def;
+
+val = strtoul(string, &end, 10);
+if ( *end || val > UINT_MAX )
+val = def;
+free(string);
+
+return val;
+}
+
+static unsigned int read_backend_node_uint(device *device, const char *node,
+ unsigned int def)
+{
+re
[PATCH 05/29] tools/xenlogd: add 9pfs response generation support
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 response handling add a generic p9_error()
function which will be used to return any error to the client.
Add all format parsing variants in order to avoid additional code churn
later when adding the users of those variants. Prepare a special case
for the "read" case already (format character 'D'): in order to avoid
adding another buffer for read data support doing the read I/O directly
into the response buffer.
Signed-off-by: Juergen Gross
---
tools/xenlogd/io.c | 189 +++-
tools/xenlogd/xenlogd.h | 3 +
2 files changed, 191 insertions(+), 1 deletion(-)
diff --git a/tools/xenlogd/io.c b/tools/xenlogd/io.c
index 590d06e906..5a06f72338 100644
--- a/tools/xenlogd/io.c
+++ b/tools/xenlogd/io.c
@@ -11,6 +11,7 @@
* before looking for the next request.
*/
+#include
#include
#include
#include
@@ -20,6 +21,16 @@
#include "xenlogd.h"
+/* P9 protocol commands (response is either cmd+1 or P9_CMD_ERROR). */
+#define P9_CMD_ERROR 107
+
+struct p9_qid {
+uint8_t type;
+#define QID_TYPE_DIR 0x80
+uint32_t version;
+uint64_t path;
+};
+
/*
* Note that the ring names "in" and "out" are from the frontend's
* perspective, so the "in" ring will be used for responses to the frontend,
@@ -101,6 +112,172 @@ static bool io_work_pending(device *device)
: ring_out_data(device);
}
+static void fmt_err(const char *fmt)
+{
+syslog(LOG_CRIT, "illegal format %s passed to fill_buffer()", fmt);
+exit(1);
+}
+
+/*
+ * Fill buffer with response data.
+ * fmt is a sequence of format characters. Supported characters are:
+ * a: an array (2 bytes number of elements + the following format as elements)
+ *The number of elements is passed in the first unsigned int parameter, the
+ *next parameter is a pointer to an array of elements as denoted by the
next
+ *format character.
+ * b: 2 byte unsigned integer
+ *The parameter is a pointer to a uint16_t value
+ * D: Data blob (4 byte length + bytes)
+ *2 parameters are consumed, first an unsigned int for the length, then a
+ *pointer to the first uint8_t value.
+ *No array support.
+ * L: 8 byte unsigned integer
+ *The parameter is a pointer to a uint64_t value
+ * Q: Qid (struct p9_qid)
+ * S: String (2 byte length + characters)
+ *The length is obtained via strlen() of the parameter, being a pointer
+ *to the first character of the string
+ * U: 4 byte unsigned integer
+ *The parameter is a pointer to a uint32_t value
+ */
+static void fill_buffer(device *device, uint8_t cmd, uint16_t tag,
+const char *fmt, ...)
+{
+struct p9_header *hdr = device->buffer;
+void *data = hdr + 1;
+const char *f;
+const void *par;
+const char *str_val;
+const struct p9_qid *qid;
+unsigned int len;
+va_list ap;
+unsigned int array_sz = 0;
+unsigned int elem_sz = 0;
+
+hdr->cmd = cmd;
+hdr->tag = tag;
+
+va_start(ap, fmt);
+
+for ( f = fmt; *f; f++ )
+{
+if ( !array_sz )
+par = va_arg(ap, const void *);
+else
+{
+par += elem_sz;
+array_sz--;
+}
+
+switch ( *f )
+{
+case 'a':
+f++;
+if ( !*f || array_sz )
+fmt_err(fmt);
+array_sz = *(const unsigned int *)par;
+*(__packed uint16_t *)data = array_sz;
+data += sizeof(uint16_t);
+par = va_arg(ap, const void *);
+elem_sz = 0;
+break;
+
+case 'u':
+*(__packed uint16_t *)data = *(const uint16_t *)par;
+elem_sz = sizeof(uint16_t);
+data += sizeof(uint16_t);
+break;
+
+case 'D':
+if ( array_sz )
+fmt_err(fmt);
+len = *(const unsigned int *)par;
+*(__packed uint32_t *)data = len;
+data += sizeof(uint32_t);
+par = va_arg(ap, const void *);
+if ( data != par )
+memcpy(data, par, len);
+data += len;
+break;
+
+case 'L':
+*(__packed uint64_t *)data = *(const uint64_t *)par;
+elem_sz = sizeof(uint64_t);
+data += sizeof(uint64_t);
+break;
+
+case 'Q':
+qid = par;
+elem_sz = sizeof(*qid);
+*(uint8_t *)data = qid->type;
+data += sizeof(uint8_t);
+*(__packed uint32_t *)data = qid->version;
+data += sizeof(uint32_t);
+*(__packed uint64_t *)data = qid->path;
+data += sizeof(uint64_t);
+
[PATCH 02/29] tools: add a new xen logging daemon
Add "xenlogd", a new logging daemon meant to support infrastructure
domains (e.g. xenstore-stubdom) to write log files in dom0.
For now only add the code needed for starting the daemon and
registering it with Xenstore via a new "/tool/xenlog/state" node by
writing the "running" state to it.
Signed-off-by: Juergen Gross
---
tools/Makefile | 1 +
tools/xenlogd/.gitignore | 1 +
tools/xenlogd/Makefile | 38 ++
tools/xenlogd/xenlogd.c | 145 +++
4 files changed, 185 insertions(+)
create mode 100644 tools/xenlogd/.gitignore
create mode 100644 tools/xenlogd/Makefile
create mode 100644 tools/xenlogd/xenlogd.c
diff --git a/tools/Makefile b/tools/Makefile
index 3a510663a0..0225020416 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -32,6 +32,7 @@ SUBDIRS-y += xenpmd
SUBDIRS-$(CONFIG_GOLANG) += golang
SUBDIRS-y += xl
SUBDIRS-y += helpers
+SUBDIRS-y += xenlogd
SUBDIRS-$(CONFIG_X86) += xenpaging
SUBDIRS-$(CONFIG_X86) += debugger
SUBDIRS-$(CONFIG_TESTS) += tests
diff --git a/tools/xenlogd/.gitignore b/tools/xenlogd/.gitignore
new file mode 100644
index 00..a0305ae096
--- /dev/null
+++ b/tools/xenlogd/.gitignore
@@ -0,0 +1 @@
+/xenlogd
diff --git a/tools/xenlogd/Makefile b/tools/xenlogd/Makefile
new file mode 100644
index 00..550e914f59
--- /dev/null
+++ b/tools/xenlogd/Makefile
@@ -0,0 +1,38 @@
+#
+# tools/helpers/Makefile
+#
+
+XEN_ROOT = $(CURDIR)/../..
+include $(XEN_ROOT)/tools/Rules.mk
+
+CFLAGS += $(PTHREAD_CFLAGS)
+LDFLAGS += $(PTHREAD_LDFLAGS)
+
+TARGETS := xenlogd
+
+XENLOGD_OBJS = xenlogd.o
+$(XENLOGD_OBJS): CFLAGS += $(CFLAGS_libxenstore)
+$(XENLOGD_OBJS): CFLAGS += $(CFLAGS_libxenevtchn)
+$(XENLOGD_OBJS): CFLAGS += $(CFLAGS_libxengnttab)
+xenlogd: LDLIBS += $(call xenlibs-ldlibs,store evtchn gnttab)
+
+.PHONY: all
+all: $(TARGETS)
+
+xenlogd: $(XENLOGD_OBJS)
+ $(CC) $(LDFLAGS) -o $@ $(XENLOGD_OBJS) $(LDLIBS) $(APPEND_LDFLAGS)
+
+.PHONY: install
+install: all
+ $(INSTALL_DIR) $(DESTDIR)$(LIBEXEC_BIN)
+ for i in $(TARGETS); do $(INSTALL_PROG) $$i $(DESTDIR)$(LIBEXEC_BIN);
done
+
+.PHONY: uninstall
+uninstall:
+ for i in $(TARGETS); do rm -f $(DESTDIR)$(LIBEXEC_BIN)/$$i; done
+
+.PHONY: clean
+clean:
+ $(RM) *.o $(TARGETS) $(DEPS_RM)
+
+distclean: clean
diff --git a/tools/xenlogd/xenlogd.c b/tools/xenlogd/xenlogd.c
new file mode 100644
index 00..792d1026a3
--- /dev/null
+++ b/tools/xenlogd/xenlogd.c
@@ -0,0 +1,145 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+/*
+ * xenlogd - Xen logging daemon
+ *
+ * Copyright (C) 2023 Juergen Gross
+ *
+ * Daemon to enable guests to access a directory of the dom0 file system.
+ * Access is made via the 9pfs protocol (xenlogd acts as a PV 9pfs backend).
+ *
+ * Usage: xenlogd
+ *
+ * xenlogd does NOT support writing any links (neither soft links nor hard
+ * links), and it is accepting only canonicalized file paths in order to
+ * avoid the possibility to "escape" from the guest specific directory.
+ *
+ * The backend device string is "xen_9pfs", the tag used for mounting the
+ * 9pfs device is "Xen".
+ *
+ * As an additional security measure the maximum file space used by the guest
+ * can be limited by the backend Xenstore node "max-size" specifying the size
+ * in MBytes. This size includes the size of the root directory of the guest.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static bool stop_me;
+static bool daemon_running;
+static struct xs_handle *xs;
+static xengnttab_handle *xg;
+static xenevtchn_handle *xe;
+
+static void handle_stop(int sig)
+{
+stop_me = true;
+}
+
+static void close_all(void)
+{
+if ( daemon_running )
+xs_rm(xs, XBT_NULL, "/tool/xenlog");
+if ( xe )
+xenevtchn_close(xe);
+if ( xg )
+xengnttab_close(xg);
+if ( xs )
+xs_close(xs);
+closelog();
+}
+
+static void do_err(const char *msg)
+{
+syslog(LOG_ALERT, "%s, errno = %d", msg, errno);
+close_all();
+exit(1);
+}
+
+static void xen_connect(void)
+{
+xs_transaction_t t;
+char *val;
+unsigned int len;
+
+xs = xs_open(0);
+if ( xs == NULL )
+do_err("xs_open() failed");
+
+xg = xengnttab_open(NULL, 0);
+if ( xg == NULL )
+do_err("xengnttab_open() failed");
+
+xe = xenevtchn_open(NULL, 0);
+if ( xe == NULL )
+do_err("xenevtchn_open() failed");
+
+while ( true )
+{
+t = xs_transaction_start(xs);
+if ( t == XBT_NULL )
+do_err("xs_transaction_start() failed");
+
+val = xs_read(xs, t, "/tool/xenlog/state", &len);
+if ( val )
+{
+free(val);
+xs_transaction_end(xs, t, true);
+do_err("daemon already running");
+}
+
+if ( !xs_write(xs, t, "/tool/xenlog/state", "running",
+ strlen("running")) )
+
[PATCH 04/29] tools/xenlogd: add transport layer
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
---
tools/include/xen-tools/common-macros.h | 4 +
tools/xenlogd/io.c | 142 +++-
tools/xenlogd/xenlogd.h | 16 +++
3 files changed, 160 insertions(+), 2 deletions(-)
diff --git a/tools/include/xen-tools/common-macros.h
b/tools/include/xen-tools/common-macros.h
index e5ed603904..c3fd7d2a30 100644
--- a/tools/include/xen-tools/common-macros.h
+++ b/tools/include/xen-tools/common-macros.h
@@ -79,6 +79,10 @@
#define __must_check __attribute__((__warn_unused_result__))
#endif
+#ifndef __packed
+#define __packed __attribute__((__packed__))
+#endif
+
#define container_of(ptr, type, member) ({ \
typeof(((type *)0)->member) *mptr__ = (ptr);\
(type *)((char *)mptr__ - offsetof(type, member)); \
diff --git a/tools/xenlogd/io.c b/tools/xenlogd/io.c
index ef0954d69d..590d06e906 100644
--- a/tools/xenlogd/io.c
+++ b/tools/xenlogd/io.c
@@ -6,24 +6,115 @@
* Copyright (C) 2023 Juergen Gross
*
* I/O thread handling.
+ *
+ * Only handle one request at a time, pushing out the complete response
+ * before looking for the next request.
*/
#include
+#include
#include
#include
+#include/* For cpu barriers. */
+#include
#include "xenlogd.h"
+/*
+ * Note that the ring names "in" and "out" are from the frontend's
+ * perspective, so the "in" ring will be used for responses to the frontend,
+ * while the "out" ring is used for requests from the frontend to the
+ * backend.
+ */
+static unsigned int ring_in_free(device *device)
+{
+unsigned int queued;
+
+queued = xen_9pfs_queued(device->prod_pvt_in, device->intf->in_cons,
+ device->ring_size);
+xen_rmb();
+
+return device->ring_size - queued;
+}
+
+static unsigned int ring_out_data(device *device)
+{
+unsigned int queued;
+
+queued = xen_9pfs_queued(device->intf->out_prod, device->cons_pvt_out,
+ device->ring_size);
+xen_rmb();
+
+return queued;
+}
+
+static unsigned int get_request_bytes(device *device, unsigned int off,
+ unsigned int len)
+{
+unsigned int size;
+unsigned int out_data = ring_out_data(device);
+RING_IDX prod, cons;
+
+size = min(len - off, out_data);
+prod = xen_9pfs_mask(device->intf->out_prod, device->ring_size);
+cons = xen_9pfs_mask(device->cons_pvt_out, device->ring_size);
+xen_9pfs_read_packet(device->buffer + off, device->data.out, size,
+ prod, &cons, device->ring_size);
+
+xen_rmb(); /* Read data out before setting visible consumer. */
+device->cons_pvt_out += size;
+device->intf->out_cons = device->cons_pvt_out;
+
+/* Signal that more space is available now. */
+xenevtchn_notify(xe, device->evtchn);
+
+return size;
+}
+
+static unsigned int put_request_bytes(device *device, unsigned int off,
+ unsigned int len)
+{
+unsigned int size;
+unsigned int in_data = ring_in_free(device);
+RING_IDX prod, cons;
+
+size = min(len - off, in_data);
+prod = xen_9pfs_mask(device->prod_pvt_in, device->ring_size);
+cons = xen_9pfs_mask(device->intf->in_cons, device->ring_size);
+xen_9pfs_write_packet(device->data.in, device->buffer + off, size,
+ &prod, cons, device->ring_size);
+
+xen_wmb(); /* Write data out before setting visible producer. */
+device->prod_pvt_in += size;
+device->intf->in_prod = device->prod_pvt_in;
+
+return size;
+}
+
static bool io_work_pending(device *device)
{
if ( device->stop_thread )
return true;
-return false;
+if ( device->error )
+return false;
+return device->handle_response ? ring_in_free(device)
+ : ring_out_data(device);
}
void *io_thread(void *arg)
{
device *device = arg;
+unsigned int count = 0;
+struct p9_header hdr;
+bool in_hdr = true;
+
+device->max_size = device->ring_size;
+device->buffer = malloc(device->max_size);
+if ( !device->buffer )
+{
+syslog(LOG_CRIT, "memory allocation failure!");
+return NULL;
+}
while ( !device->stop_thread )
{
@@ -36,9 +127,56 @@ void *io_thread(void *arg)
}
pthread_mutex_unlock(&device->mutex);
-/* TODO: I/O handling. */
+if ( device->stop_thread || device->error )
+continue;
+
+if ( !device->handle_response )
+{
+if ( in_hdr )
+{
+count += get_request_bytes(device, count, sizeof(hdr));
+if ( coun
[PATCH 12/29] tools/xenlogd: add 9pfs stat request support
Add the stat request of the 9pfs protocol.
Signed-off-by: Juergen Gross
---
tools/xenlogd/io.c | 89 ++
1 file changed, 89 insertions(+)
diff --git a/tools/xenlogd/io.c b/tools/xenlogd/io.c
index 34f137be1b..6e92667fab 100644
--- a/tools/xenlogd/io.c
+++ b/tools/xenlogd/io.c
@@ -33,6 +33,7 @@
#define P9_CMD_OPEN 112
#define P9_CMD_CREATE 114
#define P9_CMD_CLUNK 120
+#define P9_CMD_STAT 124
/* P9 protocol open flags. */
#define P9_OREAD0 /* read */
@@ -59,6 +60,25 @@ struct p9_qid {
uint64_t path;
};
+struct p9_stat {
+uint16_t size;
+uint16_t type;
+uint32_t dev;
+struct p9_qid qid;
+uint32_t mode;
+uint32_t atime;
+uint32_t mtime;
+uint64_t length;
+const char *name;
+const char *uid;
+const char *gid;
+const char *muid;
+const char *extension;
+uint32_t n_uid;
+uint32_t n_gid;
+uint32_t n_muid;
+};
+
/*
* Note that the ring names "in" and "out" are from the frontend's
* perspective, so the "in" ring will be used for responses to the frontend,
@@ -1022,6 +1042,71 @@ static void p9_clunk(device *device, struct p9_header
*hdr)
fill_buffer(device, hdr->cmd + 1, hdr->tag, "");
}
+static void fill_p9_stat(struct p9_stat *p9s, struct stat *st, const char
*name)
+{
+memset(p9s, 0, sizeof(*p9s));
+fill_qid(NULL, &p9s->qid, st);
+p9s->mode = st->st_mode & 0777;
+if ( S_ISDIR(st->st_mode) )
+p9s->mode |= P9_CREATE_PERM_DIR;
+p9s->atime = st->st_atime;
+p9s->mtime = st->st_mtime;
+p9s->length = st->st_size;
+p9s->name = name;
+p9s->uid = "";
+p9s->gid = "";
+p9s->muid = "";
+p9s->extension = "";
+p9s->n_uid = 0;
+p9s->n_gid = 0;
+p9s->n_muid = 0;
+
+/*
+ * Size of individual fields without the size field, including 5 2-byte
+ * string length fields.
+ */
+p9s->size = 71 + strlen(p9s->name);
+}
+
+static void p9_stat(device *device, struct p9_header *hdr)
+{
+uint32_t fid;
+struct p9_fid *fidp;
+struct p9_stat p9s;
+struct stat st;
+uint16_t total_length;
+int ret;
+
+ret = fill_data(device, "U", &fid);
+if ( ret != 1 )
+{
+p9_error(device, hdr->tag, EINVAL);
+return;
+}
+
+fidp = find_fid(device, fid);
+if ( !fidp )
+{
+p9_error(device, hdr->tag, ENOENT);
+return;
+}
+
+if ( stat(fidp->path, &st) < 0 )
+{
+p9_error(device, hdr->tag, errno);
+return;
+}
+fill_p9_stat(&p9s, &st, strrchr(fidp->path, '/') + 1);
+
+total_length = p9s.size + sizeof(p9s.size);
+fill_buffer(device, hdr->cmd + 1, hdr->tag, "uuuUQUUULSUUU",
+&total_length, &p9s.size, &p9s.type, &p9s.dev, &p9s.qid,
+&p9s.mode, &p9s.atime, &p9s.mtime, &p9s.length, p9s.name,
+p9s.uid, p9s.gid, p9s.muid, p9s.extension, &p9s.n_uid,
+&p9s.n_gid, &p9s.n_muid);
+
+}
+
void *io_thread(void *arg)
{
device *device = arg;
@@ -1101,6 +1186,10 @@ void *io_thread(void *arg)
p9_clunk(device, &hdr);
break;
+case P9_CMD_STAT:
+p9_stat(device, &hdr);
+break;
+
default:
syslog(LOG_DEBUG, "%u.%u sent unhandled command %u\n",
device->domid, device->devid, hdr.cmd);
--
2.35.3
[PATCH 11/29] tools/xenlogd: add 9pfs create request support
Add the create request of the 9pfs protocol.
Signed-off-by: Juergen Gross
---
tools/xenlogd/io.c | 133 +
1 file changed, 133 insertions(+)
diff --git a/tools/xenlogd/io.c b/tools/xenlogd/io.c
index 2607095e51..34f137be1b 100644
--- a/tools/xenlogd/io.c
+++ b/tools/xenlogd/io.c
@@ -31,6 +31,7 @@
#define P9_CMD_ERROR 107
#define P9_CMD_WALK 110
#define P9_CMD_OPEN 112
+#define P9_CMD_CREATE 114
#define P9_CMD_CLUNK 120
/* P9 protocol open flags. */
@@ -41,6 +42,12 @@
#define P9_OTRUNC0x10 /* or'ed in, truncate file first */
#define P9_OREMOVE 0x40 /* or'ed in, remove file after clunk */
+/* P9 protocol create permission masks. */
+#define P9_CREATE_PERM_DIR0x8000
+#define P9_CREATE_PERM_NOTSUPP0x03b0 /* link, symlink, ... */
+#define P9_CREATE_PERM_DIR_MASK 0777
+#define P9_CREATE_PERM_FILE_MASK 0666
+
#define P9_MIN_MSIZE 2048
#define P9_VERSION"9P2000.u"
#define P9_WALK_MAXELEM 16
@@ -861,6 +868,128 @@ static void p9_open(device *device, struct p9_header *hdr)
fill_buffer(device, hdr->cmd + 1, hdr->tag, "QU", &qid, &iounit);
}
+static void p9_create(device *device, struct p9_header *hdr)
+{
+uint32_t fid;
+unsigned int name_off;
+uint32_t perm;
+uint8_t mode;
+unsigned int ext_off;
+struct p9_fid *fidp;
+struct p9_fid *new_fidp;
+char *path;
+struct stat st;
+struct p9_qid qid;
+uint32_t iounit;
+int flags;
+int ret;
+
+ret = fill_data(device, "USUbS", &fid, &name_off, &perm, &mode, &ext_off);
+if ( ret != 5 )
+{
+p9_error(device, hdr->tag, EINVAL);
+return;
+}
+
+if ( !name_ok(device->str + name_off) )
+{
+p9_error(device, hdr->tag, ENOENT);
+return;
+}
+
+if ( perm & P9_CREATE_PERM_NOTSUPP )
+{
+p9_error(device, hdr->tag, EINVAL);
+return;
+}
+
+fidp = find_fid(device, fid);
+if ( !fidp || fidp->opened )
+{
+p9_error(device, hdr->tag, EINVAL);
+return;
+}
+
+path = malloc(strlen(fidp->path) + strlen(device->str + name_off) + 2 -
+ strlen(device->host_path));
+if ( !path )
+{
+p9_error(device, hdr->tag, ENOMEM);
+return;
+}
+sprintf(path, "%s/%s", fidp->path + strlen(device->host_path),
+device->str + name_off);
+new_fidp = alloc_fid_mem(device, fid, path);
+free(path);
+if ( !new_fidp )
+{
+p9_error(device, hdr->tag, ENOMEM);
+return;
+}
+
+if ( perm & P9_CREATE_PERM_DIR )
+{
+if ( mode != P9_OREAD )
+{
+p9_error(device, hdr->tag, EINVAL);
+free(new_fidp);
+return;
+}
+if ( mkdir(new_fidp->path, perm & P9_CREATE_PERM_DIR_MASK) < 0 )
+{
+p9_error(device, hdr->tag, errno);
+free(new_fidp);
+return;
+}
+
+XEN_TAILQ_REMOVE(&device->fids, fidp, list);
+XEN_TAILQ_INSERT_HEAD(&device->fids, new_fidp, list);
+free(fidp);
+fidp = new_fidp;
+
+fidp->data = opendir(fidp->path);
+if ( !fidp->data )
+{
+p9_error(device, hdr->tag, errno);
+return;
+}
+fidp->fd = dirfd(fidp->data);
+}
+else
+{
+flags = open_flags_from_mode(mode);
+if ( flags < 0 )
+{
+p9_error(device, hdr->tag, EINVAL);
+free(new_fidp);
+return;
+}
+
+XEN_TAILQ_REMOVE(&device->fids, fidp, list);
+XEN_TAILQ_INSERT_HEAD(&device->fids, new_fidp, list);
+free(fidp);
+fidp = new_fidp;
+
+fidp->fd = creat(fidp->path, flags);
+if ( fidp->fd < 0 )
+{
+p9_error(device, hdr->tag, errno);
+return;
+}
+}
+
+if ( stat(fidp->path, &st) < 0 )
+{
+p9_error(device, hdr->tag, errno);
+return;
+}
+fill_qid(fidp->path, &qid, &st);
+iounit = get_iounit(device, &st);
+fidp->opened = true;
+
+fill_buffer(device, hdr->cmd + 1, hdr->tag, "QU", &qid, &iounit);
+}
+
static void p9_clunk(device *device, struct p9_header *hdr)
{
uint32_t fid;
@@ -964,6 +1093,10 @@ void *io_thread(void *arg)
p9_open(device, &hdr);
break;
+case P9_CMD_CREATE:
+p9_create(device, &hdr);
+break;
+
case P9_CMD_CLUNK:
p9_clunk(device, &hdr);
break;
--
2.35.3
[PATCH 14/29] tools/xenlogd: add 9pfs read request support
Add the read request of the 9pfs protocol.
For now support only reading plain files (no directories).
Signed-off-by: Juergen Gross
---
tools/xenlogd/io.c | 60 ++
1 file changed, 60 insertions(+)
diff --git a/tools/xenlogd/io.c b/tools/xenlogd/io.c
index 6b4692ca67..b3f9f96bcc 100644
--- a/tools/xenlogd/io.c
+++ b/tools/xenlogd/io.c
@@ -32,6 +32,7 @@
#define P9_CMD_WALK 110
#define P9_CMD_OPEN 112
#define P9_CMD_CREATE 114
+#define P9_CMD_READ 116
#define P9_CMD_WRITE 118
#define P9_CMD_CLUNK 120
#define P9_CMD_STAT 124
@@ -1011,6 +1012,61 @@ static void p9_create(device *device, struct p9_header
*hdr)
fill_buffer(device, hdr->cmd + 1, hdr->tag, "QU", &qid, &iounit);
}
+static void p9_read(device *device, struct p9_header *hdr)
+{
+uint32_t fid;
+uint64_t off;
+unsigned int len;
+uint32_t count;
+void *buf;
+struct p9_fid *fidp;
+int ret;
+
+ret = fill_data(device, "ULU", &fid, &off, &count);
+if ( ret != 3 )
+{
+p9_error(device, hdr->tag, EINVAL);
+return;
+}
+
+fidp = find_fid(device, fid);
+if ( !fidp || !fidp->opened )
+{
+p9_error(device, hdr->tag, EBADF);
+return;
+}
+
+if ( fidp->isdir )
+{
+p9_error(device, hdr->tag, EOPNOTSUPP);
+return;
+}
+else
+{
+len = count;
+buf = device->buffer + sizeof(*hdr) + sizeof(uint32_t);
+
+while ( len != 0 )
+{
+ret = pread(fidp->fd, buf, len, off);
+if ( ret <= 0 )
+break;
+len -= ret;
+buf += ret;
+off += ret;
+}
+if ( ret && len == count )
+{
+p9_error(device, hdr->tag, errno);
+return;
+}
+
+buf = device->buffer + sizeof(*hdr) + sizeof(uint32_t);
+len = count - len;
+fill_buffer(device, hdr->cmd + 1, hdr->tag, "D", &len, buf);
+}
+}
+
static void p9_write(device *device, struct p9_header *hdr)
{
uint32_t fid;
@@ -1228,6 +1284,10 @@ void *io_thread(void *arg)
p9_create(device, &hdr);
break;
+case P9_CMD_READ:
+p9_read(device, &hdr);
+break;
+
case P9_CMD_WRITE:
p9_write(device, &hdr);
break;
--
2.35.3
[PATCH 25/29] tools/xenstored: mount 9pfs device in stubdom
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
---
tools/xenstored/core.h | 5 +
tools/xenstored/domain.c | 2 ++
tools/xenstored/minios.c | 35 +++
3 files changed, 42 insertions(+)
diff --git a/tools/xenstored/core.h b/tools/xenstored/core.h
index f7a27a4131..48ff659ec5 100644
--- a/tools/xenstored/core.h
+++ b/tools/xenstored/core.h
@@ -35,6 +35,8 @@
#include "list.h"
#include "hashtable.h"
+#define XENSTORE_LIB_DIR XEN_LIB_DIR "/xenstore"
+
#ifndef O_CLOEXEC
#define O_CLOEXEC 0
/* O_CLOEXEC support is needed for Live Update in the daemon case. */
@@ -385,6 +387,9 @@ static inline bool domain_is_unprivileged(const struct
connection *conn)
/* Return the event channel used by xenbus. */
evtchn_port_t get_xenbus_evtchn(void);
+#ifdef __MINIOS__
+void mount_9pfs(void);
+#endif
/* Write out the pidfile */
void write_pidfile(const char *pidfile);
diff --git a/tools/xenstored/domain.c b/tools/xenstored/domain.c
index 162b87b460..4263c1360f 100644
--- a/tools/xenstored/domain.c
+++ b/tools/xenstored/domain.c
@@ -1236,6 +1236,8 @@ void stubdom_init(void)
barf_perror("Failed to initialize stubdom");
xenevtchn_notify(xce_handle, stubdom->port);
+
+ mount_9pfs();
#endif
}
diff --git a/tools/xenstored/minios.c b/tools/xenstored/minios.c
index 0779efbf91..e5a3684df6 100644
--- a/tools/xenstored/minios.c
+++ b/tools/xenstored/minios.c
@@ -19,6 +19,14 @@
#include
#include "core.h"
#include
+#include
+#include
+#include
+#include
+
+#define P9_STATE_PATH "device/9pfs/0/state"
+
+static void *p9_device;
void write_pidfile(const char *pidfile)
{
@@ -54,3 +62,30 @@ void unmap_xenbus(void *interface)
xengnttab_unmap(*xgt_handle, interface, 1);
}
+static void mount_thread(void *p)
+{
+ xenbus_event_queue events = NULL;
+ char *err;
+ char *dummy;
+
+ free(xenbus_watch_path_token(XBT_NIL, P9_STATE_PATH, "9pfs", &events));
+
+ for (;;) {
+ xenbus_wait_for_watch(&events);
+ err = xenbus_read(XBT_NIL, P9_STATE_PATH, &dummy);
+ if (!err)
+ break;
+ free(err);
+ }
+
+ free(dummy);
+
+ free(xenbus_unwatch_path_token(XBT_NIL, P9_STATE_PATH, "9pfs"));
+
+ p9_device = init_9pfront(0, XENSTORE_LIB_DIR);
+}
+
+void mount_9pfs(void)
+{
+ create_thread("mount-9pfs", mount_thread, NULL);
+}
--
2.35.3
[PATCH 24/29] tools/xenstored: map stubdom interface
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(+), 1 deletion(-)
diff --git a/tools/xenstored/core.c b/tools/xenstored/core.c
index 42a848e098..1764b1af4e 100644
--- a/tools/xenstored/core.c
+++ b/tools/xenstored/core.c
@@ -3003,6 +3003,8 @@ int main(int argc, char *argv[])
lu_read_state();
#endif
+ stubdom_init();
+
check_store();
/* Get ready to listen to the tools. */
diff --git a/tools/xenstored/domain.c b/tools/xenstored/domain.c
index fa17f68618..162b87b460 100644
--- a/tools/xenstored/domain.c
+++ b/tools/xenstored/domain.c
@@ -37,6 +37,10 @@
#include
#include
+#ifdef __MINIOS__
+#include
+#endif
+
static xc_interface **xc_handle;
xengnttab_handle **xgt_handle;
static evtchn_port_t virq_port;
@@ -500,6 +504,11 @@ static void *map_interface(domid_t domid)
if (domid == xenbus_master_domid())
return xenbus_map();
+#ifdef __MINIOS__
+ if (domid == stub_domid)
+ return xenstore_buf;
+#endif
+
return xengnttab_map_grant_ref(*xgt_handle, domid,
GNTTAB_RESERVED_XENSTORE,
PROT_READ|PROT_WRITE);
@@ -509,7 +518,7 @@ static void unmap_interface(domid_t domid, void *interface)
{
if (domid == xenbus_master_domid())
unmap_xenbus(interface);
- else
+ else if (domid != stub_domid)
xengnttab_unmap(*xgt_handle, interface, 1);
}
@@ -1214,6 +1223,22 @@ void dom0_init(void)
xenevtchn_notify(xce_handle, dom0->port);
}
+void stubdom_init(void)
+{
+#ifdef __MINIOS__
+ struct domain *stubdom;
+
+ if (stub_domid < 0)
+ return;
+
+ stubdom = introduce_domain(NULL, stub_domid, xenbus_evtchn, false);
+ if (!stubdom)
+ barf_perror("Failed to initialize stubdom");
+
+ xenevtchn_notify(xce_handle, stubdom->port);
+#endif
+}
+
static unsigned int domhash_fn(const void *k)
{
return *(const unsigned int *)k;
diff --git a/tools/xenstored/domain.h b/tools/xenstored/domain.h
index 6c00540311..49c60c56bf 100644
--- a/tools/xenstored/domain.h
+++ b/tools/xenstored/domain.h
@@ -85,6 +85,7 @@ int do_reset_watches(const void *ctx, struct connection *conn,
void domain_static_init(void);
void domain_init(int evtfd);
void dom0_init(void);
+void stubdom_init(void);
void domain_deinit(void);
void ignore_connection(struct connection *conn, unsigned int err);
--
2.35.3
[PATCH 21/29] tools: tell xenstore-stubdom its own domid
Pass the domid as a boot parameter when starting xenstore-stubdom.
It will be needed to administrate its own Xenstore entries.
Signed-off-by: Juergen Gross
---
tools/helpers/init-xenstore-domain.c | 4 ++--
tools/xenstored/core.c | 9 +
tools/xenstored/core.h | 1 +
3 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/tools/helpers/init-xenstore-domain.c
b/tools/helpers/init-xenstore-domain.c
index a65abae2ac..718cb3ba4e 100644
--- a/tools/helpers/init-xenstore-domain.c
+++ b/tools/helpers/init-xenstore-domain.c
@@ -240,9 +240,9 @@ static int build(xc_interface *xch)
}
if ( param )
-snprintf(cmdline, 512, "--event %d %s", rv, param);
+snprintf(cmdline, 512, "--event %d --domid %u %s", rv, domid, param);
else
-snprintf(cmdline, 512, "--event %d", rv);
+snprintf(cmdline, 512, "--event %d --domid %u", rv, domid);
dom->guest_domid = domid;
dom->cmdline = xc_dom_strdup(dom, cmdline);
diff --git a/tools/xenstored/core.c b/tools/xenstored/core.c
index edd07711db..bb4612455d 100644
--- a/tools/xenstored/core.c
+++ b/tools/xenstored/core.c
@@ -2732,12 +2732,16 @@ static struct option options[] = {
{ "watch-nb", 1, NULL, 'W' },
#ifndef NO_LIVE_UPDATE
{ "live-update", 0, NULL, 'U' },
+#endif
+#ifdef __MINIOS__
+ { "domid", 1, NULL, 2 },
#endif
{ NULL, 0, NULL, 0 } };
int dom0_domid = 0;
int dom0_event = 0;
int priv_domid = 0;
+int stub_domid = -1;
static unsigned int get_optval_uint(const char *arg)
{
@@ -2927,6 +2931,11 @@ int main(int argc, char *argv[])
case 'U':
live_update = true;
break;
+#endif
+#ifdef __MINIOS__
+ case 2:
+ stub_domid = get_optval_uint(optarg);
+ break;
#endif
}
}
diff --git a/tools/xenstored/core.h b/tools/xenstored/core.h
index 480b0f5f7b..f7a27a4131 100644
--- a/tools/xenstored/core.h
+++ b/tools/xenstored/core.h
@@ -359,6 +359,7 @@ do {\
extern int dom0_domid;
extern int dom0_event;
extern int priv_domid;
+extern int stub_domid;
extern bool keep_orphans;
extern unsigned int timeout_watch_event_msec;
--
2.35.3
[PATCH 20/29] tools: add 9pfs device to xenstore-stubdom
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 = "xenlogd"
- path = "/var/lib/xen/xenstore"
For now don't limit allowed file space or number of files.
Add a new libxl function for adding it similar to the function for
adding the console device.
Signed-off-by: Juergen Gross
---
tools/helpers/init-xenstore-domain.c | 2 ++
tools/include/libxl.h| 17
tools/libs/light/libxl_9pfs.c| 29
3 files changed, 48 insertions(+)
diff --git a/tools/helpers/init-xenstore-domain.c
b/tools/helpers/init-xenstore-domain.c
index 140ed610ae..a65abae2ac 100644
--- a/tools/helpers/init-xenstore-domain.c
+++ b/tools/helpers/init-xenstore-domain.c
@@ -543,6 +543,8 @@ int main(int argc, char** argv)
}
libxl_console_add_xenstore(ctx, domid, 0, console_evtchn, console_gfn,
NULL);
+libxl_p9_add_xenstore(ctx, domid, 0, LIBXL_P9_TYPE_XENLOGD, "xen",
+ XEN_LIB_DIR"/xenstore", 0, 0, 0, 0, NULL);
libxl_ctx_free(ctx);
fd = creat(XEN_RUN_DIR "/xenstored.pid", 0666);
diff --git a/tools/include/libxl.h b/tools/include/libxl.h
index 907aa0a330..ab8a67f50a 100644
--- a/tools/include/libxl.h
+++ b/tools/include/libxl.h
@@ -583,6 +583,13 @@
* libxl_console_add_xenstore() in libxl.
*/
#define LIBXL_HAVE_CONSOLE_ADD_XENSTORE 1
+
+/*
+ * LIBXL_HAVE_P9_ADD_XENSTORE indicates presence of the function
+ * libxl_p9_add_xenstore() in libxl.
+ */
+#define LIBXL_HAVE_P9_ADD_XENSTORE 1
+
/*
* libxl ABI compatibility
*
@@ -2060,6 +2067,16 @@ int libxl_console_add_xenstore(libxl_ctx *ctx, uint32_t
domid, uint32_t backend,
const libxl_asyncop_how *ao_how)
LIBXL_EXTERNAL_CALLERS_ONLY;
+/* libxl_p9_add_xenstore writes the Xenstore entries for a domain's
+ * primary 9pfs device based on domid, backend type and device parameters.
+ */
+int libxl_p9_add_xenstore(libxl_ctx *ctx, uint32_t domid, uint32_t backend,
+ libxl_p9_type type, char *tag, char *path,
+ unsigned int max_space, unsigned int max_files,
+ unsigned int max_open_files, bool auto_delete,
+ const libxl_asyncop_how *ao_how)
+ LIBXL_EXTERNAL_CALLERS_ONLY;
+
/* May be called with info_r == NULL to check for domain's existence.
* Returns ERROR_DOMAIN_NOTFOUND if domain does not exist (used to return
* ERROR_INVAL for this scenario). */
diff --git a/tools/libs/light/libxl_9pfs.c b/tools/libs/light/libxl_9pfs.c
index 0b9d84dce9..3297389493 100644
--- a/tools/libs/light/libxl_9pfs.c
+++ b/tools/libs/light/libxl_9pfs.c
@@ -174,6 +174,35 @@ static void libxl__device_p9_add(libxl__egc *egc, uint32_t
domid,
aodev->callback(egc, aodev);
}
+int libxl_p9_add_xenstore(libxl_ctx *ctx, uint32_t domid, uint32_t backend,
+ libxl_p9_type type, char *tag, char *path,
+ unsigned int max_space, unsigned int max_files,
+ unsigned int max_open_files, bool auto_delete,
+ const libxl_asyncop_how *ao_how)
+{
+AO_CREATE(ctx, domid, ao_how);
+libxl__ao_device *aodev;
+libxl_device_p9 p9 = { .backend_domid = backend,
+ .tag = tag,
+ .path = path,
+ .security_model = "none",
+ .type = type,
+ .max_space = max_space,
+ .max_files = max_files,
+ .max_open_files = max_open_files,
+ .auto_delete = auto_delete,
+ };
+
+GCNEW(aodev);
+libxl__prepare_ao_device(ao, aodev);
+aodev->action = LIBXL__DEVICE_ACTION_ADD;
+aodev->callback = device_addrm_aocomplete;
+
+libxl__device_p9_add(egc, domid, &p9, aodev);
+
+return AO_INPROGRESS;
+}
+
#define libxl_device_p9_list NULL
#define libxl_device_p9_compare NULL
--
2.35.3
[PATCH 28/29] tools/xenstored: support complete log capabilities in stubdom
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
---
tools/hotplug/Linux/launch-xenstore.in | 1 +
tools/xenstored/control.c | 30 +-
tools/xenstored/minios.c | 3 +++
3 files changed, 19 insertions(+), 15 deletions(-)
diff --git a/tools/hotplug/Linux/launch-xenstore.in
b/tools/hotplug/Linux/launch-xenstore.in
index e854ca1eb8..da4eeca7c5 100644
--- a/tools/hotplug/Linux/launch-xenstore.in
+++ b/tools/hotplug/Linux/launch-xenstore.in
@@ -98,6 +98,7 @@ test -f @CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons && .
@CONFIG_DIR@/@CONFIG_LEAF
[ -z "$XENSTORE_DOMAIN_SIZE" ] && XENSTORE_DOMAIN_SIZE=8
XENSTORE_DOMAIN_ARGS="$XENSTORE_DOMAIN_ARGS --memory
$XENSTORE_DOMAIN_SIZE"
[ -z "$XENSTORE_MAX_DOMAIN_SIZE" ] ||
XENSTORE_DOMAIN_ARGS="$XENSTORE_DOMAIN_ARGS --maxmem $XENSTORE_MAX_DOMAIN_SIZE"
+ [ -z "$XENSTORED_TRACE" ] ||
XENSTORE_DOMAIN_ARGS="$XENSTORE_DOMAIN_ARGS -T xenstored-trace.log"
echo -n Starting $XENSTORE_DOMAIN_KERNEL...
${LIBEXEC_BIN}/init-xenstore-domain $XENSTORE_DOMAIN_ARGS || exit 1
diff --git a/tools/xenstored/control.c b/tools/xenstored/control.c
index b2f64d674f..dae23a5ac0 100644
--- a/tools/xenstored/control.c
+++ b/tools/xenstored/control.c
@@ -201,19 +201,6 @@ static int do_control_quota_s(const void *ctx, struct
connection *conn,
return EINVAL;
}
-#ifdef __MINIOS__
-static int do_control_memreport(const void *ctx, struct connection *conn,
- const char **vec, int num)
-{
- if (num)
- return EINVAL;
-
- talloc_report_full(NULL, stdout);
-
- send_ack(conn, XS_CONTROL);
- return 0;
-}
-#else
static int do_control_logfile(const void *ctx, struct connection *conn,
const char **vec, int num)
{
@@ -222,13 +209,26 @@ static int do_control_logfile(const void *ctx, struct
connection *conn,
close_log();
talloc_free(tracefile);
- tracefile = talloc_strdup(NULL, vec[0]);
+ tracefile = absolute_filename(NULL, vec[0]);
reopen_log();
send_ack(conn, XS_CONTROL);
return 0;
}
+#ifdef __MINIOS__
+static int do_control_memreport(const void *ctx, struct connection *conn,
+ const char **vec, int num)
+{
+ if (num)
+ return EINVAL;
+
+ talloc_report_full(NULL, stdout);
+
+ send_ack(conn, XS_CONTROL);
+ return 0;
+}
+#else
static int do_control_memreport(const void *ctx, struct connection *conn,
const char **vec, int num)
{
@@ -309,10 +309,10 @@ static struct cmd_s cmds[] = {
"[-c ] [-F] [-t ] \n"
"Default timeout is 60 seconds.", 5 },
#endif
+ { "logfile", do_control_logfile, "" },
#ifdef __MINIOS__
{ "memreport", do_control_memreport, "" },
#else
- { "logfile", do_control_logfile, "" },
{ "memreport", do_control_memreport, "[]" },
#endif
{ "print", do_control_print, "" },
diff --git a/tools/xenstored/minios.c b/tools/xenstored/minios.c
index cd6e288f2a..c02a263d9d 100644
--- a/tools/xenstored/minios.c
+++ b/tools/xenstored/minios.c
@@ -87,6 +87,9 @@ static void mount_thread(void *p)
free(xenbus_unwatch_path_token(XBT_NIL, P9_STATE_PATH, "9pfs"));
p9_device = init_9pfront(0, XENSTORE_LIB_DIR);
+
+ /* Start logging if selected. */
+ reopen_log();
}
void mount_9pfs(void)
--
2.35.3
[PATCH 19/29] stubdom: extend xenstore stubdom configs
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 --- stubdom/xenstore-minios.cfg| 2 +- stubdom/xenstorepvh-minios.cfg | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/stubdom/xenstore-minios.cfg b/stubdom/xenstore-minios.cfg index a41704bb6b..239da519b9 100644 --- a/stubdom/xenstore-minios.cfg +++ b/stubdom/xenstore-minios.cfg @@ -3,7 +3,7 @@ CONFIG_NETFRONT=n CONFIG_FBFRONT=n CONFIG_KBDFRONT=n CONFIG_CONSFRONT=n -CONFIG_XENBUS=n CONFIG_LWIP=n +CONFIG_9PFRONT=y CONFIG_BALLOON=y XEN_INTERFACE_VERSION=__XEN_LATEST_INTERFACE_VERSION__ diff --git a/stubdom/xenstorepvh-minios.cfg b/stubdom/xenstorepvh-minios.cfg index 6af51f5753..752b90d7d3 100644 --- a/stubdom/xenstorepvh-minios.cfg +++ b/stubdom/xenstorepvh-minios.cfg @@ -4,7 +4,7 @@ CONFIG_NETFRONT=n CONFIG_FBFRONT=n CONFIG_KBDFRONT=n CONFIG_CONSFRONT=n -CONFIG_XENBUS=n CONFIG_LWIP=n +CONFIG_9PFRONT=y CONFIG_BALLOON=y XEN_INTERFACE_VERSION=__XEN_LATEST_INTERFACE_VERSION__ -- 2.35.3
[PATCH 18/29] tools/xenstored: rename xenbus_evtchn()
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
---
tools/xenstored/core.h | 2 +-
tools/xenstored/domain.c | 2 +-
tools/xenstored/minios.c | 2 +-
tools/xenstored/posix.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/xenstored/core.h b/tools/xenstored/core.h
index ad87199042..480b0f5f7b 100644
--- a/tools/xenstored/core.h
+++ b/tools/xenstored/core.h
@@ -383,7 +383,7 @@ static inline bool domain_is_unprivileged(const struct
connection *conn)
}
/* Return the event channel used by xenbus. */
-evtchn_port_t xenbus_evtchn(void);
+evtchn_port_t get_xenbus_evtchn(void);
/* Write out the pidfile */
void write_pidfile(const char *pidfile);
diff --git a/tools/xenstored/domain.c b/tools/xenstored/domain.c
index 409b53acf9..6ef136e01f 100644
--- a/tools/xenstored/domain.c
+++ b/tools/xenstored/domain.c
@@ -1208,7 +1208,7 @@ void dom0_init(void)
evtchn_port_t port;
struct domain *dom0;
- port = xenbus_evtchn();
+ port = get_xenbus_evtchn();
if (port == -1)
barf_perror("Failed to initialize dom0 port");
diff --git a/tools/xenstored/minios.c b/tools/xenstored/minios.c
index b5c3a205e6..0779efbf91 100644
--- a/tools/xenstored/minios.c
+++ b/tools/xenstored/minios.c
@@ -38,7 +38,7 @@ void init_pipe(int reopen_log_pipe[2])
reopen_log_pipe[1] = -1;
}
-evtchn_port_t xenbus_evtchn(void)
+evtchn_port_t get_xenbus_evtchn(void)
{
return dom0_event;
}
diff --git a/tools/xenstored/posix.c b/tools/xenstored/posix.c
index 6ac45fdb45..7e03dd982d 100644
--- a/tools/xenstored/posix.c
+++ b/tools/xenstored/posix.c
@@ -111,7 +111,7 @@ void unmap_xenbus(void *interface)
munmap(interface, getpagesize());
}
-evtchn_port_t xenbus_evtchn(void)
+evtchn_port_t get_xenbus_evtchn(void)
{
int fd;
int rc;
--
2.35.3
[PATCH 27/29] tools/xenstored: add daemon_init() function
Some xenstored initialization needs to be done in the daemon case only,
so split it out into a new daemon_init() function being a stub in the
stubdom case.
Signed-off-by: Juergen Gross
---
tools/xenstored/core.c | 6 +-
tools/xenstored/core.h | 1 +
tools/xenstored/minios.c | 4
tools/xenstored/posix.c | 10 ++
4 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/tools/xenstored/core.c b/tools/xenstored/core.c
index 9f48d91027..204b932ca9 100644
--- a/tools/xenstored/core.c
+++ b/tools/xenstored/core.c
@@ -2949,11 +2949,7 @@ int main(int argc, char *argv[])
if (optind != argc)
barf("%s: No arguments desired", argv[0]);
- reopen_log();
-
- /* Make sure xenstored directory exists. */
- /* Errors ignored here, will be reported when we open files */
- mkdir(xenstore_daemon_rundir(), 0755);
+ daemon_init();
if (dofork) {
openlog("xenstored", 0, LOG_DAEMON);
diff --git a/tools/xenstored/core.h b/tools/xenstored/core.h
index d3cd4a4c8a..a15d5b0d67 100644
--- a/tools/xenstored/core.h
+++ b/tools/xenstored/core.h
@@ -391,6 +391,7 @@ evtchn_port_t get_xenbus_evtchn(void);
void mount_9pfs(void);
#endif
+void daemon_init(void);
const char *xenstore_rundir(void);
char *absolute_filename(const void *ctx, const char *filename);
diff --git a/tools/xenstored/minios.c b/tools/xenstored/minios.c
index 104f37587b..cd6e288f2a 100644
--- a/tools/xenstored/minios.c
+++ b/tools/xenstored/minios.c
@@ -62,6 +62,10 @@ void unmap_xenbus(void *interface)
xengnttab_unmap(*xgt_handle, interface, 1);
}
+void daemon_init(void)
+{
+}
+
static void mount_thread(void *p)
{
xenbus_event_queue events = NULL;
diff --git a/tools/xenstored/posix.c b/tools/xenstored/posix.c
index d02d0e446f..c84e7ef3a8 100644
--- a/tools/xenstored/posix.c
+++ b/tools/xenstored/posix.c
@@ -163,3 +163,13 @@ const char *xenstore_rundir(void)
{
return xenstore_daemon_rundir();
}
+
+void daemon_init(void)
+{
+ reopen_log();
+
+ /* Make sure xenstored directories exist. */
+ /* Errors ignored here, will be reported when we open files */
+ mkdir(xenstore_daemon_rundir(), 0755);
+ mkdir(XENSTORE_LIB_DIR, 0755);
+}
--
2.35.3
[PATCH 26/29] tools/xenstored: add helpers for filename handling
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() (used e.g. for saving the state
file in case of live update - needs to be unchanged in the daemon
case, but should result in /var/lib/xen/xenstore for stubdom)
Signed-off-by: Juergen Gross
---
tools/xenstored/core.c | 9 -
tools/xenstored/core.h | 3 +++
tools/xenstored/lu_daemon.c | 4 ++--
tools/xenstored/minios.c| 5 +
tools/xenstored/posix.c | 6 ++
5 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/tools/xenstored/core.c b/tools/xenstored/core.c
index 1764b1af4e..9f48d91027 100644
--- a/tools/xenstored/core.c
+++ b/tools/xenstored/core.c
@@ -158,6 +158,13 @@ void trace_destroy(const void *data, const char *type)
trace("obj: DESTROY %s %p\n", type, data);
}
+char *absolute_filename(const void *ctx, const char *filename)
+{
+ if (filename[0] != '/')
+ return talloc_asprintf(ctx, XENSTORE_LIB_DIR "/%s", filename);
+ return talloc_strdup(ctx, filename);
+}
+
/**
* Signal handler for SIGHUP, which requests that the trace log is reopened
* (in the main loop). A single byte is written to reopen_log_pipe, to awaken
@@ -2995,7 +3002,7 @@ int main(int argc, char *argv[])
signal(SIGHUP, trigger_reopen_log);
if (tracefile)
- tracefile = talloc_strdup(NULL, tracefile);
+ tracefile = absolute_filename(NULL, tracefile);
#ifndef NO_LIVE_UPDATE
/* Read state in case of live update. */
diff --git a/tools/xenstored/core.h b/tools/xenstored/core.h
index 48ff659ec5..d3cd4a4c8a 100644
--- a/tools/xenstored/core.h
+++ b/tools/xenstored/core.h
@@ -391,6 +391,9 @@ evtchn_port_t get_xenbus_evtchn(void);
void mount_9pfs(void);
#endif
+const char *xenstore_rundir(void);
+char *absolute_filename(const void *ctx, const char *filename);
+
/* Write out the pidfile */
void write_pidfile(const char *pidfile);
diff --git a/tools/xenstored/lu_daemon.c b/tools/xenstored/lu_daemon.c
index 71bcabadd3..635ab0 100644
--- a/tools/xenstored/lu_daemon.c
+++ b/tools/xenstored/lu_daemon.c
@@ -24,7 +24,7 @@ void lu_get_dump_state(struct lu_dump_state *state)
state->size = 0;
state->filename = talloc_asprintf(NULL, "%s/state_dump",
- xenstore_daemon_rundir());
+ xenstore_rundir());
if (!state->filename)
barf("Allocation failure");
@@ -65,7 +65,7 @@ FILE *lu_dump_open(const void *ctx)
int fd;
filename = talloc_asprintf(ctx, "%s/state_dump",
- xenstore_daemon_rundir());
+ xenstore_rundir());
if (!filename)
return NULL;
diff --git a/tools/xenstored/minios.c b/tools/xenstored/minios.c
index e5a3684df6..104f37587b 100644
--- a/tools/xenstored/minios.c
+++ b/tools/xenstored/minios.c
@@ -89,3 +89,8 @@ void mount_9pfs(void)
{
create_thread("mount-9pfs", mount_thread, NULL);
}
+
+const char *xenstore_rundir(void)
+{
+ return XENSTORE_LIB_DIR;
+}
diff --git a/tools/xenstored/posix.c b/tools/xenstored/posix.c
index 7e03dd982d..d02d0e446f 100644
--- a/tools/xenstored/posix.c
+++ b/tools/xenstored/posix.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include "utils.h"
#include "core.h"
@@ -157,3 +158,8 @@ void *xenbus_map(void)
return addr;
}
+
+const char *xenstore_rundir(void)
+{
+ return xenstore_daemon_rundir();
+}
--
2.35.3
[PATCH 15/29] tools/libs/light: add backend type for 9pfs PV devices
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 "xenlogd" with the related Xenstore backend-side
directory "xen_9pfs".
As additional security features it is possible to specify:
- "max-space" for limiting the maximum space consumed on the filesystem
in MBs
- "max-files" for limiting the maximum number of files in the
filesystem
- "max-open-files" for limiting the maximum number of concurrent open
files
For convenience "auto-delete" is available to let the backend delete the
oldest file of the guest in case otherwise "max-space" or "max-files"
would be violated.
The xenlogd daemon will be started by libxenlight automatically when
the first "xen_9pfs" device is being created.
Signed-off-by: Juergen Gross
---
tools/libs/light/libxl_9pfs.c | 143 +-
tools/libs/light/libxl_create.c | 4 +-
tools/libs/light/libxl_dm.c | 2 +-
tools/libs/light/libxl_types.idl | 11 ++
tools/libs/light/libxl_types_internal.idl | 1 +
5 files changed, 154 insertions(+), 7 deletions(-)
diff --git a/tools/libs/light/libxl_9pfs.c b/tools/libs/light/libxl_9pfs.c
index 5ab0d3aa21..0b9d84dce9 100644
--- a/tools/libs/light/libxl_9pfs.c
+++ b/tools/libs/light/libxl_9pfs.c
@@ -33,20 +33,157 @@ static int libxl__set_xenstore_p9(libxl__gc *gc, uint32_t
domid,
flexarray_append_pair(front, "tag", p9->tag);
+if (p9->type == LIBXL_P9_TYPE_XENLOGD) {
+flexarray_append_pair(back, "max-space",
+ GCSPRINTF("%u", p9->max_space));
+flexarray_append_pair(back, "max-files",
+ GCSPRINTF("%u", p9->max_files));
+flexarray_append_pair(back, "max-open-files",
+ GCSPRINTF("%u", p9->max_open_files));
+flexarray_append_pair(back, "auto-delete",
+ p9->auto_delete ? "1" : "0");
+}
+
+return 0;
+}
+
+static int libxl__device_from_p9(libxl__gc *gc, uint32_t domid,
+ libxl_device_p9 *type, libxl__device *device)
+{
+device->backend_devid = type->devid;
+device->backend_domid = type->backend_domid;
+device->backend_kind= type->type == LIBXL_P9_TYPE_QEMU
+ ? LIBXL__DEVICE_KIND_9PFS
+ : LIBXL__DEVICE_KIND_XEN_9PFS;
+device->devid = type->devid;
+device->domid = domid;
+device->kind= LIBXL__DEVICE_KIND_9PFS;
+
return 0;
}
-#define libxl__add_p9s NULL
+static int libxl_device_p9_dm_needed(void *e, unsigned domid)
+{
+libxl_device_p9 *elem = e;
+
+return elem->type == LIBXL_P9_TYPE_QEMU && elem->backend_domid == domid;
+}
+
+typedef struct libxl__aop9_state libxl__aop9_state;
+
+struct libxl__aop9_state {
+libxl__spawn_state spawn;
+libxl__ao_device *aodev;
+libxl_device_p9 *p9;
+uint32_t domid;
+void (*callback)(libxl__egc *, libxl__aop9_state *, int);
+};
+
+static void xenlogd_spawn_outcome(libxl__egc *egc, libxl__aop9_state *aop9,
+ int rc)
+{
+aop9->aodev->rc = rc;
+if (rc)
+aop9->aodev->callback(egc, aop9->aodev);
+else
+libxl__device_add_async(egc, aop9->domid, &libxl__p9_devtype,
+aop9->p9, aop9->aodev);
+}
+
+static void xenlogd_confirm(libxl__egc *egc, libxl__spawn_state *spawn,
+const char *xsdata)
+{
+STATE_AO_GC(spawn->ao);
+
+if (!xsdata)
+return;
+
+if (strcmp(xsdata, "running"))
+return;
+
+libxl__spawn_initiate_detach(gc, spawn);
+}
+
+static void xenlogd_failed(libxl__egc *egc, libxl__spawn_state *spawn, int rc)
+{
+libxl__aop9_state *aop9 = CONTAINER_OF(spawn, *aop9, spawn);
+
+xenlogd_spawn_outcome(egc, aop9, rc);
+}
+
+static void xenlogd_detached(libxl__egc *egc, libxl__spawn_state *spawn)
+{
+libxl__aop9_state *aop9 = CONTAINER_OF(spawn, *aop9, spawn);
+
+xenlogd_spawn_outcome(egc, aop9, 0);
+}
+
+static int xenlogd_spawn(libxl__egc *egc, uint32_t domid, libxl_device_p9 *p9,
+ libxl__ao_device *aodev)
+{
+STATE_AO_GC(aodev->ao);
+struct libxl__aop9_state *aop9;
+int rc;
+char *args[] = { "xenlogd", NULL };
+
+if (p9->type != LIBXL_P9_TYPE_XENLOGD ||
+libxl__xs_read(gc, XBT_NULL, "/tool/xenlog/state"))
+return 0;
+
+GCNEW(aop9);
+aop9->aodev = aodev;
+aop9->p9 = p9;
+aop9->domid = domid;
+aop9->callback = xenlogd_spawn_outcome;
+
+aop9->spawn.ao = aodev->ao;
+aop9->spawn.what = "xenlog daemon";
+aop9->spawn.xspath = "/tool/xenlog/state";
+aop9->spawn.timeout_ms = LIBXL_DEVICE_MODEL_START_TIMEOUT * 1000;
+aop9->spawn.pidpath = "/tool/xenlog/pid";
+aop9->spawn.midproc_cb = libxl__spawn_record_pid;
+aop9->spawn.confirm_cb = xenlogd_confir
[PATCH 09/29] tools/xenlogd: add 9pfs open request support
Add the open request of the 9pfs protocol.
Signed-off-by: Juergen Gross
---
tools/xenlogd/io.c | 130
tools/xenlogd/xenlogd.h | 4 ++
2 files changed, 134 insertions(+)
diff --git a/tools/xenlogd/io.c b/tools/xenlogd/io.c
index 778e1dc2c9..c2b259f42e 100644
--- a/tools/xenlogd/io.c
+++ b/tools/xenlogd/io.c
@@ -18,6 +18,8 @@
#include
#include
#include
+#include
+#include
#include/* For cpu barriers. */
#include
@@ -28,6 +30,15 @@
#define P9_CMD_ATTACH 104
#define P9_CMD_ERROR 107
#define P9_CMD_WALK 110
+#define P9_CMD_OPEN 112
+
+/* P9 protocol open flags. */
+#define P9_OREAD0 /* read */
+#define P9_OWRITE 1 /* write */
+#define P9_ORDWR2 /* read and write */
+#define P9_OMODEMASK 0x03
+#define P9_OTRUNC0x10 /* or'ed in, truncate file first */
+#define P9_OREMOVE 0x40 /* or'ed in, remove file after clunk */
#define P9_MIN_MSIZE 2048
#define P9_VERSION"9P2000.u"
@@ -734,6 +745,121 @@ static void p9_walk(device *device, struct p9_header *hdr)
free(names);
}
+static int open_flags_from_mode(uint8_t mode)
+{
+int flags;
+
+switch ( mode & P9_OMODEMASK )
+{
+case P9_OREAD:
+flags = O_RDONLY;
+break;
+
+case P9_OWRITE:
+flags = O_WRONLY;
+break;
+
+case P9_ORDWR:
+flags = O_RDWR;
+break;
+
+default:
+return -1;
+}
+
+if ( mode & P9_OTRUNC )
+flags |= O_TRUNC;
+
+return flags;
+}
+
+static unsigned int get_iounit(device *device, struct stat *st)
+{
+return (device->max_size - st->st_blksize) & ~(st->st_blksize - 1);
+}
+
+static void p9_open(device *device, struct p9_header *hdr)
+{
+uint32_t fid;
+uint8_t mode;
+struct p9_fid *fidp;
+struct stat st;
+struct p9_qid qid;
+uint32_t iounit;
+int flags;
+int ret;
+
+ret = fill_data(device, "Ub", &fid, &mode);
+if ( ret != 2 )
+{
+p9_error(device, hdr->tag, EINVAL);
+return;
+}
+if ( mode & ~(P9_OMODEMASK | P9_OTRUNC | P9_OREMOVE) )
+{
+p9_error(device, hdr->tag, EINVAL);
+return;
+}
+
+fidp = find_fid(device, fid);
+if ( !fidp )
+{
+p9_error(device, hdr->tag, ENOENT);
+return;
+}
+if ( fidp->opened )
+{
+p9_error(device, hdr->tag, EINVAL);
+return;
+}
+
+if ( stat(fidp->path, &st) < 0 )
+{
+p9_error(device, hdr->tag, ENOENT);
+return;
+}
+
+fidp->isdir = S_ISDIR(st.st_mode);
+fidp->mode = mode;
+if ( fidp->isdir )
+{
+if ( mode != P9_OREAD )
+{
+p9_error(device, hdr->tag, EINVAL);
+return;
+}
+fidp->data = opendir(fidp->path);
+if ( !fidp->data )
+{
+p9_error(device, hdr->tag, errno);
+return;
+}
+fidp->fd = dirfd(fidp->data);
+}
+else
+{
+flags = open_flags_from_mode(mode);
+if ( flags < 0 )
+{
+p9_error(device, hdr->tag, EINVAL);
+return;
+}
+
+fidp->fd = open(fidp->path, flags);
+if ( fidp->fd < 0 )
+{
+p9_error(device, hdr->tag, errno);
+return;
+}
+}
+
+fill_qid(fidp->path, &qid, &st);
+iounit = get_iounit(device, &st);
+fidp->opened = true;
+
+fill_buffer(device, hdr->cmd + 1, hdr->tag, "QU", &qid, &iounit);
+}
+
void *io_thread(void *arg)
{
device *device = arg;
@@ -801,6 +927,10 @@ void *io_thread(void *arg)
p9_walk(device, &hdr);
break;
+case P9_CMD_OPEN:
+p9_open(device, &hdr);
+break;
+
default:
syslog(LOG_DEBUG, "%u.%u sent unhandled command %u\n",
device->domid, device->devid, hdr.cmd);
diff --git a/tools/xenlogd/xenlogd.h b/tools/xenlogd/xenlogd.h
index 23f013af9e..6b7b5e2b91 100644
--- a/tools/xenlogd/xenlogd.h
+++ b/tools/xenlogd/xenlogd.h
@@ -22,7 +22,11 @@ struct p9_header {
struct p9_fid {
XEN_TAILQ_ENTRY(struct p9_fid) list;
unsigned int fid;
+int fd;
+uint8_t mode;
bool opened;
+bool isdir;
+void *data;/* File type specific. */
char path[];
};
--
2.35.3
[PATCH 22/29] tools/xenstored:
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
domain's ring page.
Signed-off-by: Juergen Gross
---
tools/xenstored/domain.c | 31 +--
1 file changed, 13 insertions(+), 18 deletions(-)
diff --git a/tools/xenstored/domain.c b/tools/xenstored/domain.c
index 6ef136e01f..58b0942043 100644
--- a/tools/xenstored/domain.c
+++ b/tools/xenstored/domain.c
@@ -497,14 +497,20 @@ static const struct interface_funcs domain_funcs = {
static void *map_interface(domid_t domid)
{
+ if (domid == xenbus_master_domid())
+ return xenbus_map();
+
return xengnttab_map_grant_ref(*xgt_handle, domid,
GNTTAB_RESERVED_XENSTORE,
PROT_READ|PROT_WRITE);
}
-static void unmap_interface(void *interface)
+static void unmap_interface(domid_t domid, void *interface)
{
- xengnttab_unmap(*xgt_handle, interface, 1);
+ if (domid == xenbus_master_domid())
+ unmap_xenbus(interface);
+ else
+ xengnttab_unmap(*xgt_handle, interface, 1);
}
static int domain_tree_remove_sub(const void *ctx, struct connection *conn,
@@ -594,14 +600,8 @@ static int destroy_domain(void *_domain)
eprintf("> Unbinding port %i failed!\n", domain->port);
}
- if (domain->interface) {
- /* Domain 0 was mapped by dom0_init, so it must be unmapped
- using munmap() and not the grant unmap call. */
- if (domain->domid == dom0_domid)
- unmap_xenbus(domain->interface);
- else
- unmap_interface(domain->interface);
- }
+ if (domain->interface)
+ unmap_interface(domain->domid, domain->interface);
fire_special_watches("@releaseDomain");
@@ -966,18 +966,13 @@ static struct domain *introduce_domain(const void *ctx,
return NULL;
if (!domain->introduced) {
- interface = is_master_domain ? xenbus_map()
-: map_interface(domid);
+ interface = map_interface(domid);
if (!interface && !restore)
return NULL;
if (new_domain(domain, port, restore)) {
rc = errno;
- if (interface) {
- if (is_master_domain)
- unmap_xenbus(interface);
- else
- unmap_interface(interface);
- }
+ if (interface)
+ unmap_interface(domid, interface);
errno = rc;
return NULL;
}
--
2.35.3
[PATCH 10/29] tools/xenlogd: add 9pfs clunk request support
Add the clunk request of the 9pfs protocol.
Signed-off-by: Juergen Gross
---
tools/xenlogd/io.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/tools/xenlogd/io.c b/tools/xenlogd/io.c
index c2b259f42e..2607095e51 100644
--- a/tools/xenlogd/io.c
+++ b/tools/xenlogd/io.c
@@ -31,6 +31,7 @@
#define P9_CMD_ERROR 107
#define P9_CMD_WALK 110
#define P9_CMD_OPEN 112
+#define P9_CMD_CLUNK 120
/* P9 protocol open flags. */
#define P9_OREAD0 /* read */
@@ -860,6 +861,38 @@ static void p9_open(device *device, struct p9_header *hdr)
fill_buffer(device, hdr->cmd + 1, hdr->tag, "QU", &qid, &iounit);
}
+static void p9_clunk(device *device, struct p9_header *hdr)
+{
+uint32_t fid;
+struct p9_fid *fidp;
+int ret;
+
+ret = fill_data(device, "U", &fid);
+if ( ret != 1 )
+{
+p9_error(device, hdr->tag, EINVAL);
+return;
+}
+
+fidp = find_fid(device, fid);
+if ( !fidp )
+{
+p9_error(device, hdr->tag, ENOENT);
+return;
+}
+
+if ( fidp->opened )
+{
+close(fidp->fd);
+if ( fidp->mode & P9_OREMOVE )
+unlink(fidp->path);
+}
+
+free_fid(device, fidp);
+
+fill_buffer(device, hdr->cmd + 1, hdr->tag, "");
+}
+
void *io_thread(void *arg)
{
device *device = arg;
@@ -931,6 +964,10 @@ void *io_thread(void *arg)
p9_open(device, &hdr);
break;
+case P9_CMD_CLUNK:
+p9_clunk(device, &hdr);
+break;
+
default:
syslog(LOG_DEBUG, "%u.%u sent unhandled command %u\n",
device->domid, device->devid, hdr.cmd);
--
2.35.3
[PATCH 16/29] tools/xl: support new 9pfs backend xenlogd
Add support for the new 9pfs backend "xenlogd". For this backend type
the tag defaults to "Xen" and the host side path to
"/var/log/xen/guests/".
Signed-off-by: Juergen Gross
---
docs/man/xl.cfg.5.pod.in | 36 ++--
tools/xl/xl_parse.c | 35 +++
2 files changed, 69 insertions(+), 2 deletions(-)
diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
index 2e234b450e..be82d35eed 100644
--- a/docs/man/xl.cfg.5.pod.in
+++ b/docs/man/xl.cfg.5.pod.in
@@ -772,10 +772,16 @@ settings, from the following list:
=over 4
+=item B
+
+The backendtype for the PV device. Supported values are B and B.
+The default is B.
+
=item B
9pfs tag to identify the filesystem share. The tag is needed on the
-guest side to mount it.
+guest side to mount it. For the backendtype of B the tag defaults to
+"Xen".
=item B
@@ -785,12 +791,38 @@ squash or remap).
=item B
-Filesystem path on the backend to export.
+Filesystem path on the backend to export. For the backendtype of B
+the path defaults to "@XEN_LOG_DIR@/guests/".
=item B
Specify the backend domain name or id, defaults to dom0.
+=item B
+
+Specify the maximum number of files below B. A value of 0 (which
+is the default) doesn't limit the number of files. Only valid for
+B.
+
+=item B
+
+Specify the maximum number of concurrently opened files below B.
+Multiple opens of the same file are counted individually. Only valid for
+B, which has a default of B.
+
+=item B
+
+Specify the maximum used disk space in MiB below B. A value of 0 (which
+is the default) doesn't limit the usable disk space. Only valid for
+B.
+
+=item B
+
+When set the backend will delete the oldest file which is currently not
+opened by the guest in case the disk space limit set via B or the
+file limit set via B is being reached. Only valid for
+B.
+
=back
=item B
diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
index ed983200c3..346532e117 100644
--- a/tools/xl/xl_parse.c
+++ b/tools/xl/xl_parse.c
@@ -2232,6 +2232,20 @@ void parse_config_data(const char *config_source,
replace_string(&p9->tag, value);
} else if (!strcmp(key, "backend")) {
replace_string(&p9->backend_domname, value);
+} else if (!strcmp(key, "type")) {
+if (libxl_p9_type_from_string(value, &p9->type)) {
+fprintf(stderr, "failed to parse 9pfs type: %s\n",
+value);
+exit(1);
+}
+} else if (!strcmp(key, "max-files")) {
+p9->max_files = parse_ulong(value);
+} else if (!strcmp(key, "max-open-files")) {
+p9->max_open_files = parse_ulong(value);
+} else if (!strcmp(key, "max-space")) {
+p9->max_space = parse_ulong(value);
+} else if (!strcmp(key, "auto-delete")) {
+p9->auto_delete = strtoul(value, NULL, 0);
} else {
fprintf(stderr, "Unknown 9pfs parameter '%s'\n", key);
exit(1);
@@ -2242,6 +2256,27 @@ void parse_config_data(const char *config_source,
libxl_string_list_dispose(&pairs);
+if (p9->type == LIBXL_P9_TYPE_UNKNOWN) {
+p9->type = LIBXL_P9_TYPE_QEMU;
+}
+if (p9->type == LIBXL_P9_TYPE_QEMU &&
+(p9->max_space || p9->auto_delete)) {
+fprintf(stderr, "Illegal 9pfs parameter combination\n");
+exit(1);
+}
+if (p9->type == LIBXL_P9_TYPE_XENLOGD) {
+if (!p9->tag) {
+replace_string(&p9->tag, "Xen");
+}
+if (!p9->path) {
+char *path;
+
+xasprintf(&path, XEN_LOG_DIR "/guests/%s", c_info->name);
+replace_string(&p9->path, path);
+free(path);
+}
+}
+
if (!p9->path || !p9->security_model || !p9->tag) {
fprintf(stderr, "9pfs spec missing required field!\n");
exit(1);
--
2.35.3
[PATCH 17/29] tools/helpers: allocate xenstore event channel for xenstore stubdom
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
---
tools/helpers/init-xenstore-domain.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/tools/helpers/init-xenstore-domain.c
b/tools/helpers/init-xenstore-domain.c
index b2d5df8ba5..140ed610ae 100644
--- a/tools/helpers/init-xenstore-domain.c
+++ b/tools/helpers/init-xenstore-domain.c
@@ -248,6 +248,13 @@ static int build(xc_interface *xch)
dom->cmdline = xc_dom_strdup(dom, cmdline);
dom->xenstore_domid = domid;
dom->console_evtchn = console_evtchn;
+rv = xc_evtchn_alloc_unbound(xch, domid, domid);
+if ( rv < 0 )
+{
+fprintf(stderr, "xc_evtchn_alloc_unbound failed\n");
+goto err;
+}
+dom->xenstore_evtchn = rv;
rv = xc_dom_mem_init(dom, memory);
if ( rv )
--
2.35.3
[PATCH 08/29] tools/xenlogd: add 9pfs walk request support
Add the walk request of the 9pfs protocol.
Signed-off-by: Juergen Gross
---
tools/xenlogd/io.c | 138
tools/xenlogd/xenlogd.h | 1 +
2 files changed, 139 insertions(+)
diff --git a/tools/xenlogd/io.c b/tools/xenlogd/io.c
index fa825c9f39..778e1dc2c9 100644
--- a/tools/xenlogd/io.c
+++ b/tools/xenlogd/io.c
@@ -27,9 +27,11 @@
#define P9_CMD_VERSION100
#define P9_CMD_ATTACH 104
#define P9_CMD_ERROR 107
+#define P9_CMD_WALK 110
#define P9_MIN_MSIZE 2048
#define P9_VERSION"9P2000.u"
+#define P9_WALK_MAXELEM 16
struct p9_qid {
uint8_t type;
@@ -523,6 +525,20 @@ static int fill_qid(const char *path, struct p9_qid *qid,
struct stat *stbuf)
return 0;
}
+static bool name_ok(const char *str)
+{
+if ( !*str )
+return false;
+
+if ( strchr(str, '/' ) )
+return false;
+
+if ( !strcmp(str, "..") || !strcmp(str, ".") )
+return false;
+
+return true;
+}
+
static void p9_error(device *device, uint16_t tag, uint32_t err)
{
unsigned int erroff;
@@ -600,6 +616,124 @@ static void p9_attach(device *device, struct p9_header
*hdr)
fill_buffer(device, hdr->cmd + 1, hdr->tag, "Q", &qid);
}
+static void p9_walk(device *device, struct p9_header *hdr)
+{
+uint32_t fid;
+uint32_t newfid;
+struct p9_fid *fidp;
+struct p9_qid *qids = NULL;
+unsigned int n_names = 0;
+unsigned int *names = NULL;
+unsigned int walked = 0;
+unsigned int i;
+char *path = NULL;
+unsigned int path_len;
+int ret;
+
+ret = fill_data(device, "UUaS", &fid, &newfid, &n_names, &names);
+if ( n_names > P9_WALK_MAXELEM )
+{
+p9_error(device, hdr->tag, EINVAL);
+goto out;
+}
+if ( ret != 3 + n_names )
+{
+p9_error(device, hdr->tag, errno);
+goto out;
+}
+
+fidp = find_fid(device, fid);
+if ( !fidp )
+{
+p9_error(device, hdr->tag, ENOENT);
+goto out;
+}
+if ( fidp->opened )
+{
+p9_error(device, hdr->tag, EINVAL);
+goto out;
+}
+
+path_len = strlen(fidp->path) + 1;
+for ( i = 0; i < n_names; i++ )
+{
+if ( !name_ok(device->str + names[i]) )
+{
+p9_error(device, hdr->tag, ENOENT);
+goto out;
+}
+path_len += strlen(device->str + names[i]) + 1;
+}
+path = calloc(path_len + 1, 1);
+if ( !path )
+{
+p9_error(device, hdr->tag, ENOMEM);
+goto out;
+}
+strcpy(path, fidp->path);
+
+if ( n_names )
+{
+qids = calloc(n_names, sizeof(*qids));
+if ( !qids )
+{
+p9_error(device, hdr->tag, ENOMEM);
+goto out;
+}
+for ( i = 0; i < n_names; i++ )
+{
+strcat(path, "/");
+strcat(path, device->str + names[i]);
+ret = fill_qid(path, qids + i, NULL);
+if ( ret )
+{
+if ( !walked )
+{
+p9_error(device, hdr->tag, errno);
+goto out;
+}
+break;
+}
+walked++;
+}
+}
+
+if ( walked == n_names )
+{
+const char *rel_path = path + strlen(device->host_path);
+bool ok = false;
+
+if ( fid == newfid )
+{
+struct p9_fid *new_fidp;
+
+new_fidp = alloc_fid_mem(device, fid, rel_path);
+if ( new_fidp )
+{
+XEN_TAILQ_REMOVE(&device->fids, fidp, list);
+XEN_TAILQ_INSERT_HEAD(&device->fids, new_fidp, list);
+free(fidp);
+ok = true;
+}
+}
+else
+ok = alloc_fid(device, newfid, rel_path);
+
+if ( !ok )
+{
+p9_error(device, hdr->tag, errno);
+goto out;
+}
+}
+
+fill_buffer(device, hdr->cmd + 1, hdr->tag, "aQ", &walked, qids);
+
+ out:
+free(qids);
+free(path);
+free(names);
+}
+
void *io_thread(void *arg)
{
device *device = arg;
@@ -663,6 +797,10 @@ void *io_thread(void *arg)
p9_attach(device, &hdr);
break;
+case P9_CMD_WALK:
+p9_walk(device, &hdr);
+break;
+
default:
syslog(LOG_DEBUG, "%u.%u sent unhandled command %u\n",
device->domid, device->devid, hdr.cmd);
diff --git a/tools/xenlogd/xenlogd.h b/tools/xenlogd/xenlogd.h
index bd2a283ccb..23f013af9e 100644
--- a/tools/xenlogd/xenlogd.h
+++ b/tools/xenlogd/xenlogd.h
@@ -22,6 +22,7 @@ struct p9_header {
struct p9_fid {
XEN_TAILQ_ENTRY(struct p9_fid) list;
unsigned int fid;
+bool opened;
char path[];
};
--
2.35.3
[PATCH 23/29] tools/xenstored: split domain_init()
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
unconditionally, and in a part setting up the event channel handle.
Note that there is no chance that chk_domain_generation() can be
called now before xc_handle has been setup, so there is no need for
the related special case anymore.
Signed-off-by: Juergen Gross
---
tools/xenstored/core.c | 2 ++
tools/xenstored/domain.c | 12 ++--
tools/xenstored/domain.h | 1 +
3 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/tools/xenstored/core.c b/tools/xenstored/core.c
index bb4612455d..42a848e098 100644
--- a/tools/xenstored/core.c
+++ b/tools/xenstored/core.c
@@ -2972,6 +2972,8 @@ int main(int argc, char *argv[])
init_pipe(reopen_log_pipe);
+ domain_static_init();
+
/* Listen to hypervisor. */
if (!no_domain_init && !live_update) {
domain_init(-1);
diff --git a/tools/xenstored/domain.c b/tools/xenstored/domain.c
index 58b0942043..fa17f68618 100644
--- a/tools/xenstored/domain.c
+++ b/tools/xenstored/domain.c
@@ -1224,10 +1224,8 @@ static int domeq_fn(const void *key1, const void *key2)
return *(const unsigned int *)key1 == *(const unsigned int *)key2;
}
-void domain_init(int evtfd)
+void domain_static_init(void)
{
- int rc;
-
/* Start with a random rather low domain count for the hashtable. */
domhash = create_hashtable(NULL, "domains", domhash_fn, domeq_fn, 0);
if (!domhash)
@@ -1258,6 +1256,11 @@ void domain_init(int evtfd)
xengnttab_set_max_grants(*xgt_handle, DOMID_FIRST_RESERVED);
talloc_set_destructor(xgt_handle, close_xgt_handle);
+}
+
+void domain_init(int evtfd)
+{
+ int rc;
if (evtfd < 0)
xce_handle = xenevtchn_open(NULL, XENEVTCHN_NO_CLOEXEC);
@@ -1291,9 +1294,6 @@ static bool chk_domain_generation(unsigned int domid,
uint64_t gen)
{
struct domain *d;
- if (!xc_handle && domid == dom0_domid)
- return true;
-
d = find_domain_struct(domid);
return d && d->generation <= gen;
diff --git a/tools/xenstored/domain.h b/tools/xenstored/domain.h
index 7625dca8cd..6c00540311 100644
--- a/tools/xenstored/domain.h
+++ b/tools/xenstored/domain.h
@@ -82,6 +82,7 @@ int do_get_domain_path(const void *ctx, struct connection
*conn,
int do_reset_watches(const void *ctx, struct connection *conn,
struct buffered_data *in);
+void domain_static_init(void);
void domain_init(int evtfd);
void dom0_init(void);
void domain_deinit(void);
--
2.35.3
[PATCH 13/29] tools/xenlogd: add 9pfs write request support
Add the write request of the 9pfs protocol.
Signed-off-by: Juergen Gross
---
tools/xenlogd/io.c | 50 ++
1 file changed, 50 insertions(+)
diff --git a/tools/xenlogd/io.c b/tools/xenlogd/io.c
index 6e92667fab..6b4692ca67 100644
--- a/tools/xenlogd/io.c
+++ b/tools/xenlogd/io.c
@@ -32,6 +32,7 @@
#define P9_CMD_WALK 110
#define P9_CMD_OPEN 112
#define P9_CMD_CREATE 114
+#define P9_CMD_WRITE 118
#define P9_CMD_CLUNK 120
#define P9_CMD_STAT 124
@@ -1010,6 +1011,51 @@ static void p9_create(device *device, struct p9_header
*hdr)
fill_buffer(device, hdr->cmd + 1, hdr->tag, "QU", &qid, &iounit);
}
+static void p9_write(device *device, struct p9_header *hdr)
+{
+uint32_t fid;
+uint64_t off;
+unsigned int len;
+uint32_t written;
+void *buf;
+struct p9_fid *fidp;
+int ret;
+
+ret = fill_data(device, "ULD", &fid, &off, &len, device->buffer);
+if ( ret != 3 )
+{
+p9_error(device, hdr->tag, EINVAL);
+return;
+}
+
+fidp = find_fid(device, fid);
+if ( !fidp || !fidp->opened || fidp->isdir )
+{
+p9_error(device, hdr->tag, EBADF);
+return;
+}
+
+buf = device->buffer;
+
+while ( len != 0 )
+{
+ret = pwrite(fidp->fd, buf, len, off);
+if ( ret < 0 )
+break;
+len -= ret;
+buf += ret;
+off += ret;
+}
+
+written = buf - device->buffer;
+if ( written == 0 )
+{
+p9_error(device, hdr->tag, errno);
+return;
+}
+fill_buffer(device, hdr->cmd + 1, hdr->tag, "U", &written);
+}
+
static void p9_clunk(device *device, struct p9_header *hdr)
{
uint32_t fid;
@@ -1182,6 +1228,10 @@ void *io_thread(void *arg)
p9_create(device, &hdr);
break;
+case P9_CMD_WRITE:
+p9_write(device, &hdr);
+break;
+
case P9_CMD_CLUNK:
p9_clunk(device, &hdr);
break;
--
2.35.3
[PATCH 29/29] tools/xenstored: have a single do_control_memreport()
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
---
tools/xenstored/control.c | 27 +++
1 file changed, 7 insertions(+), 20 deletions(-)
diff --git a/tools/xenstored/control.c b/tools/xenstored/control.c
index dae23a5ac0..7db2c4703b 100644
--- a/tools/xenstored/control.c
+++ b/tools/xenstored/control.c
@@ -216,23 +216,11 @@ static int do_control_logfile(const void *ctx, struct
connection *conn,
return 0;
}
-#ifdef __MINIOS__
-static int do_control_memreport(const void *ctx, struct connection *conn,
- const char **vec, int num)
-{
- if (num)
- return EINVAL;
-
- talloc_report_full(NULL, stdout);
-
- send_ack(conn, XS_CONTROL);
- return 0;
-}
-#else
static int do_control_memreport(const void *ctx, struct connection *conn,
const char **vec, int num)
{
FILE *fp;
+ char *filename;
int fd;
if (num > 1)
@@ -255,8 +243,12 @@ static int do_control_memreport(const void *ctx, struct
connection *conn,
if (!fp)
close(fd);
}
- } else
- fp = fopen(vec[0], "a");
+ } else {
+ filename = absolute_filename(ctx, vec[0]);
+ if (!filename)
+ return ENOMEM;
+ fp = fopen(filename, "a");
+ }
if (!fp)
return EBADF;
@@ -267,7 +259,6 @@ static int do_control_memreport(const void *ctx, struct
connection *conn,
send_ack(conn, XS_CONTROL);
return 0;
}
-#endif
static int do_control_print(const void *ctx, struct connection *conn,
const char **vec, int num)
@@ -310,11 +301,7 @@ static struct cmd_s cmds[] = {
"Default timeout is 60 seconds.", 5 },
#endif
{ "logfile", do_control_logfile, "" },
-#ifdef __MINIOS__
- { "memreport", do_control_memreport, "" },
-#else
{ "memreport", do_control_memreport, "[]" },
-#endif
{ "print", do_control_print, "" },
{ "quota", do_control_quota,
"[set ||max [-r]]" },
--
2.35.3
[PATCH 06/29] tools/xenlogd: add 9pfs version request support
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
---
tools/xenlogd/io.c | 202 +
1 file changed, 202 insertions(+)
diff --git a/tools/xenlogd/io.c b/tools/xenlogd/io.c
index 5a06f72338..f35520018f 100644
--- a/tools/xenlogd/io.c
+++ b/tools/xenlogd/io.c
@@ -22,8 +22,12 @@
#include "xenlogd.h"
/* P9 protocol commands (response is either cmd+1 or P9_CMD_ERROR). */
+#define P9_CMD_VERSION100
#define P9_CMD_ERROR 107
+#define P9_MIN_MSIZE 2048
+#define P9_VERSION"9P2000.u"
+
struct p9_qid {
uint8_t type;
#define QID_TYPE_DIR 0x80
@@ -267,6 +271,169 @@ static unsigned int add_string(device *device, const char
*str,
return ret;
}
+static bool chk_data(device *device, void *data, unsigned int len)
+{
+struct p9_header *hdr = device->buffer;
+
+if ( data + len <= device->buffer + hdr->size )
+return true;
+
+errno = E2BIG;
+
+return false;
+}
+
+static bool fill_data_elem(void **par, void **array, unsigned int *array_sz,
+ unsigned int elem_sz, void *data)
+{
+if ( *array_sz && !*array )
+{
+*array = calloc(*array_sz, elem_sz);
+if ( !*array )
+return false;
+*par = *array;
+}
+
+memcpy(*par, data, elem_sz);
+
+if ( *array_sz )
+{
+*par += elem_sz;
+*array_sz -= 1;
+}
+
+return true;
+}
+
+/*
+ * Fill variables with request data.
+ * fmt is a sequence of format characters. Supported characters are:
+ * a: an array (2 bytes number of elements + the following format as elements)
+ *The number of elements is stored in the first unsigned int parameter, the
+ *next parameter is a pointer to an array of elements as denoted by the
next
+ *format character. The array is allocated dynamically.
+ * b: 1 byte unsigned integer
+ *The value is stored in the next parameter with type uint8_t.
+ * D: Data blob (4 byte length + bytes)
+ *2 parameters are consumed, first an unsigned int for the length, then a
+ *pointer to the first uint8_t value.
+ *No array support.
+ * L: 8 byte unsigned integer
+ *The value is stored in the next parameter with type uint64_t.
+ * S: String (2 byte length + characters)
+ *The 0-terminated string is stored in device->str + off, off is stored in
+ *the next parameter with type unsigned int.
+ * U: 4 byte unsigned integer
+ *The value is stored in the next parameter with type uint32_t.
+ *
+ * Return value: number of filled variables, errno will be set in case of
+ * error.
+ */
+static int fill_data(device *device, const char *fmt, ...)
+{
+struct p9_header *hdr = device->buffer;
+void *data = hdr + 1;
+void *par;
+unsigned int pars = 0;
+const char *f;
+va_list ap;
+unsigned int len;
+unsigned int str_off;
+unsigned int array_sz = 0;
+void **array = NULL;
+
+va_start(ap, fmt);
+
+for ( f = fmt; *f; f++ )
+{
+if ( !array_sz )
+par = va_arg(ap, void *);
+
+switch ( *f )
+{
+case 'a':
+f++;
+if ( !*f || array_sz )
+fmt_err(fmt);
+if ( !chk_data(device, data, sizeof(uint16_t)) )
+return pars;
+array_sz = *(__packed uint16_t *)data;
+data += sizeof(uint16_t);
+*(unsigned int *)par = array_sz;
+array = va_arg(ap, void **);
+*array = NULL;
+break;
+
+case 'b':
+if ( !chk_data(device, data, sizeof(uint8_t)) )
+return pars;
+if ( !fill_data_elem(&par, array, &array_sz, sizeof(uint8_t),
+ data) )
+return pars;
+data += sizeof(uint8_t);
+break;
+
+case 'D':
+if ( array_sz )
+fmt_err(fmt);
+if ( !chk_data(device, data, sizeof(uint32_t)) )
+return pars;
+len = *(__packed uint32_t *)data;
+data += sizeof(uint32_t);
+*(unsigned int *)par = len;
+par = va_arg(ap, void *);
+if ( !chk_data(device, data, len) )
+return pars;
+memcpy(par, data, len);
+data += len;
+break;
+
+case 'L':
+if ( !chk_data(device, data, sizeof(uint64_t)) )
+return pars;
+if ( !fill_data_elem(&par, array, &array_sz, sizeof(uint64_t),
+ data) )
+return pars;
+data += sizeof(uint64_t);
+break;
+
+case 'S':
+if ( !chk_data(device, data, sizeof(uint16_t)) )
+retur
[PATCH 07/29] tools/xenlogd: add 9pfs attach request support
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().
For filling the qid data take the approach from the qemu 9pfs backend
implementation.
Signed-off-by: Juergen Gross
---
tools/xenlogd/io.c | 128
tools/xenlogd/xenlogd.c | 1 +
tools/xenlogd/xenlogd.h | 11
3 files changed, 140 insertions(+)
diff --git a/tools/xenlogd/io.c b/tools/xenlogd/io.c
index f35520018f..fa825c9f39 100644
--- a/tools/xenlogd/io.c
+++ b/tools/xenlogd/io.c
@@ -16,6 +16,8 @@
#include
#include
#include
+#include
+#include
#include/* For cpu barriers. */
#include
@@ -23,6 +25,7 @@
/* P9 protocol commands (response is either cmd+1 or P9_CMD_ERROR). */
#define P9_CMD_VERSION100
+#define P9_CMD_ATTACH 104
#define P9_CMD_ERROR 107
#define P9_MIN_MSIZE 2048
@@ -434,6 +437,92 @@ static int fill_data(device *device, const char *fmt, ...)
return pars;
}
+static struct p9_fid *find_fid(device *device, unsigned int fid)
+{
+struct p9_fid *fidp;
+
+XEN_TAILQ_FOREACH(fidp, &device->fids, list)
+{
+if ( fidp->fid == fid )
+return fidp;
+}
+
+return NULL;
+}
+
+static struct p9_fid *alloc_fid_mem(device *device, unsigned int fid,
+const char *path)
+{
+struct p9_fid *fidp;
+size_t pathlen;
+
+pathlen = strlen(device->host_path) + strlen(path) + 1;
+fidp = calloc(sizeof(*fidp) + pathlen, 1);
+if ( !fidp )
+return NULL;
+
+fidp->fid = fid;
+snprintf(fidp->path, pathlen, "%s%s", device->host_path, path);
+
+return fidp;
+}
+
+static struct p9_fid *alloc_fid(device *device, unsigned int fid,
+const char *path)
+{
+struct p9_fid *fidp;
+
+if ( find_fid(device, fid) )
+{
+errno = EBADFD;
+return NULL;
+}
+
+if ( device->n_fids >= device->max_open_files )
+{
+errno = EMFILE;
+return NULL;
+}
+
+fidp = alloc_fid_mem(device, fid, path);
+if ( !fidp )
+return NULL;
+
+XEN_TAILQ_INSERT_HEAD(&device->fids, fidp, list);
+device->n_fids++;
+
+return fidp;
+}
+
+static void free_fid(device *device, struct p9_fid *fidp)
+{
+if ( !fidp )
+return;
+
+device->n_fids--;
+XEN_TAILQ_REMOVE(&device->fids, fidp, list);
+free(fidp);
+}
+
+static int fill_qid(const char *path, struct p9_qid *qid, struct stat *stbuf)
+{
+struct stat st;
+
+if ( !stbuf )
+{
+if ( stat(path, &st) )
+return errno;
+
+stbuf = &st;
+}
+
+qid->type = S_ISDIR(stbuf->st_mode) ? QID_TYPE_DIR : 0;
+qid->version = stbuf->st_mtime ^ (stbuf->st_size << 8);
+qid->path = stbuf->st_ino;
+
+return 0;
+}
+
static void p9_error(device *device, uint16_t tag, uint32_t err)
{
unsigned int erroff;
@@ -476,6 +565,41 @@ static void p9_version(device *device, struct p9_header
*hdr)
version);
}
+static void p9_attach(device *device, struct p9_header *hdr)
+{
+uint32_t fid;
+uint32_t dummy_u32;
+unsigned int dummy_uint;
+struct p9_qid qid;
+int ret;
+
+ret = fill_data(device, "UUSSU", &fid, &dummy_u32, &dummy_uint,
&dummy_uint,
+&dummy_u32);
+if ( ret != 5 )
+{
+p9_error(device, hdr->tag, errno);
+return;
+}
+
+device->root_fid = alloc_fid(device, fid, "");
+if ( !device->root_fid )
+{
+p9_error(device, hdr->tag, errno);
+return;
+}
+
+ret = fill_qid(device->host_path, &qid, NULL);
+if ( ret )
+{
+free_fid(device, device->root_fid);
+device->root_fid = NULL;
+p9_error(device, hdr->tag, ret);
+return;
+}
+
+fill_buffer(device, hdr->cmd + 1, hdr->tag, "Q", &qid);
+}
+
void *io_thread(void *arg)
{
device *device = arg;
@@ -535,6 +659,10 @@ void *io_thread(void *arg)
p9_version(device, &hdr);
break;
+case P9_CMD_ATTACH:
+p9_attach(device, &hdr);
+break;
+
default:
syslog(LOG_DEBUG, "%u.%u sent unhandled command %u\n",
device->domid, device->devid, hdr.cmd);
diff --git a/tools/xenlogd/xenlogd.c b/tools/xenlogd/xenlogd.c
index da0a09a122..d2de7bfbf2 100644
--- a/tools/xenlogd/xenlogd.c
+++ b/tools/xenlogd/xenlogd.c
@@ -274,6 +274,7 @@ static device *new_device(unsigned int domid, unsigned int
devid)
pthread_cond_init(&device->cond, NULL);
pthread_mutex_init(&device->mutex, NULL);
+XEN_TAILQ_INIT(&device->fids);
val = read_backend_node(device, "security_model");
if ( !val || strcmp(val, "none") )
diff --git a/tools/xenlogd/xenlogd.h b/tools/xenlogd/xenlogd.h
index c10c6aa9e5..bd2a283ccb 100644
--- a/tools/xenlogd/xe
[PATCH] xen: avoid generation of stub header
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 ( such as PPC or RISC-V ) on initial
stages of adding support, it is needed to generate
for only define the mentioned above arch_pci_dev structure.
For the Arm-only stubs ( mentioned in for disabled
HAS_PCI and ARM-specific) will be needed
to add directly alongside . Only to
was added.
Suggested-by: Jan Beulich
Signed-off-by: Oleksii Kurochko
---
xen/arch/arm/domain_build.c| 1 +
xen/arch/arm/include/asm/pci.h | 7 ---
xen/arch/ppc/include/asm/pci.h | 7 ---
xen/include/xen/pci.h | 11 +++
4 files changed, 12 insertions(+), 14 deletions(-)
delete mode 100644 xen/arch/ppc/include/asm/pci.h
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 49792dd590..2dd2926b41 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
#include
diff --git a/xen/arch/arm/include/asm/pci.h b/xen/arch/arm/include/asm/pci.h
index 8cb46f6b71..7f77226c9b 100644
--- a/xen/arch/arm/include/asm/pci.h
+++ b/xen/arch/arm/include/asm/pci.h
@@ -130,13 +130,6 @@ bool pci_check_bar(const struct pci_dev *pdev, mfn_t
start, mfn_t end);
#else /*!CONFIG_HAS_PCI*/
-struct arch_pci_dev { };
-
-static always_inline bool is_pci_passthrough_enabled(void)
-{
-return false;
-}
-
struct pci_dev;
static inline void arch_pci_init_pdev(struct pci_dev *pdev) {}
diff --git a/xen/arch/ppc/include/asm/pci.h b/xen/arch/ppc/include/asm/pci.h
deleted file mode 100644
index e76c8e5475..00
--- a/xen/arch/ppc/include/asm/pci.h
+++ /dev/null
@@ -1,7 +0,0 @@
-#ifndef __ASM_PPC_PCI_H__
-#define __ASM_PPC_PCI_H__
-
-struct arch_pci_dev {
-};
-
-#endif /* __ASM_PPC_PCI_H__ */
diff --git a/xen/include/xen/pci.h b/xen/include/xen/pci.h
index 251b8761a8..168ca320ce 100644
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -68,7 +68,18 @@ typedef union {
};
} pci_sbdf_t;
+#ifdef CONFIG_HAS_PCI
#include
+#else
+
+struct arch_pci_dev { };
+
+static always_inline bool is_pci_passthrough_enabled(void)
+{
+return false;
+}
+
+#endif
struct pci_dev_info {
/*
--
2.41.0
Re: [PATCH 18/29] tools/xenstored: rename xenbus_evtchn()
Hi Juergen, On 01/11/2023 09:33, Juergen Gross wrote: 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. This works right now, but what guarantee us that Mini-OS will not change other symbols and clash with the one provided by Xenstored again? Furthermore, technically, this is a problem for all the other software linked with Mini-OS. So wouldn't it be better to modify the Mini-OS build system to prefix all the symbols of the linked binary (here Xenstored)? Cheers, -- Julien Grall
Re: [PATCH 18/29] tools/xenstored: rename xenbus_evtchn()
On 01.11.23 11:44, Julien Grall wrote: Hi Juergen, On 01/11/2023 09:33, Juergen Gross wrote: 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. This works right now, but what guarantee us that Mini-OS will not change other symbols and clash with the one provided by Xenstored again? Furthermore, technically, this is a problem for all the other software linked with Mini-OS. So wouldn't it be better to modify the Mini-OS build system to prefix all the symbols of the linked binary (here Xenstored)? How would that work? From Mini-OS point of view libraries are not distinguishable from the linked application. This would mean the build system would prefix the library symbols as well, while the application would try to reference the the un-prefixed library symbols. I think the only way to avoid this kind of problem would be to have a positive list of exported Mini-OS symbols and to hide all other symbols from linked libraries and the app. I can look into this, but I'd like to do this work outside of this series in order not to block its development for an unknown amount of time. Juergen OpenPGP_0xB0DE9DD628BF132F.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Xen 4.18 rc5
Hi all, Xen 4.18 rc5 is tagged. You can check that out from xen.git: git://xenbits.xen.org/xen.git 4.18.0-rc5 For your convenience there is also a tarball at: https://downloads.xenproject.org/release/xen/4.18.0-rc5/xen-4.18.0-rc5.tar.gz And the signature is at: https://downloads.xenproject.org/release/xen/4.18.0-rc5/xen-4.18.0-rc5.tar.gz.sig Please send bug reports and test reports to xen-devel@lists.xenproject.org. When sending bug reports, please CC relevant maintainers and me (henry.w...@arm.com). Kind regards, Henry
Re: [PATCH 18/29] tools/xenstored: rename xenbus_evtchn()
Hi Juergen, On 01/11/2023 11:08, Juergen Gross wrote: On 01.11.23 11:44, Julien Grall wrote: Hi Juergen, On 01/11/2023 09:33, Juergen Gross wrote: 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. This works right now, but what guarantee us that Mini-OS will not change other symbols and clash with the one provided by Xenstored again? Furthermore, technically, this is a problem for all the other software linked with Mini-OS. So wouldn't it be better to modify the Mini-OS build system to prefix all the symbols of the linked binary (here Xenstored)? How would that work? From Mini-OS point of view libraries are not distinguishable from the linked application. This would mean the build system would prefix the library symbols as well, while the application would try to reference the the un-prefixed library symbols. AFAICT, objcopy could rename symbols. So if you pre-process the libraries and application before hand, then you should still be able to link. I think the only way to avoid this kind of problem would be to have a positive list of exported Mini-OS symbols and to hide all other symbols from linked libraries and the app. I can look into this, but I'd like to do this work outside of this series in order not to block its development for an unknown amount of time. I am ok with that: Reviewed-by: Julien Grall Cheers, -- Julien Grall
Re: [PATCH v8 3/8] xen/arm: Fold mmu_init_secondary_cpu() to head.S
On 01/11/2023 01:58, Henry Wang wrote:
Hi Julien,
Hi,
On Nov 1, 2023, at 02:29, Julien Grall wrote:
Hi Henry,
+Ayan
On 23/10/2023 03:13, Henry Wang wrote:
Currently mmu_init_secondary_cpu() only enforces the page table
should not contain mapping that are both Writable and eXecutables
after boot. To ease the arch/arm/mm.c split work, fold this function
to head.S.
For arm32, introduce an assembly macro pt_enforce_wxn. The macro is
called before secondary CPUs jumping into the C world.
For arm64, set the SCTLR_Axx_ELx_WXN flag right when the MMU is
enabled. This would avoid the extra TLB flush and SCTLR dance.
For a random reader, it is not clear why you can't set WnX early for arm32 as
well. I think it would helpful to explain the difference. I.e. at the point the
MMU is enabled, the page-tables may still contain mapping which are writable
and executable.
Sounds good, I will add the suggested sentence.
.endm
+/*
+ * Enforce Xen page-tables do not contain mapping that are both
+ * Writable and eXecutables.
+ *
+ * This should be called on each secondary CPU.
+ */
+.macro pt_enforce_wxn tmp
+mrc CP32(\tmp, HSCTLR)
+orr \tmp, \tmp, #SCTLR_Axx_ELx_WXN
+dsb
+mcr CP32(\tmp, HSCTLR)
+/*
+ * The TLBs may cache SCTLR_EL2.WXN. So ensure it is synchronized
+ * before flushing the TLBs.
+ */
+isb
+flush_xen_tlb_local \tmp
+.endm
+
/*
* Common register usage in this file:
* r0 -
@@ -254,6 +273,7 @@ secondary_switched:
/* Use a virtual address to access the UART. */
mov_w r11, EARLY_UART_VIRTUAL_ADDRESS
#endif
+pt_enforce_wxn r0
From recent discussion on IRC, Ayan reminded me this patch [1]. Ideally, I
would want to print a message just before to indicate that the bit is set. But
I understand that this would need to be droppped in Ayan rework as we don't yet
support early printk in enable_mmu().
While debugging an MMU issue on Arm32, I wrote a patch to sprinkle prints in
the enable_mmu() code. I will clean-up the patch and send it.
Just to make sure, your patch is for both Arm32 and Arm64, is my understanding
correct?
No it is only for arm32.
If it is only for Arm32, do you need me adding the print for Arm64 as well in
this patch?
No need. For arm64, we will enable WnX at the same time as the MMU. So
we are already covered by the other prints.
I will add a print at that point. Meanwhile, I would move the call a few lines
above? This will allow Ayan to drop [1].
Yeah I will include Ayan’s change in this patch and add his sign-off.
PRINT("- Ready -\r\n")
/* Jump to C world */
mov_w r2, start_secondary
diff --git a/xen/arch/arm/arm64/mmu/head.S b/xen/arch/arm/arm64/mmu/head.S
index 88075ef083..df06cefbbe 100644
--- a/xen/arch/arm/arm64/mmu/head.S
+++ b/xen/arch/arm/arm64/mmu/head.S
@@ -264,10 +264,11 @@ ENDPROC(create_page_tables)
* Inputs:
* x0 : Physical address of the page tables.
The inputs list should be updated to mention what x1 means.
I will use “x1: Extra flags of the SCTLR.” if this looks good to you.
I am fine with that.
Cheers,
--
Julien Grall
Re: [PATCH v8 3/8] xen/arm: Fold mmu_init_secondary_cpu() to head.S
Hi Julien, > On Nov 1, 2023, at 20:05, Julien Grall wrote: >>> >>> While debugging an MMU issue on Arm32, I wrote a patch to sprinkle prints >>> in the enable_mmu() code. I will clean-up the patch and send it. >> Just to make sure, your patch is for both Arm32 and Arm64, is my >> understanding correct? > > No it is only for arm32. > >> If it is only for Arm32, do you need me adding the print for Arm64 as well >> in this patch? > > No need. For arm64, we will enable WnX at the same time as the MMU. So we are > already covered by the other prints. Ok, thanks for the explanation. Kind regards, Henry
[linux-linus test] 183644: regressions - trouble: fail/pass/starved
flight 183644 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/183644/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-examine 8 reboot fail REGR. vs. 183617 test-arm64-arm64-libvirt-xsm 8 xen-boot fail REGR. vs. 183617 test-arm64-arm64-xl-credit1 8 xen-boot fail REGR. vs. 183617 test-arm64-arm64-xl-credit2 8 xen-boot fail REGR. vs. 183617 test-arm64-arm64-xl-thunderx 8 xen-boot fail REGR. vs. 183617 test-arm64-arm64-xl 8 xen-boot fail REGR. vs. 183617 test-arm64-arm64-xl-vhd 8 xen-boot fail REGR. vs. 183617 test-arm64-arm64-libvirt-raw 8 xen-boot fail REGR. vs. 183617 test-arm64-arm64-xl-xsm 8 xen-boot fail REGR. vs. 183617 test-armhf-armhf-xl 8 xen-boot fail REGR. vs. 183617 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 183617 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 183617 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 183617 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 183617 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 183617 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 183617 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 183617 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 183617 test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qcow2 14 migrate-support-checkfail never pass test-amd64-amd64-libvirt-raw 14 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass test-amd64-amd64-dom0pvh-xl-amd 3 hosts-allocate starved n/a version targeted for testing: linux89ed67ef126c4160349c1b96fdb775ea6170ac90 baseline version: linuxffc253263a1375a65fa6c9f62a893e9767fbebfa Last test of basis 183617 2023-10-30 08:36:55 Z2 days Failing since183625 2023-10-31 02:27:44 Z1 days3 attempts Testing same since 183644 2023-10-31 23:14:38 Z0 days1 attempts 677 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-arm64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-xl
Re: exynos-mixer 14450000.mixer: [drm:exynos_drm_register_dma] *ERROR* Device 14450000.mixer lacks support for IOMMU
Hi Marek, I would like to recompile and install the kernel 6.6 on my ARM Chromebook. I would like to know if your patch has been accepted and included there. Thanks. On Wed, Nov 1, 2023 at 8:48 AM Chuck Zmudzinski wrote: > > On 10/31/2023 8:08 AM, Marek Szyprowski wrote: > > Hi, > > > > On 31.10.2023 00:03, Mario Marietto wrote: > >> We are a team of linux enthusiasts who are trying to boot Xen on a > >> Samsung XE303C12 Chromebook aka "snow" following the suggestions in > >> the slide show presentation here: > >> https://www.slideshare.net/xen_com_mgr/xpds16-porting-xen-on-arm-to-a-new-soc-julien-grall-arm > >> This device uses an exynos5250 SOC dual core 1.7 GHz with 2 MB RAM, it > >> is a Samsung armv7 chip with virtualization extensions. In particular, > >> we have it working fairly well both on the bare metal with a recent > >> 6.1.59 Linux LTS kernel and also with a recent 5.4.257 LTS kernel with > >> KVM, the older LTS kernel version is used to test KVM because support > >> for KVM on arm v7 was removed from Linux around kernel version 5.7. So > >> we know we have the hypervisor mode enabled because we were able to > >> use it with KVM. For Xen, we are using the latest Debian build of Xen > >> 4.17 for the Debian armhf architecture: (XEN) Xen version 4.17.2-pre > >> (Debian 4.17.1+2-gb773c48e36-1) > >> (pkg-xen-devel@xxx) (arm-linux-gnueabihf-gcc > >> (Debian 12.2.0-14) 12.2.0) debug=n Thu May 18 19:26:30 UTC 2023 The > >> Linux kernel is a custom build that adds the Xen config kernel options > >> (CONFIG_XEN_DOM0, etc) on top of a kernel that works well on the same > >> Chromebook model on the bare metal. I can provide the config options > >> of the kernel that was used if that is helpful. Our method of booting > >> is to have u-boot boot the Xen hypervisor and load the device tree > >> after adding the dom0 to the otherwise unaltered device tree from the > >> Linux kernel using u-boot fdt commands to add a /chosen node, as > >> described on the Xen wiki and in the pages linked from there. We have > >> also tried adding and loading an initrd.img using the device tree > >> /chosen node but that made no difference in our tests. We actually > >> have the Linux LTS kernel version 6.1.59 working as dom0 with Xen > >> using the same version of u-boot that we used for KVM, but with a big > >> problem. The problem we see is that when booting the 6.1.59 kernel > >> version as dom0 with Xen, the screen is totally dark and the only way > >> to access the system is remotely through ssh. Logs indicate most > >> everything else is working, such as the wifi card so we can access it > >> remotely via ssh and a USB optical mouse lights up when connected so > >> USB is also working. Obviously, the disk is also working. The > >> Chromebook is configured to boot from the device's SD card slot by > >> turning on Chrome OS developer mode options to enable booting from the > >> SD card slot. The mystery is that when booting the exact same 6.1.59 > >> kernel on the bare metal instead of booting it as dom0 on Xen, it > >> boots up with full access to the screen and we can interact with the > >> system using the X.org windows system. But booting as dom0 with Xen, > >> the screen is totally dark and the only access we have to the system > >> is through the network via ssh. Also, when booting the 5.4.257 kernel > >> with KVM in hypervisor mode, the screen works and we can interact with > >> the system through the X.org windows system. Exploring the log file,we > >> have seen the errors below : > >> > >> Without Xen (or in bare metal): > >> > >> devuan-bunsen kernel: [drm] Exynos DRM: using 1440.fimd device for > >> DMA mapping operations > >> devuan-bunsen kernel: exynos-drm exynos-drm: bound 1440.fimd (ops > >> 0xc0d96354) > >> devuan-bunsen kernel: exynos-drm exynos-drm: bound 1445.mixer (ops > >> 0xc0d97554) > >> devuan-bunsen kernel: exynos-drm exynos-drm: bound > >> 145b.dp-controller (ops 0xc0d97278) > >> devuan-bunsen kernel: exynos-drm exynos-drm: bound 1453.hdmi (ops > >> 0xc0d97bd0) > >> ... > >> devuan-bunsen kernel: Console: switching to colour frame buffer device > >> 170x48 > >> devuan-bunsen kernel: exynos-drm exynos-drm: [drm] fb0: exynosdrmfb > >> frame buffer device > >> devuan-bunsen kernel: [drm] Initialized exynos 1.1.0 20180330 for > >> exynos-drm on minor 0 > >> > >> In this case,the kernel is able to use the exynos-drm kernel to start > >> the fb0 device. But with Xen we get this error with exynos-drm: > >> > >> devuan-bunsen kernel: [drm] Exynos DRM: using 1440.fimd device for > >> DMA mapping operations > >> devuan-bunsen kernel: exynos-drm exynos-drm: bound 1440.fimd (ops > >> 0xc0d96354) > >> devuan-bunsen kernel: exynos-mixer 1445.mixer: > >> [drm:exynos_drm_register_dma] *ERROR* Device 1445.mixer lacks > >> support for IOMMU > >> devuan-bunsen kernel: exynos-drm exynos-drm: failed to bind > >> 1445.mixer (ops 0xc0d97554): -22 > >> dev
Re: [PATCH 1/3] Mini-OS: make xenstore_buf externally visible
On Wed, Nov 1, 2023 at 6:13 AM Juergen Gross wrote: > > For support of the 9pfs frontend in Xenstore-stubdom xenstore_buf > needs to be externally visible. > > Signed-off-by: Juergen Gross xenstore_buf will be used by the xen.git patch "[PATCH 24/29] tools/xenstored: map stubdom interface". Reviewed-by: Jason Andryuk Thanks, Jason
Re: [PATCH 2/3] Mini-OS: don't crash if no shutdown node is available
On Wed, Nov 1, 2023 at 5:06 AM Juergen Gross wrote: > > 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 was taken. Just ignore this error now. > > Signed-off-by: Juergen Gross Reviewed-by: Jason Andryuk
Re: [PATCH 3/3] Mini-OS: fix 9pfs stat receive format
On Wed, Nov 1, 2023 at 5:14 AM Juergen Gross wrote:
>
> 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
> ---
> 9pfront.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/9pfront.c b/9pfront.c
> index 5da8a365..43c7409f 100644
> --- a/9pfront.c
> +++ b/9pfront.c
> @@ -711,6 +711,7 @@ static int p9_create(struct dev_9pfs *dev, uint32_t fid,
> char *path,
> static int p9_stat(struct dev_9pfs *dev, uint32_t fid, struct p9_stat *stat)
> {
> struct req *req = get_free_req(dev);
> +uint16_t total;
> int ret;
>
> if ( !req )
> @@ -719,10 +720,10 @@ static int p9_stat(struct dev_9pfs *dev, uint32_t fid,
> struct p9_stat *stat)
> memset(stat, 0, sizeof(*stat));
> req->cmd = P9_CMD_STAT;
> send_9p(dev, req, "U", fid);
> -rcv_9p(dev, req, "uuUQUUULSUUU", &stat->size, &stat->type,
> &stat->dev,
> - stat->qid, &stat->mode, &stat->atime, &stat->mtime, &stat->length,
> - &stat->name, &stat->uid, &stat->gid, &stat->muid,
> &stat->extension,
> - &stat->n_uid, &stat->n_gid, &stat->n_muid);
> +rcv_9p(dev, req, "uuuUQUUULSUUU", &total, &stat->size, &stat->type,
> + &stat->dev, stat->qid, &stat->mode, &stat->atime, &stat->mtime,
> + &stat->length, &stat->name, &stat->uid, &stat->gid, &stat->muid,
> + &stat->extension, &stat->n_uid, &stat->n_gid, &stat->n_muid);
total is unused by the linux frontend end as well. Looks like QEMU
hard codes the value as 0.
Reviewed-by: Jason Andryuk
Thanks,
Jason
[PATCH v4] acpi/processor: sanitize _OSC/_PDC capabilities for Xen dom0
From: Roger Pau Monne
The Processor capability bits notify ACPI of the OS capabilities, and
so ACPI can adjust the return of other Processor methods taking the OS
capabilities into account.
When Linux is running as a Xen dom0, the hypervisor is the entity
in charge of processor power management, and hence Xen needs to make
sure the capabilities reported by _OSC/_PDC match the capabilities of
the driver in Xen.
Introduce a small helper to sanitize the buffer when running as Xen
dom0.
When Xen supports HWP, this serves as the equivalent of commit
a21211672c9a ("ACPI / processor: Request native thermal interrupt
handling via _OSC") to avoid SMM crashes. Xen will set bit
ACPI_PROC_CAP_COLLAB_PROC_PERF (bit 12) in the capability bits and the
_OSC/_PDC call will apply it.
[ jandryuk: Mention Xen HWP's need. Support _OSC & _PDC ]
Signed-off-by: Roger Pau Monné
Cc: sta...@vger.kernel.org
Signed-off-by: Jason Andryuk
---
v4:
Use xen_santize_proc_cap_bits() name - Michal
Rephrase comment - Michal
v3:
Move xen_sanitize_pdc() call to arch_acpi_set_proc_cap_bits() to cover
_OSC and _PDC.
drivers/xen/pcpu.c is CONFIG_DOM0 && CONFIG_X86
v2:
Move local variables in acpi_processor_eval_pdc() to reuse in both conditions.
---
arch/x86/include/asm/acpi.h | 14 ++
arch/x86/include/asm/xen/hypervisor.h | 9 +
drivers/xen/pcpu.c| 21 +
3 files changed, 44 insertions(+)
diff --git a/arch/x86/include/asm/acpi.h b/arch/x86/include/asm/acpi.h
index c8a7fc23f63c..f896eed4516c 100644
--- a/arch/x86/include/asm/acpi.h
+++ b/arch/x86/include/asm/acpi.h
@@ -16,6 +16,9 @@
#include
#include
#include
+#include
+
+#include
#ifdef CONFIG_ACPI_APEI
# include
@@ -127,6 +130,17 @@ static inline void arch_acpi_set_proc_cap_bits(u32 *cap)
if (!cpu_has(c, X86_FEATURE_MWAIT) ||
boot_option_idle_override == IDLE_NOMWAIT)
*cap &= ~(ACPI_PROC_CAP_C_C1_FFH | ACPI_PROC_CAP_C_C2C3_FFH);
+
+ if (xen_initial_domain()) {
+ /*
+* When Linux is running as Xen dom0, the hypervisor is the
+* entity in charge of the processor power management, and so
+* Xen needs to check the OS capabilities reported in the
+* processor capabilities buffer matches what the hypervisor
+* driver supports.
+*/
+ xen_sanitize_proc_cap_bits(cap);
+ }
}
static inline bool acpi_has_cpu_in_madt(void)
diff --git a/arch/x86/include/asm/xen/hypervisor.h
b/arch/x86/include/asm/xen/hypervisor.h
index 7048dfacc04b..a9088250770f 100644
--- a/arch/x86/include/asm/xen/hypervisor.h
+++ b/arch/x86/include/asm/xen/hypervisor.h
@@ -100,4 +100,13 @@ static inline void leave_lazy(enum xen_lazy_mode mode)
enum xen_lazy_mode xen_get_lazy_mode(void);
+#if defined(CONFIG_XEN_DOM0) && defined(CONFIG_ACPI)
+void xen_sanitize_proc_cap_bits(uint32_t *buf);
+#else
+static inline void xen_sanitize_proc_cap_bits(uint32_t *buf)
+{
+ BUG();
+}
+#endif
+
#endif /* _ASM_X86_XEN_HYPERVISOR_H */
diff --git a/drivers/xen/pcpu.c b/drivers/xen/pcpu.c
index b3e3d1bb37f3..7000701dff8f 100644
--- a/drivers/xen/pcpu.c
+++ b/drivers/xen/pcpu.c
@@ -47,6 +47,9 @@
#include
#include
+#ifdef CONFIG_ACPI
+#include
+#endif
/*
* @cpu_id: Xen physical cpu logic number
@@ -400,4 +403,22 @@ bool __init xen_processor_present(uint32_t acpi_id)
return online;
}
+
+void xen_sanitize_proc_cap_bits(uint32_t *cap)
+{
+ struct xen_platform_op op = {
+ .cmd= XENPF_set_processor_pminfo,
+ .u.set_pminfo.id= -1,
+ .u.set_pminfo.type = XEN_PM_PDC,
+ };
+ u32 buf[3] = { ACPI_PDC_REVISION_ID, 1, *cap };
+ int ret;
+
+ set_xen_guest_handle(op.u.set_pminfo.pdc, buf);
+ ret = HYPERVISOR_platform_op(&op);
+ if (ret)
+ pr_err("sanitize of _PDC buffer bits from Xen failed: %d\n",
+ ret);
+ *cap = buf[2];
+}
#endif
--
2.41.0
[PATCH 1/2] Mini-OS: link kernel separately
Add an additional link step with linking all Mini-OS kernel binaries into a single object file. This is done in preparation of hiding Mini-OS internal symbols before linking the kernel with libraries and an application. Signed-off-by: Juergen Gross --- Makefile | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 7ee181a2..85c6db75 100644 --- a/Makefile +++ b/Makefile @@ -164,8 +164,11 @@ endif $(OBJ_DIR)/arch/x86/minios-x86%.lds: arch/x86/minios-x86.lds.S $(CPP) $(ASFLAGS) -P $< -o $@ -$(OBJ_DIR)/$(TARGET): $(OBJS) $(APP_O) arch_lib $(OBJ_DIR)/$(TARGET_ARCH_DIR)/minios-$(MINIOS_TARGET_ARCH).lds - $(LD) -r $(LDFLAGS) $(HEAD_OBJ) $(APP_O) $(OBJS) $(LDARCHLIB) $(LDLIBS) -o $@.o +$(OBJ_DIR)/$(TARGET)-kern.o: $(OBJS) arch_lib $(OBJ_DIR)/$(TARGET_ARCH_DIR)/minios-$(MINIOS_TARGET_ARCH).lds + $(LD) -r $(LDFLAGS) $(HEAD_OBJ) $(OBJS) $(LDARCHLIB) -o $@ + +$(OBJ_DIR)/$(TARGET): $(OBJ_DIR)/$(TARGET)-kern.o $(APP_O) + $(LD) -r $(LDFLAGS) $(OBJ_DIR)/$(TARGET)-kern.o $(APP_O) $(LDLIBS) -o $@.o $(OBJCOPY) -w -G $(GLOBAL_PREFIX)* -G _start $@.o $@.o $(LD) $(LDFLAGS) $(LDFLAGS_FINAL) $@.o $(EXTRA_OBJS) -o $@-debug strip -s $@-debug -o $@ -- 2.35.3
[PATCH 0/2] Mini-OS: hide mini-os internal symbols
In order to avoid conflicts due to symbols with the same name when linking Mini-OS with an application, hide all Mini9-OS internal symbols from the application by linking the Mini-OS kernel individually and then removing all symbols which should be used internally only. Juergen Gross (2): Mini-OS: link kernel separately Mini-OS: keep a positive list of externally visible symbols Makefile| 8 ++- mini-os.map | 187 2 files changed, 193 insertions(+), 2 deletions(-) create mode 100644 mini-os.map -- 2.35.3
[PATCH 2/2] Mini-OS: keep a positive list of externally visible symbols
Add a mini-os.map file containing all global symbols that are allowed to be referenced by an application or library. Hide all other symbols of Mini-OS from being visible externally. The symbols in mini-os.map have been obtained via building all defined and not failing stubdoms (caml-stubdom doesn't build). Signed-off-by: Juergen Gross --- Makefile| 3 +- mini-os.map | 187 2 files changed, 189 insertions(+), 1 deletion(-) create mode 100644 mini-os.map diff --git a/Makefile b/Makefile index 85c6db75..d4768110 100644 --- a/Makefile +++ b/Makefile @@ -164,8 +164,9 @@ endif $(OBJ_DIR)/arch/x86/minios-x86%.lds: arch/x86/minios-x86.lds.S $(CPP) $(ASFLAGS) -P $< -o $@ -$(OBJ_DIR)/$(TARGET)-kern.o: $(OBJS) arch_lib $(OBJ_DIR)/$(TARGET_ARCH_DIR)/minios-$(MINIOS_TARGET_ARCH).lds +$(OBJ_DIR)/$(TARGET)-kern.o: $(OBJS) arch_lib $(OBJ_DIR)/$(TARGET_ARCH_DIR)/minios-$(MINIOS_TARGET_ARCH).lds mini-os.map $(LD) -r $(LDFLAGS) $(HEAD_OBJ) $(OBJS) $(LDARCHLIB) -o $@ + $(OBJCOPY) -w -G $(GLOBAL_PREFIX)* --keep-global-symbols=mini-os.map $@ $@ $(OBJ_DIR)/$(TARGET): $(OBJ_DIR)/$(TARGET)-kern.o $(APP_O) $(LD) -r $(LDFLAGS) $(OBJ_DIR)/$(TARGET)-kern.o $(APP_O) $(LDLIBS) -o $@.o diff --git a/mini-os.map b/mini-os.map new file mode 100644 index ..b62806e1 --- /dev/null +++ b/mini-os.map @@ -0,0 +1,187 @@ +# Mini-OS symbols being externally visible +# entry point +_start +# Mini-OS service functions +alloc_fd +alloc_file_type +alloc_pages +bind_virq +block +console_print +create_thread +do_map_frames +free_pages +get_file_from_fd +hypercall_page +event_queue +evtchn_alloc_unbound +evtchn_bind_interdomain +evtchn_get_peercontext +gntmap_fini +gntmap_init +gntmap_map_grant_refs +gntmap_munmap +gntmap_set_max_grants +map_frames_ex +mask_evtchn +need_pgt +printk +schedule +stop_kernel +unbind_evtchn +unmask_evtchn +wake +xencons_ring_avail +xprintk +__local_irq_restore +__local_irq_save +__udivdi3 +__udivmoddi4 +__umoddi3 +# libc +accept +bind +chdir +clock_gettime +close +closedir +connect +do_exit +dup +dup2 +execv +fcntl +fork +fstat64 +fsync +ftruncate +getpagesize +getpid +getsockname +getsockopt +gettimeofday +htonl +htons +inet_aton +inet_ntoa +isatty +kill +link +listen +lockf +lseek64 +mkdir +mmap64 +munmap +nanosleep +ntohl +ntohs +open64 +opendir +openlog +pipe +poll +posix_openpt +read +readdir +recv +rmdir +sbrk +select +select_read_flag +send +sendto +setsid +setsockopt +sigaction +sleep +socket +stat +sysconf +syslog +tcgetattr +tcsetattr +umask +unlink +usleep +waitpid +write +_exit +_fini +_init +___lock_acquire +___lock_acquire_recursive +___lock_init_recursive +___lock_release +___lock_release_recursive +# 9pfront driver +init_9pfront +# blkfront driver +blkfront_aio +blkfront_aio_poll +blkfront_aio_push_operation +blkfront_io +blkfront_open +blkfront_queue +blkfront_sync +init_blkfront +shutdown_blkfront +# fbfront driver +fbfront_open +fbfront_receive +fbfront_resize +fbfront_update +init_fbfront +shutdown_fbfront +# kbdfront driver +init_kbdfront +kbdfront_open +kbdfront_receive +shutdown_kbdfront +# netfront driver +init_netfront +netfront_receive +netfront_tap_open +netfront_xmit +networking_set_addr +shutdown_netfront +# pcifront driver +pcifront_conf_read +pcifront_conf_write +pcifront_scan +shutdown_pcifront +# tpmback driver +init_tpmback +shutdown_tpmback +tpmback_get_opaque +tpmback_get_peercontext +tpmback_get_uuid +tpmback_req_any +tpmback_resp +tpmback_set_opaque +# tpmfront driver +init_tpmfront +shutdown_tpmfront +tpmfront_cmd +tpmfront_open +# tpm_tis driver +init_tpm_tis +init_tpm2_tis +tpm_tis_open +tpm_tis_request_locality +# xenbus driver +xenbus_ls +xenbus_read +xenbus_wait_for_watch +xenbus_watch_path_token +xenbus_unwatch_path_token +xs_daemon_open +xs_directory +xs_fileno +xs_get_domain_path +xs_read +xs_read_watch +xs_rm +xs_unwatch +xs_watch +xs_write -- 2.35.3
[PATCH] stubdom: remove caml-stubdom
In order to build caml-stubdom, it must be explicitly enabled via "configure --enable-caml-stubdom". The build process is failing due to stubdom/ocaml.patch failing to apply. Since the patched file has been modified in 2014 the last time, it seems nobody cares for caml-stubdom since at least then. Remove caml-stubdom from the build system. Signed-off-by: Juergen Gross --- stubdom/Makefile | 51 stubdom/caml/Makefile| 24 - stubdom/caml/hello.ml| 4 --- stubdom/caml/main-caml.c | 42 -- stubdom/caml/minios.cfg | 0 stubdom/configure| 56 stubdom/configure.ac | 2 -- stubdom/ocaml.patch | 19 -- 8 files changed, 198 deletions(-) delete mode 100644 stubdom/caml/Makefile delete mode 100644 stubdom/caml/hello.ml delete mode 100644 stubdom/caml/main-caml.c delete mode 100644 stubdom/caml/minios.cfg delete mode 100644 stubdom/ocaml.patch diff --git a/stubdom/Makefile b/stubdom/Makefile index 0ddfce1ba2..27a18a9e33 100644 --- a/stubdom/Makefile +++ b/stubdom/Makefile @@ -257,37 +257,6 @@ $(TPMEMU_STAMPFILE): tpm_emulator-$(XEN_TARGET_ARCH) $(GMP_STAMPFILE) .PHONY: cross-tpmemu cross-tpmemu: $(TPMEMU_STAMPFILE) -# -# Cross-ocaml -# - -CAMLLIB = $(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/lib/ocaml -OCAML_STAMPFILE=$(CAMLLIB)/.dirstamp - -ocaml-$(OCAML_VERSION).tar.gz: - $(FETCHER) $@ $(OCAML_URL)/$@ - -ocaml-$(XEN_TARGET_ARCH)/.dirstamp: ocaml-$(OCAML_VERSION).tar.gz ocaml.patch - tar xzf $< - cd ocaml-$(OCAML_VERSION) && patch -p0 < ../ocaml.patch - rm -rf ocaml-$(XEN_TARGET_ARCH) - mv ocaml-$(OCAML_VERSION) ocaml-$(XEN_TARGET_ARCH) - touch $@ - -MINIOS_HASNOT=IPV6 INET_ATON - -.PHONY: cross-ocaml -cross-ocaml: $(OCAML_STAMPFILE) -$(OCAML_STAMPFILE): ocaml-$(XEN_TARGET_ARCH)/.dirstamp - cd ocaml-$(XEN_TARGET_ARCH) && ./configure -prefix $(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf \ - -no-pthread -no-shared-libs -no-tk -no-curses \ - -cc "$(CC) -U_FORTIFY_SOURCE -fno-stack-protector -mno-red-zone" - $(foreach i,$(MINIOS_HASNOT),sed -i 's,^\(#define HAS_$(i)\),//\1,' ocaml-$(XEN_TARGET_ARCH)/config/s.h ; ) - $(MAKE) DESTDIR= -C ocaml-$(XEN_TARGET_ARCH) world - $(MAKE) DESTDIR= -C ocaml-$(XEN_TARGET_ARCH) opt - $(MAKE) -C ocaml-$(XEN_TARGET_ARCH) install - touch $@ - ### # Links ### @@ -419,17 +388,6 @@ ioemu: cross-zlib cross-libpci libxenguest ioemu-minios-config.mk $(QEMU_ROOT)/xen-setup-stubdom ) $(MAKE) DESTDIR= -C ioemu -f $(QEMU_ROOT)/Makefile -## -# caml -## - -caml-minios-config.mk: $(CURDIR)/caml/minios.cfg - MINIOS_CONFIG="$<" CONFIG_FILE="$(CURDIR)/$@" $(MAKE) DESTDIR= -C $(MINI_OS) config - -.PHONY: caml -caml: $(CROSS_ROOT) - CPPFLAGS="$(TARGET_CPPFLAGS) $(shell cat caml-minios-config.mk)" CFLAGS="$(TARGET_CFLAGS)" $(MAKE) DESTDIR= -C $@ LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) OCAMLC_CROSS_PREFIX=$(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/bin/ - ### # C ### @@ -516,10 +474,6 @@ ioemu-stubdom: APP_OBJS=$(CURDIR)/ioemu/i386-stubdom/qemu.a $(CURDIR)/ioemu/i386 ioemu-stubdom: mini-os-$(XEN_TARGET_ARCH)-ioemu lwip-$(XEN_TARGET_ARCH) libxenguest ioemu DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/ioemu-minios.cfg" $(MAKE) DESTDIR= -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS="$(APP_OBJS)" -.PHONY: caml-stubdom -caml-stubdom: mini-os-$(XEN_TARGET_ARCH)-caml lwip-$(XEN_TARGET_ARCH) libxenguest cross-ocaml caml - DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/caml/minios.cfg" $(MAKE) DESTDIR= -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS="$(CURDIR)/caml/main-caml.o $(CURDIR)/caml/caml.o $(CAMLLIB)/libasmrun.a" - .PHONY: c-stubdom c-stubdom: mini-os-$(XEN_TARGET_ARCH)-c lwip-$(XEN_TARGET_ARCH) libxenguest c DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/c/minios.cfg" $(MAKE) DESTDIR= -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS=$(CURDIR)/c/main.a @@ -580,8 +534,6 @@ endif install-c: c-stubdom -install-caml: caml-stubdom - install-xenstore: xenstore-stubdom $(INSTALL_DIR) "$(DESTDIR)$(XENFIRMWAREDIR)" $(INSTALL_DATA) mini-os-$(XEN_TARGET_ARCH)-xenstore/mini-os.gz "$(DESTDIR)$(XENFIRMWAREDIR)/xenstore-stubdom.gz" @@ -642,13 +594,11 @@ clean: $(foreach lib,$(STUB_LIBS),clean-libxen$(lib)) clean: rm -fr mini-os-$(XEN_TARGET_ARCH)-ioemu rm -fr mini-os-$(XEN_TARGET_ARCH)-c - rm -fr mini-os-$(XEN_TARGET_ARCH)-caml rm -fr m
Re: [PATCH] stubdom: remove caml-stubdom
On 01/11/2023 4:08 pm, Juergen Gross wrote: > In order to build caml-stubdom, it must be explicitly enabled via > "configure --enable-caml-stubdom". The build process is failing due to > stubdom/ocaml.patch failing to apply. Since the patched file has been > modified in 2014 the last time, it seems nobody cares for caml-stubdom > since at least then. > > Remove caml-stubdom from the build system. > > Signed-off-by: Juergen Gross CC-ing some of the Ocaml folks just in case, but I expect that this functionality has been entirely superseded by MirageOS and/or Solo5. Also, hunk to the Removed section of CHANGELOG.md please (can be fixed on commit if no other changes are needed.) ~Andrew > --- > stubdom/Makefile | 51 > stubdom/caml/Makefile| 24 - > stubdom/caml/hello.ml| 4 --- > stubdom/caml/main-caml.c | 42 -- > stubdom/caml/minios.cfg | 0 > stubdom/configure| 56 > stubdom/configure.ac | 2 -- > stubdom/ocaml.patch | 19 -- > 8 files changed, 198 deletions(-) > delete mode 100644 stubdom/caml/Makefile > delete mode 100644 stubdom/caml/hello.ml > delete mode 100644 stubdom/caml/main-caml.c > delete mode 100644 stubdom/caml/minios.cfg > delete mode 100644 stubdom/ocaml.patch > > diff --git a/stubdom/Makefile b/stubdom/Makefile > index 0ddfce1ba2..27a18a9e33 100644 > --- a/stubdom/Makefile > +++ b/stubdom/Makefile > @@ -257,37 +257,6 @@ $(TPMEMU_STAMPFILE): tpm_emulator-$(XEN_TARGET_ARCH) > $(GMP_STAMPFILE) > .PHONY: cross-tpmemu > cross-tpmemu: $(TPMEMU_STAMPFILE) > > -# > -# Cross-ocaml > -# > - > -CAMLLIB = $(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/lib/ocaml > -OCAML_STAMPFILE=$(CAMLLIB)/.dirstamp > - > -ocaml-$(OCAML_VERSION).tar.gz: > - $(FETCHER) $@ $(OCAML_URL)/$@ > - > -ocaml-$(XEN_TARGET_ARCH)/.dirstamp: ocaml-$(OCAML_VERSION).tar.gz ocaml.patch > - tar xzf $< > - cd ocaml-$(OCAML_VERSION) && patch -p0 < ../ocaml.patch > - rm -rf ocaml-$(XEN_TARGET_ARCH) > - mv ocaml-$(OCAML_VERSION) ocaml-$(XEN_TARGET_ARCH) > - touch $@ > - > -MINIOS_HASNOT=IPV6 INET_ATON > - > -.PHONY: cross-ocaml > -cross-ocaml: $(OCAML_STAMPFILE) > -$(OCAML_STAMPFILE): ocaml-$(XEN_TARGET_ARCH)/.dirstamp > - cd ocaml-$(XEN_TARGET_ARCH) && ./configure -prefix > $(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf \ > - -no-pthread -no-shared-libs -no-tk -no-curses \ > - -cc "$(CC) -U_FORTIFY_SOURCE -fno-stack-protector -mno-red-zone" > - $(foreach i,$(MINIOS_HASNOT),sed -i 's,^\(#define HAS_$(i)\),//\1,' > ocaml-$(XEN_TARGET_ARCH)/config/s.h ; ) > - $(MAKE) DESTDIR= -C ocaml-$(XEN_TARGET_ARCH) world > - $(MAKE) DESTDIR= -C ocaml-$(XEN_TARGET_ARCH) opt > - $(MAKE) -C ocaml-$(XEN_TARGET_ARCH) install > - touch $@ > - > ### > # Links > ### > @@ -419,17 +388,6 @@ ioemu: cross-zlib cross-libpci libxenguest > ioemu-minios-config.mk > $(QEMU_ROOT)/xen-setup-stubdom ) > $(MAKE) DESTDIR= -C ioemu -f $(QEMU_ROOT)/Makefile > > -## > -# caml > -## > - > -caml-minios-config.mk: $(CURDIR)/caml/minios.cfg > - MINIOS_CONFIG="$<" CONFIG_FILE="$(CURDIR)/$@" $(MAKE) DESTDIR= -C > $(MINI_OS) config > - > -.PHONY: caml > -caml: $(CROSS_ROOT) > - CPPFLAGS="$(TARGET_CPPFLAGS) $(shell cat caml-minios-config.mk)" > CFLAGS="$(TARGET_CFLAGS)" $(MAKE) DESTDIR= -C $@ > LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) > OCAMLC_CROSS_PREFIX=$(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/bin/ > - > ### > # C > ### > @@ -516,10 +474,6 @@ ioemu-stubdom: > APP_OBJS=$(CURDIR)/ioemu/i386-stubdom/qemu.a $(CURDIR)/ioemu/i386 > ioemu-stubdom: mini-os-$(XEN_TARGET_ARCH)-ioemu lwip-$(XEN_TARGET_ARCH) > libxenguest ioemu > DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" > DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/ioemu-minios.cfg" > $(MAKE) DESTDIR= -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< > LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS="$(APP_OBJS)" > > -.PHONY: caml-stubdom > -caml-stubdom: mini-os-$(XEN_TARGET_ARCH)-caml lwip-$(XEN_TARGET_ARCH) > libxenguest cross-ocaml caml > - DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" > DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/caml/minios.cfg" > $(MAKE) DESTDIR= -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< > LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) > APP_OBJS="$(CURDIR)/caml/main-caml.o $(CURDIR)/caml/caml.o > $(CAMLLIB)/libasmrun.a" > - > .PHONY: c-stubdom > c-stubdom: mini-os-$(XEN_TARGET_ARCH)-c lwip-$(XEN_TARGET_ARCH) libxenguest c > DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" > DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/c/minios.cfg" > $(MAKE) DESTDIR= -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< > LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS=$(CURDIR)/c/main.a > @@ -580,8 +534,6 @@ endif > >
Re: [PATCH 2/3] Mini-OS: don't crash if no shutdown node is available
On 01/11/2023 9:00 am, Juergen Gross wrote: > 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 was taken. Just ignore this error now. > > Signed-off-by: Juergen Gross Which cases might we not have a control/shutdown node? I'm all for coping better with its absence, but it's not a piece of the Xen ABI which is optional. And on that front, not crashing is good, but why remove the watch? What if it comes into existence later? Is there any problem with just leaving the watch outstanding? ~Andrew
Re: [PATCH 2/3] Mini-OS: don't crash if no shutdown node is available
On 01.11.23 17:38, Andrew Cooper wrote: On 01/11/2023 9:00 am, Juergen Gross wrote: 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 was taken. Just ignore this error now. Signed-off-by: Juergen Gross Which cases might we not have a control/shutdown node? Xenstore-stubdom. It should _never_ shutdown, and it isn't really under control of Xen tools (other than being created). I'm all for coping better with its absence, but it's not a piece of the Xen ABI which is optional. I'd like to differ here. See reasoning above. And on that front, not crashing is good, but why remove the watch? What if it comes into existence later? Is there any problem with just leaving the watch outstanding? A needless waste of memory in Xenstore-stubdom. Juergen OpenPGP_0xB0DE9DD628BF132F.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [PATCH 21/29] tools: tell xenstore-stubdom its own domid
On 01/11/2023 9:33 am, Juergen Gross wrote: > Pass the domid as a boot parameter when starting xenstore-stubdom. > It will be needed to administrate its own Xenstore entries. > > Signed-off-by: Juergen Gross I'm going to fix this differently. Because I'm utterly sick and tired of the absurd position at the moment where HVM guests can ask the hypervisor for their domid but PV cant. (Despite both being able to figure it out anyway through other information leaks in hypercalls.) The only reason I didn't nack the patch which created this problem to begin with was because it was part of the original Spectre/Meltdown work. ~Andrew
Re: [PATCH 2/3] Mini-OS: don't crash if no shutdown node is available
On 01/11/2023 4:42 pm, Juergen Gross wrote: > On 01.11.23 17:38, Andrew Cooper wrote: >> On 01/11/2023 9:00 am, Juergen Gross wrote: >>> 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 was taken. Just ignore this error now. >>> >>> Signed-off-by: Juergen Gross >> >> Which cases might we not have a control/shutdown node? > > Xenstore-stubdom. It should _never_ shutdown, and it isn't really under > control of Xen tools (other than being created). > >> I'm all for coping better with its absence, but it's not a piece of the >> Xen ABI which is optional. > > I'd like to differ here. See reasoning above. If we're going to permit this configuration, then I think it needs an extension to xenstore-paths to make it officially optional. And I think it's reasonable to support, but I wouldn't go as far as saying "never". If you've cleaved the global xenstored in twain/trine/etc, then individual parts of it can shut down normally. ~Andrew
[ovmf test] 183649: all pass - PUSHED
flight 183649 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/183649/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf fbbbd984998d83cf6b69e9291336aefbac23396c baseline version: ovmf 1b1509abee839b74d3232bbd6a256a1bdc230925 Last test of basis 183646 2023-11-01 03:11:04 Z0 days Testing same since 183649 2023-11-01 15:41:02 Z0 days1 attempts People who touched revisions under test: Sami Mujawar jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 1b1509abee..fbbbd98499 fbbbd984998d83cf6b69e9291336aefbac23396c -> xen-tested-master
[libvirt test] 183647: tolerable all pass - PUSHED
flight 183647 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/183647/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 183567 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 183567 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 183567 test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-qcow2 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-qcow2 15 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass version targeted for testing: libvirt fb9df5396098d4dc9b1566fc1656c5c8a3da8684 baseline version: libvirt 9ca910488cf43ffeb18116c76afd278d3d3cada4 Last test of basis 183567 2023-10-28 04:22:26 Z4 days Testing same since 183647 2023-11-01 04:18:50 Z0 days1 attempts People who touched revisions under test: Daniel P. Berrangé jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-arm64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-libvirt pass test-arm64-arm64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-libvirt-pairpass test-amd64-i386-libvirt-pair pass test-arm64-arm64-libvirt-qcow2 pass test-armhf-armhf-libvirt-qcow2 pass test-arm64-arm64-libvirt-raw pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-libvirt-raw pass test-amd64-amd64-libvirt-vhd pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is
[xen-unstable test] 183645: tolerable trouble: fail/pass/starved - PUSHED
flight 183645 xen-unstable real [real] flight 183650 xen-unstable real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/183645/ http://logs.test-lab.xenproject.org/osstest/logs/183650/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-vhd 13 guest-start fail pass in 183650-retest Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-vhd 14 migrate-support-check fail in 183650 never pass test-armhf-armhf-xl-vhd 15 saverestore-support-check fail in 183650 never pass test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 183640 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 183640 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 183640 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 183640 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 183640 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 183640 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 183640 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 183640 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 183640 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 183640 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 183640 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 183640 test-amd64-i386-xl-pvshim14 guest-start fail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-amd64-i386-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass test-amd64-amd64-dom0pvh-xl-amd 3 hosts-allocate starved n/a version targeted for testing: xen 7befef87cc9b1bb8ca15d866ce1ecd9165ccb58c baseline version: xen 9659b2a6d73b14620e1
Re: [PATCH 01/29] xen/public: add some more 9pfs xenstore paths
On Wed, Nov 1, 2023 at 7:24 AM Juergen Gross wrote: > > 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/io/9pfs.h b/xen/include/public/io/9pfs.h > index 9ad2773082..ac4bf0434b 100644 > --- a/xen/include/public/io/9pfs.h > +++ b/xen/include/public/io/9pfs.h > @@ -71,6 +71,40 @@ > * created on the guest (no user ownership squash or remap) > * Only "none" is supported in this version of the protocol. > * > + *max-files > + * Values: > + * > + * The maximum number of files (including directories) allowed for > + * this device. Backend support of this node is optional. If the node > + * is not present or the value is zero the number of files is not > + * limited. > + * > + *max-open-files > + * Values: > + * > + * The maximum number of files the guest is allowed to have opened > + * concurrently. Multiple concurrent opens of the same file are > counted > + * individually. Backend support of this node is optional. If the > node > + * is not present or the value is zero a backend specific default is > + * applied. > + * > + *max-space > + * Values: > + * > + * The maximum file space in MiBs the guest is allowed to use for > this > + * device. Backend support of this node is optional. If the node is > + * not present or the value is zero the space is not limited. > + * > + *auto-delete > + * Values: > + * > + * When set to "1" the backend will delete the file with the oldest > + * modification date below in case the allowed maximum file > + * space (see ) or file number (see ) is being > + * exceeded due to guest activity (creation or extension of files). > + * Files currently opened by the guest won't be deleted. Backend > + * support of this node is optional. > + * These seem reasonable, but it looks like xenlogd only implements max-open-files. They are all marked optional, so I guess it's okay to include them. Is there a plan to implement them? Maybe hold off until an implementation comes along? Regards, Jason
Re: [PATCH v8 8/8] xen/arm: mmu: move MMU specific P2M code to mmu/p2m.{c,h}
Hi Henry, On 23/10/2023 03:13, Henry Wang wrote: From: Penny Zheng Current P2M implementation is designed for MMU system only. We move the MMU-specific codes into mmu/p2m.c, and only keep generic codes in p2m.c, like VMID allocator, etc. We also move MMU-specific definitions and declarations to mmu/p2m.h, such as p2m_tlb_flush_sync(). Also expose previously static functions p2m_vmid_allocator_init(), p2m_alloc_vmid() for further MPU usage. Since with the code movement p2m_free_vmid() is now used in two files, also expose p2m_free_vmid(). With the code movement, global variable max_vmid is used in multiple files instead of a single file (and will be used in MPU P2M implementation), declare it in the header and remove the "static" of this variable. Also, since p2m_invalidate_root() should be MMU only and after the code movement the only caller of p2m_invalidate_root() outside of mmu/p2m.c is arch_domain_creation_finished(), creating a new function named p2m_domain_creation_finished() in mmu/p2m.c for the original code in arch_domain_creation_finished(), and marking p2m_invalidate_root() as static. Take the opportunity to fix the incorrect coding style when possible. When there is bit shift in macros, take the opportunity to add the missing 'U' as a compliance of MISRA. Signed-off-by: Penny Zheng Signed-off-by: Wei Chen Signed-off-by: Henry Wang Acked-by: Julien Grall I think the series is now fully acked. But I will wait for 4.18 to be released before merging this series. Please remind me in a couple of weeks time if I forgot to merge it. Cheers, -- Julien Grall
Re: [PATCH 02/29] tools: add a new xen logging daemon
On Wed, Nov 1, 2023 at 10:27 AM Juergen Gross wrote:
>
> Add "xenlogd", a new logging daemon meant to support infrastructure
> domains (e.g. xenstore-stubdom) to write log files in dom0.
As I understand it, your new daemon is a generic 9pfs backend, which
you use for logging. I think naming it something like xen9pfsd would
more accurately describe its functionality.
> For now only add the code needed for starting the daemon and
> registering it with Xenstore via a new "/tool/xenlog/state" node by
> writing the "running" state to it.
To support driver domain use cases, I think you want to use a relative
Xenstore path. While this daemon is independent from libxl, it might
be easiest to use "libxl/xenlog/" ("libxl/xen9pfs/") to take advantage
of driver domains having a read-write "libxl/" directory.
> Signed-off-by: Juergen Gross
The code looks good to me.
Regards,
Jason
Re: [PATCH v2 2/5] xen/arm: Add asm/domain.h include to kernel.h
Hi Luca, On 27/09/2023 15:01, Luca Fancellu wrote: The 'enum domain_type' is defined by 'asm/domain.h' which is not included (directly or indirectly) by 'asm/kernel.h'. This currently doesn't break the compilation because asm/domain.h will included by the user of 'kernel.h'. But it would be better to avoid relying on it. So add the include in 'asm/domain.h'. Signed-off-by: Luca Fancellu Acked-by: Julien Grall Cheers, -- Julien Grall
Re: [PATCH v2 3/5] arm/dom0less: put dom0less feature code in a separate module
Hi Luca,
On 27/09/2023 15:01, Luca Fancellu wrote:
Currently the dom0less feature code is mostly inside domain_build.c
and setup.c, it is a feature that may not be useful to everyone so
put the code in a different compilation module in order to make it
easier to disable the feature in the future.
Move gic_interrupt_t in domain_build.h to use it with the function
declaration, move its comment above the declaration.
The following functions are now visible externally from domain_build
because they are used also from the dom0less-build module:
- get_allocation_size
- set_interrupt
- domain_fdt_begin_node
- make_memory_node
- make_resv_memory_node
- make_hypervisor_node
- make_psci_node
- make_cpus_node
- make_timer_node
- handle_device_interrupts
- construct_domain
- process_shm
The functions allocate_static_memory and assign_static_memory_11
are now externally visible, so put their declarations into
domain_build.h and move the #else and stub definition in the header
as well.
Move is_dom0less_mode from setup.c to dom0less-build.c and make it
externally visible.
Where spotted, fix code style issues.
No functional change is intended.
Signed-off-by: Luca Fancellu
---
xen/arch/arm/Makefile |1 +
xen/arch/arm/dom0less-build.c | 1087 ++
xen/arch/arm/domain_build.c | 1276 ++---
xen/arch/arm/include/asm/dom0less-build.h | 25 +
xen/arch/arm/include/asm/domain_build.h | 58 +
xen/arch/arm/include/asm/setup.h |1 -
xen/arch/arm/setup.c | 33 +-
7 files changed, 1288 insertions(+), 1193 deletions(-)
create mode 100644 xen/arch/arm/dom0less-build.c
create mode 100644 xen/arch/arm/include/asm/dom0less-build.h
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 81c31c36fc3d..70dd7201ef30 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -15,6 +15,7 @@ obj-y += cpufeature.o
obj-y += decode.o
obj-y += device.o
obj-$(CONFIG_IOREQ_SERVER) += dm.o
+obj-y += dom0less-build.init.o
obj-y += domain.o
obj-y += domain_build.init.o
obj-$(CONFIG_ARCH_MAP_DOMAIN_PAGE) += domain_page.o
diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
new file mode 100644
index ..dc9c90cf00a7
--- /dev/null
+++ b/xen/arch/arm/dom0less-build.c
@@ -0,0 +1,1087 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * xen/arch/arm/dom0less-build.c
+ *
+ * Code related to the dom0less functionality
+ *
+ * Copyright (C) 2023 Arm Ltd.
This feels a bit odd to add your copyright here. It sounds like Arm
wrote all the code, but you only moved. That said, I am not a lawyer.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+bool __init is_dom0less_mode(void)
+{
+struct bootmodules *mods = &bootinfo.modules;
+struct bootmodule *mod;
+unsigned int i;
+bool dom0found = false;
+bool domUfound = false;
+
+/* Look into the bootmodules */
+for ( i = 0 ; i < mods->nr_mods ; i++ )
+{
+mod = &mods->module[i];
+/* Find if dom0 and domU kernels are present */
+if ( mod->kind == BOOTMOD_KERNEL )
+{
+if ( mod->domU == false )
+{
+dom0found = true;
+break;
+}
+else
+domUfound = true;
+}
+}
+
+/*
+ * If there is no dom0 kernel but at least one domU, then we are in
+ * dom0less mode
+ */
+return ( !dom0found && domUfound );
+}
+
+static bool __init allocate_bank_memory(struct domain *d,
+struct kernel_info *kinfo,
+gfn_t sgfn,
+paddr_t tot_size)
I understand that this is today only used by domUs. However, we could
technically use it for allocating dom0 memory if it is not 1:1.
So I think this function should stay in domain_build.c.
The rest of the code movement looks alright to me.
Cheers,
--
Julien Grall
[PATCH 0/2] x86/vmx: Multiple fixes
Fixes for two bugs initially reported to the Xen Security Team, but determined not have an impact in security-supported configurations. The Xen Security Team would like to thank Ishiisan for engaging in responsible disclsoure. As a reminder to the rest of the Xen community, please do ask you're not sure. Andrew Cooper (2): x86/vmx: Fix IRQ handling for EXIT_REASON_INIT x86/vmx: Disallow the use of inactivity states xen/arch/x86/hvm/vmx/vmx.c | 12 ++-- xen/arch/x86/hvm/vmx/vvmx.c | 9 +++-- xen/arch/x86/include/asm/hvm/hvm.h | 5 - xen/arch/x86/include/asm/hvm/vmx/vmcs.h | 1 + 4 files changed, 18 insertions(+), 9 deletions(-) -- 2.30.2
[PATCH 2/2] x86/vmx: Disallow the use of inactivity states
Right now, vvmx will blindly copy L12's ACTIVITY_STATE into the L02 VMCS and
enter the vCPU. Luckily for us, nested-virt is explicitly unsupported for
security bugs.
The inactivity states are HLT, SHUTDOWN and WAIT-FOR-SIPI, and as noted by the
SDM in Vol3 27.7 "Special Features of VM Entry":
If VM entry ends with the logical processor in an inactive activity state,
the VM entry generates any special bus cycle that is normally generated when
that activity state is entered from the active state.
Also,
Some activity states unconditionally block certain events.
I.e. A VMEntry with ACTIVITY=SHUTDOWN will initiate a platform reset, while a
VMEntry with ACTIVITY=WAIT-FOR-SIPI will really block everything other than
SIPIs.
Both of these activity states are for the TXT ACM to use, not for regular
hypervisors, and Xen doesn't support dropping the HLT intercept either.
There are two paths in Xen which operate on ACTIVITY_STATE.
1) The vmx_{get,set}_nonreg_state() helpers for VM-Fork.
As regular VMs can't use any inactivity states, this is just duplicating
the 0 from construct_vmcs(). Drop the field, leaving a comment as to why
it is skipped.
2) Nested virt, because of ACTIVITY_STATE in vmcs_gstate_field[].
Explicitly hide the inactivity states in the guest's view of MSR_VMX_MISC,
and remove ACTIVITY_STATE from vmcs_gstate_field[].
In virtual_vmentry(), we should trigger a VMEntry failure for the use of
any inactivity states, but there's no support for that in the code at all
so leave a TODO for when we finally start working on nested-virt in
earnest.
Reported-by: Reima ISHII
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
CC: Jun Nakajima
CC: Kevin Tian
CC: Tamas K Lengyel
CC: Reima ISHII
CC: Takahiro Shinagawa
Note, entirely untested.
---
xen/arch/x86/hvm/vmx/vmx.c | 2 --
xen/arch/x86/hvm/vmx/vvmx.c | 9 +++--
xen/arch/x86/include/asm/hvm/hvm.h | 5 -
xen/arch/x86/include/asm/hvm/vmx/vmcs.h | 1 +
4 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index d26920d03bbc..a35fb23b0ece 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -1543,7 +1543,6 @@ static void cf_check vmx_get_nonreg_state(struct vcpu *v,
{
vmx_vmcs_enter(v);
-__vmread(GUEST_ACTIVITY_STATE, &nrs->vmx.activity_state);
__vmread(GUEST_INTERRUPTIBILITY_INFO, &nrs->vmx.interruptibility_info);
__vmread(GUEST_PENDING_DBG_EXCEPTIONS, &nrs->vmx.pending_dbg);
@@ -1558,7 +1557,6 @@ static void cf_check vmx_set_nonreg_state(struct vcpu *v,
{
vmx_vmcs_enter(v);
-__vmwrite(GUEST_ACTIVITY_STATE, nrs->vmx.activity_state);
__vmwrite(GUEST_INTERRUPTIBILITY_INFO, nrs->vmx.interruptibility_info);
__vmwrite(GUEST_PENDING_DBG_EXCEPTIONS, nrs->vmx.pending_dbg);
diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index 16b0ef82b6c8..fd0ae3916656 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -899,7 +899,10 @@ static const u16 vmcs_gstate_field[] = {
GUEST_LDTR_AR_BYTES,
GUEST_TR_AR_BYTES,
GUEST_INTERRUPTIBILITY_INFO,
+/*
+ * ACTIVITY_STATE is handled specially.
GUEST_ACTIVITY_STATE,
+ */
GUEST_SYSENTER_CS,
GUEST_PREEMPTION_TIMER,
/* natural */
@@ -1200,6 +1203,8 @@ static void virtual_vmentry(struct cpu_user_regs *regs)
nvcpu->nv_vmentry_pending = 0;
nvcpu->nv_vmswitch_in_progress = 1;
+/* TODO: Fail VMentry for GUEST_ACTIVITY_STATE != 0 */
+
/*
* EFER handling:
* hvm_set_efer won't work if CR0.PG = 1, so we change the value
@@ -2316,8 +2321,8 @@ int nvmx_msr_read_intercept(unsigned int msr, u64
*msr_content)
data = hvm_cr4_guest_valid_bits(d);
break;
case MSR_IA32_VMX_MISC:
-/* Do not support CR3-target feature now */
-data = host_data & ~VMX_MISC_CR3_TARGET;
+/* Do not support CR3-targets or activity states. */
+data = host_data & ~(VMX_MISC_CR3_TARGET | VMX_MISC_ACTIVITY_MASK);
break;
case MSR_IA32_VMX_EPT_VPID_CAP:
data = nept_get_ept_vpid_cap();
diff --git a/xen/arch/x86/include/asm/hvm/hvm.h
b/xen/arch/x86/include/asm/hvm/hvm.h
index 6d53713fc3a9..caeb8ef4f596 100644
--- a/xen/arch/x86/include/asm/hvm/hvm.h
+++ b/xen/arch/x86/include/asm/hvm/hvm.h
@@ -78,7 +78,10 @@ enum hvm_intblk {
struct hvm_vcpu_nonreg_state {
union {
struct {
-uint64_t activity_state;
+/*
+ * ACTIVITY_STATE is part of VT-x's Non-Register state, but we
+ * don't support the use of any inactivity states.
+ */
uint64_t interruptibility_info;
uint64_t pending_dbg;
uint64_t interrupt_status;
diff --git a/xen/arch/x86/include/asm/hvm/vmx/vmcs.h
b/xen/arch/x86/include/asm/hvm/vmx/vmcs.h
index d07fcb2bc929..8de99
[PATCH 1/2] x86/vmx: Fix IRQ handling for EXIT_REASON_INIT
When receiving an INIT, a prior bugfix tried to ignore the INIT and continue
onwards.
Unfortunately it's not safe to return at that point in vmx_vmexit_handler().
Just out of context in the first hunk is a local_irqs_enabled() which is
depended-upon by the return-to-guest path, causing the following checklock
failure in debug builds:
(XEN) Error: INIT received - ignoring
(XEN) CHECKLOCK FAILURE: prev irqsafe: 0, curr irqsafe 1
(XEN) Xen BUG at common/spinlock.c:132
(XEN) [ Xen-4.19-unstable x86_64 debug=y Tainted: H ]
...
(XEN) Xen call trace:
(XEN)[] R check_lock+0xcd/0xe1
(XEN)[] F _spin_lock+0x1b/0x60
(XEN)[] F pt_update_irq+0x32/0x3bb
(XEN)[] F vmx_intr_assist+0x3b/0x51d
(XEN)[] F vmx_asm_vmexit_handler+0xf7/0x210
Luckily, this is benign in release builds. Accidentally having IRQs disabled
when trying to take an IRQs-on lock isn't a deadlock-vulnerable pattern.
Move the INIT handling into the main switch statement. In hindsight, it's
wrong to skip other normal VMExit steps.
Fixes: b1f11273d5a7 ("x86/vmx: Don't spuriously crash the domain when INIT is
received")
Reported-by: Reima ISHII
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
CC: Jun Nakajima
CC: Kevin Tian
CC: Tamas K Lengyel
CC: Reima ISHII
CC: Takahiro Shinagawa
With this patch in place, the INIT is ignored and the guest continues:
(XEN) HVM1 restore: CPU 0
(d1) --- Xen Test Framework ---
(d1) Environment: HVM 64bit (Long mode 4 levels)
(XEN) Error: INIT received - ignoring
(d1) Test result: SUCCESS
---
xen/arch/x86/hvm/vmx/vmx.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 1edc7f1e919f..d26920d03bbc 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -4097,10 +4097,6 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
case EXIT_REASON_MCE_DURING_VMENTRY:
do_machine_check(regs);
break;
-
-case EXIT_REASON_INIT:
-printk(XENLOG_ERR "Error: INIT received - ignoring\n");
-return; /* Renter the guest without further processing */
}
/* Now enable interrupts so it's safe to take locks. */
@@ -4390,6 +4386,12 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
case EXIT_REASON_TRIPLE_FAULT:
hvm_triple_fault();
break;
+
+case EXIT_REASON_INIT:
+/* TODO: Turn into graceful shutdown. */
+printk(XENLOG_ERR "Error: INIT received - ignoring\n");
+break;
+
case EXIT_REASON_PENDING_VIRT_INTR:
/* Disable the interrupt window. */
v->arch.hvm.vmx.exec_control &= ~CPU_BASED_VIRTUAL_INTR_PENDING;
--
2.30.2
Re: [PATCH 03/29] tools/xenlogd: connect to frontend
On Wed, Nov 1, 2023 at 5:34 AM Juergen Gross wrote:
>
> Add the code for connecting to frontends to xenlogd.
>
> Signed-off-by: Juergen Gross
> diff --git a/tools/xenlogd/xenlogd.c b/tools/xenlogd/xenlogd.c
> index 792d1026a3..da0a09a122 100644
> --- a/tools/xenlogd/xenlogd.c
> +++ b/tools/xenlogd/xenlogd.c
> +static void connect_device(device *device)
> +{
> +unsigned int val;
> +xenevtchn_port_or_error_t evtchn;
1.> +
> +val = read_frontend_node_uint(device, "version", 0);
> +if ( val != 1 )
> +return connect_err(device, "frontend specifies illegal version");
> +val = read_frontend_node_uint(device, "num-rings", 0);
> +if ( val != 1 )
> +return connect_err(device, "frontend specifies illegal ring number");
Linux uses 2 rings (XEN_9PFS_NUM_RINGS), and it doesn't connect when
max-rings is less than that.
max_rings = xenbus_read_unsigned(dev->otherend, "max-rings", 0);
if (max_rings < XEN_9PFS_NUM_RINGS)
return -EINVAL;
new_device() writes max-rings as 1. So this works for mini-os, but
not Linux. I'm not requesting you to change it - just noting it.
> +
> +val = read_frontend_node_uint(device, "event-channel-0", 0);
> +if ( val == 0 )
> +return connect_err(device, "frontend specifies illegal evtchn");
> +evtchn = xenevtchn_bind_interdomain(xe, device->domid, val);
> +if ( evtchn < 0 )
> +return connect_err(device, "could not bind to event channel");
> +device->evtchn = evtchn;
> +
> +val = read_frontend_node_uint(device, "ring-ref0", 0);
> +if ( val == 0 )
> +return connect_err(device, "frontend specifies illegal grant for
> ring");
> +device->intf = xengnttab_map_grant_ref(xg, device->domid, val,
> + PROT_READ | PROT_WRITE);
> +if ( !device->intf )
> +return connect_err(device, "could not map interface page");
> +device->ring_order = device->intf->ring_order;
> +if ( device->ring_order > 9 || device->ring_order < 1 )
> +return connect_err(device, "frontend specifies illegal ring order");
> +device->ring_size = XEN_FLEX_RING_SIZE(device->ring_order);
> +device->data.in = xengnttab_map_domain_grant_refs(xg,
> + 1 <<
> device->ring_order,
> + device->domid,
> + device->intf->ref,
> + PROT_READ |
> PROT_WRITE);
> +if ( !device->data.in )
> +return connect_err(device, "could not map ring pages");
> +device->data.out = device->data.in + device->ring_size;
> +
> +if ( pthread_create(&device->thread, NULL, io_thread, device) )
> + return connect_err(device, "could not start I/O thread");
> +device->thread_active = true;
> +
> +write_backend_state(device, XenbusStateConnected);
> +}
> +
> @@ -122,6 +669,11 @@ int main(int argc, char *argv[])
> int syslog_mask = LOG_MASK(LOG_WARNING) | LOG_MASK(LOG_ERR) |
>LOG_MASK(LOG_CRIT) | LOG_MASK(LOG_ALERT) |
>LOG_MASK(LOG_EMERG);
> +char **watch;
> +struct pollfd p[2] = {
> +{ .events = POLLIN, .revents = POLLIN },
Are you intentionally setting revents to enter the loop initially?
Shouldn't the watch registration trigger it to fire anyway?
> +{ .events = POLLIN }
> +};
>
> umask(027);
> if ( getenv("XENLOGD_VERBOSE") )
> @@ -134,9 +686,26 @@ int main(int argc, char *argv[])
>
> xen_connect();
>
> +if ( !xs_watch(xs, "backend/xen_9pfs", "main") )
> +do_err("xs_watch() in main thread failed");
> +p[0].fd = xs_fileno(xs);
> +p[1].fd = xenevtchn_fd(xe);
> +
> +scan_backend();
> +
> while ( !stop_me )
> {
> -sleep(60);
> +while ( (p[0].revents & POLLIN) &&
> +(watch = xs_check_watch(xs)) != NULL )
> +{
> +handle_watch(watch[XS_WATCH_PATH], watch[XS_WATCH_TOKEN]);
> +free(watch);
> +}
> +
> +if ( p[1].revents & POLLIN )
> +handle_event();
> +
> +poll(p, 2, 1);
Can you just use an infinite timeout and rely on the signal
interrupting the system call?
Regards,
Jason
[PATCH for-4.18] x86/time: Fix UBSAN failure in __update_vcpu_system_time()
As reported:
(XEN)
(XEN) UBSAN: Undefined behaviour in arch/x86/time.c:1542:32
(XEN) member access within null pointer of type 'union vcpu_info_t'
(XEN) [ Xen-4.19-unstable x86_64 debug=y ubsan=y Not tainted ]
...
(XEN) Xen call trace:
(XEN)[] R common/ubsan/ubsan.c#ubsan_epilogue+0xa/0xd2
(XEN)[] F __ubsan_handle_type_mismatch+0x133/0x49b
(XEN)[] F __ubsan_handle_type_mismatch_v1+0xfa/0xfc
(XEN)[] F
arch/x86/time.c#__update_vcpu_system_time+0x212/0x30f
(XEN)[] F update_vcpu_system_time+0xe/0x10
(XEN)[] F
arch/x86/time.c#local_time_calibration+0x1f7/0x523
(XEN)[] F common/softirq.c#__do_softirq+0x1f4/0x31a
(XEN)[] F do_softirq+0x13/0x15
(XEN)[] F arch/x86/domain.c#idle_loop+0x2e0/0x367
(XEN)
(XEN)
It is not valid to derive a pointer from vcpu_info() prior to checking that
the underlying map pointer is good.
Reorder actions so the NULL pointer check is first.
Fixes: 20279afd7323 ("x86: split populating of struct vcpu_time_info into a
separate function")
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
CC: Henry Wang
4.18 blocker, or we'll need to issue an XSA/CVE.
---
xen/arch/x86/time.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
index d0b0986509b2..6d33edd0addc 100644
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -1539,12 +1539,14 @@ static void collect_time_info(const struct vcpu *v,
static void __update_vcpu_system_time(struct vcpu *v, int force)
{
-struct vcpu_time_info *u = &vcpu_info(v, time), _u;
+struct vcpu_time_info *u, _u;
const struct domain *d = v->domain;
if ( !v->vcpu_info_area.map )
return;
+u = &vcpu_info(v, time);
+
collect_time_info(v, &_u);
/* Don't bother unless timestamp record has changed or we are forced. */
base-commit: 7befef87cc9b1bb8ca15d866ce1ecd9165ccb58c
--
2.30.2
Re: [GIT PULL] xen: branch for v6.7-rc1
The pull request you sent on Sat, 28 Oct 2023 17:55:24 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git > for-linus-6.7-rc1-tag has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/ca995ce438cc641c47d4b8e4abeb1878a3d07c5f Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
[QEMU][PATCH v1] Xen: Fix xen_set_irq() and xendevicemodel_set_irq_level()
Remove '=' from 'if CONFIG_XEN_CTRL_INTERFACE_VERSION <= 41500'.
Because xendevicemodel_set_irq_level() was introduced in 4.15 version.
Also, update xendevicemodel_set_irq_level() to return -1 for older versions.
Signed-off-by: Vikram Garhwal
---
hw/arm/xen_arm.c| 4 +++-
include/hw/xen/xen_native.h | 4 ++--
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/hw/arm/xen_arm.c b/hw/arm/xen_arm.c
index f83b983ec5..a5631529d0 100644
--- a/hw/arm/xen_arm.c
+++ b/hw/arm/xen_arm.c
@@ -75,7 +75,9 @@ static MemoryRegion ram_lo, ram_hi;
static void xen_set_irq(void *opaque, int irq, int level)
{
-xendevicemodel_set_irq_level(xen_dmod, xen_domid, irq, level);
+if (xendevicemodel_set_irq_level(xen_dmod, xen_domid, irq, level)) {
+error_report("xendevicemodel_set_irq_level failed");
+}
}
static void xen_create_virtio_mmio_devices(XenArmState *xam)
diff --git a/include/hw/xen/xen_native.h b/include/hw/xen/xen_native.h
index 5d2718261f..6f09c48823 100644
--- a/include/hw/xen/xen_native.h
+++ b/include/hw/xen/xen_native.h
@@ -523,12 +523,12 @@ static inline int xen_set_ioreq_server_state(domid_t dom,
enable);
}
-#if CONFIG_XEN_CTRL_INTERFACE_VERSION <= 41500
+#if CONFIG_XEN_CTRL_INTERFACE_VERSION < 41500
static inline int xendevicemodel_set_irq_level(xendevicemodel_handle *dmod,
domid_t domid, uint32_t irq,
unsigned int level)
{
-return 0;
+return -1;
}
#endif
--
2.17.1
Re: [XEN PATCH][for-4.19 v6 2/8] x86: add deviation for asm-only functions
On Wed, 1 Nov 2023, Nicola Vetrini wrote:
> As stated in rules.rst, functions used only in asm modules
> are allowed to have no prior declaration visible when being
> defined, hence these functions are marked with an
> 'asmlinkage' macro, which is then deviated for MISRA C:2012
> Rule 8.4.
>
> Signed-off-by: Nicola Vetrini
> ---
> Changes in v3:
> - added SAF deviations for vmx counterparts to svm functions.
> Changes in v5:
> - drop SAF deviations in favour of the pseudo-attribute asmlinkage
> Changes in v6:
> - conditioned asmlinkage definition to make it overridable;
> - move the pseudo-attribute after the return type
> ---
> automation/eclair_analysis/ECLAIR/deviations.ecl | 9 +
> docs/misra/deviations.rst| 6 ++
> xen/arch/x86/hvm/svm/intr.c | 2 +-
> xen/arch/x86/hvm/svm/nestedsvm.c | 2 +-
> xen/arch/x86/hvm/svm/svm.c | 4 ++--
> xen/arch/x86/hvm/vmx/intr.c | 2 +-
> xen/arch/x86/hvm/vmx/vmx.c | 4 ++--
> xen/arch/x86/hvm/vmx/vvmx.c | 2 +-
> xen/arch/x86/traps.c | 2 +-
> xen/arch/x86/x86_64/traps.c | 2 +-
> xen/include/xen/compiler.h | 5 +
> 11 files changed, 30 insertions(+), 10 deletions(-)
>
> diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl
> b/automation/eclair_analysis/ECLAIR/deviations.ecl
> index fa56e5c00a27..06619ecf7e8d 100644
> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> @@ -163,6 +163,15 @@ Therefore the absence of prior declarations is safe."
> -config=MC3R1.R8.4,reports+={safe, "first_area(any_loc(file(gcov)))"}
> -doc_end
>
> +-doc_begin="Recognize the occurrence of current_stack_pointer as a
> declaration."
> +-file_tag+={asm_defns, "^xen/arch/x86/include/asm/asm_defns\\.h$"}
> +-config=MC3R1.R8.4,declarations+={safe,
> "loc(file(asm_defns))&&^current_stack_pointer$"}
> +-doc_end
> +
> +-doc_begin="asmlinkage is a marker to indicate that the function is only
> used to interface with asm modules."
> +-config=MC3R1.R8.4,declarations+={safe,"loc(text(^(?s).*asmlinkage.*$,
> -1..0))"}
> +-doc_end
> +
> -doc_begin="The following variables are compiled in multiple translation
> units
> belonging to different executables and therefore are safe."
> -config=MC3R1.R8.6,declarations+={safe,
> "name(current_stack_pointer||bsearch||sort)"}
> diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
> index 8511a189253b..d468da2f5ce9 100644
> --- a/docs/misra/deviations.rst
> +++ b/docs/misra/deviations.rst
> @@ -133,6 +133,12 @@ Deviations related to MISRA C:2012 Rules:
> configuration. Therefore, the absence of prior declarations is safe.
> - Tagged as `safe` for ECLAIR.
>
> + * - R8.4
> + - Functions and variables used only by asm modules are either marked
> with
> + the `asmlinkage` macro or with a SAF-1-safe textual deviation
> + (see safe.json).
> + - Tagged as `safe` for ECLAIR.
Reviewed-by: Stefano Stabellini
If Julien prefers a different wording I could modify on commit as needed
> * - R8.6
> - The following variables are compiled in multiple translation units
> belonging to different executables and therefore are safe.
> diff --git a/xen/arch/x86/hvm/svm/intr.c b/xen/arch/x86/hvm/svm/intr.c
> index 192e17ebbfbb..4805c5567213 100644
> --- a/xen/arch/x86/hvm/svm/intr.c
> +++ b/xen/arch/x86/hvm/svm/intr.c
> @@ -123,7 +123,7 @@ static void svm_enable_intr_window(struct vcpu *v, struct
> hvm_intack intack)
> vmcb, general1_intercepts | GENERAL1_INTERCEPT_VINTR);
> }
>
> -void svm_intr_assist(void)
> +void asmlinkage svm_intr_assist(void)
> {
> struct vcpu *v = current;
> struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb;
> diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c
> b/xen/arch/x86/hvm/svm/nestedsvm.c
> index a09b6abaaeaf..fc7658d67d4e 100644
> --- a/xen/arch/x86/hvm/svm/nestedsvm.c
> +++ b/xen/arch/x86/hvm/svm/nestedsvm.c
> @@ -1441,7 +1441,7 @@ nestedsvm_vcpu_vmexit(struct vcpu *v, struct
> cpu_user_regs *regs,
> }
>
> /* VCPU switch */
> -void nsvm_vcpu_switch(void)
> +void asmlinkage nsvm_vcpu_switch(void)
> {
> struct cpu_user_regs *regs = guest_cpu_user_regs();
> struct vcpu *v = current;
> diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
> index 24c417ca7199..cb8abe7a0066 100644
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -1056,7 +1056,7 @@ static void noreturn cf_check svm_do_resume(void)
> reset_stack_and_jump(svm_asm_do_resume);
> }
>
> -void svm_vmenter_helper(void)
> +void asmlinkage svm_vmenter_helper(void)
> {
> const struct cpu_user_regs *regs = guest_cpu_user_regs();
> struct vcpu *curr = current;
> @@ -2586,7 +2586,7 @@ const struct hvm_function_table * __init s
Re: [XEN PATCH][for-4.19 v6 3/8] x86: add asmlinkage macro to variables only used in asm code
On Wed, 1 Nov 2023, Nicola Vetrini wrote: > To avoid a violation of MISRA C:2012 Rule 8.4, as permitted > by docs/misra/rules.rst. > > The current_stack_pointer is a declaration: mark it as such > for ECLAIR. > > Signed-off-by: Nicola Vetrini Reviewed-by: Stefano Stabellini
Re: Imagebuilder can't compute correctly the memory addresses of our images
Hi Mario, Replies inline below On Wed, 1 Nov 2023, Mario Marietto wrote: > Hello to everyone. > > We are a team of linux enthusiasts who are trying to boot Xen on a Samsung > XE303C12 Chromebook aka "snow" , following the suggestions in > the slide show presentation here: > > https://www.slideshare.net/xen_com_mgr/xpds16-porting-xen-on-arm-to-a-new-soc-julien-grall-arm > > This device uses an exynos5250 SOC dual core 1.7 GHz with 2 MB RAM, it is > a Samsung armv7 chip with virtualization extensions. > > In particular, we have it working fairly well both on the bare metal with > a recent 6.1.59 Linux LTS kernel and also with a recent 5.4.257 LTS > kernel with KVM, the older LTS kernel version is used to test KVM because > support for KVM on arm v7 was removed from Linux around kernel version > 5.7. So we know we have the hypervisor mode enabled because we were able > to use it with KVM. > > For Xen, we are using the latest Debian build of Xen 4.17 for the Debian > armhf architecture: > > (XEN) Xen version 4.17.2-pre (Debian 4.17.1+2-gb773c48e36-1) > (pkg-xen-devel@xxx) (arm-linux-gnueabihf-gcc (Debian > 12.2.0-14) 12.2.0) debug=n Thu May 18 19:26:30 UTC 2023 > > The Linux kernel is a custom build that adds the Xen config kernel > options (CONFIG_XEN_DOM0, etc) on top of a kernel that works well on the > same Chromebook model on the bare metal. > > Our method of booting is to have u-boot boot the Xen hypervisor and load > the device tree after adding the dom0 to the otherwise unaltered device > tree from the Linux kernel using u-boot fdt commands to add a /chosen > node, as described on the Xen wiki and in the pages linked from there. We > have also tried adding and loading an initrd.img using the device tree > /chosen node but that made no difference in our tests. > > The workflow is the following : > > a) let's create the file xen-config-6.1.59 : > > MEMORY_START="0x0" > MEMORY_END="0x8000" > LOAD_CMD="ext2load mmc 1:3" > BOOT_CMD="bootm" > DEVICE_TREE="exynos5250-snow-6.1.59-stb-xen-cbe+.dtb" > XEN="xen-4.17-armhf" > XEN_CMD="console=dtuart dtuart=serial0 dom0_mem=1G dom0_max_vcpus=2 > bootscrub=0 vwfi=native sched=null" > DOM0_KERNEL="zImage-6.1.59-xen-mixer-off" > DOM0_CMD="console=tty earlycon=xen earlyprintk=xen root=/dev/mmcblk1p4 rw > rootwait clk_ignore_unused" > UBOOT_SOURCE="xen.source" > UBOOT_SCRIPT="xen.scr" > > b) let's create gen-script.sh : > > bash ./uboot-script-gen -c xen-config-6.1.59 -d . > > c) let's run the script gen-script.sh : > > # ./gen-script > > Image Name: > Created: Wed Nov 1 14:34:23 2023 > Image Type: ARM Linux Kernel Image (uncompressed) > Data Size: 884744 Bytes = 864.01 KiB = 0.84 MiB > Load Address: 0180 > Entry Point: 0180 > Generated uboot script xen.scr, to be loaded at address 0xC0: > ext2load mmc 1:3 0xC0 xen.scr; source 0xC0 This step is confusing: step b) should directly generate xen.scr. There is no ./gen-script to run. > d) let's give a look inside the file xen.scr because we need some memory > address that it has generated : > > > ext2load mmc 1:3 0x180 xen-4.17-armhf.ub > ext2load mmc 1:3 0x1A0 exynos5250-snow-6.1.59-stb-xen-cbe+.dtb Here the Dom0 kernel is missing? > fdt addr 0x1A0 > fdt resize 1024 > fdt set /chosen \#address-cells <0x2> > fdt set /chosen \#size-cells <0x2> > fdt set /chosen xen,xen-bootargs "console=dtuart dtuart=serial0 dom0_mem=1G > dom0_max_vcpus=2 bootscrub=0 vwfi=native sched=null" > fdt mknod /chosen dom0 > fdt set /chosen/dom0 compatible "xen,linux-zimage" "xen,multiboot-module" > "multiboot,module" > fdt set /chosen/dom0 reg <0x0 0xE0 0x0 0x816110 > > fdt set /chosen xen,dom0-bootargs "console=tty earlycon=xen earlyprintk=xen > root=/dev/mmcblk1p4 rw rootwait clk_ignore_unused" > setenv fdt_high 0x > bootm 0x180 - 0x1A0 > > As you can see it has generated a lot of interesting memory addresses,but > unfortunately they are all wrong,except for one,this : > > 0x816110 > > This is well calculated. What do you mean they are wrong? Which ones are wrong? Imagebuilder will pick addresses 2MB aligned starting from a 2MB offset from MEMORY_START. So both 0x180 and 0x1A0 should be good addresses because they are in the MEMORY_START-MEMORY_END range. There is one issue though: the dom0 kernel address 0xE0 is not present among the loading commands. > e) let's write this template,called "bootxen.source" : > > mmc dev 1 > ext2load mmc 1:3 0x4200 zImage-6.1.59-xen-mixer-off > ext2load mmc 1:3 0x5100 xen-4.17-armhf-armmp-0x51004000.ub > ext2load mmc 1:3 0x5ffec000 exynos5250-snow-6.1.59-stb-xen-cbe+.dtb > fdt addr 0x5ffec000 > fdt resize 1024 > fdt set /chosen \#address-cells <0x2> > fdt set /chosen \#size-cells <0x2> > fdt set /chosen xen,xen-bootargs "console=dtuart dtuart=serial0 dom0_mem=1G > dom0_max_vcpus=2 bootscrub=0 vwfi=native sched=null" > fdt mknod /chosen dom0 > fdt
[PATCH 1/2] xen/arm32: head: Rework how the fixmap and early UART mapping are prepared
From: Julien Grall
Since commit 5e213f0f4d2c ("xen/arm32: head: Widen the use of the
temporary mapping"), boot_second (used to cover regions like Xen and
the fixmap) will not be mapped if the identity mapping overlap.
So it is ok to prepare the fixmap table and link it in boot_second
earlier. With that, the fixmap can also be used earlier via the
temporary mapping.
Therefore split setup_fixmap() in two:
* The table is now linked in create_page_tables() because
the boot page tables needs to be recreated for every CPU.
* The early UART mapping is only added for the boot CPU0 as the
fixmap table is not cleared when secondary CPUs boot.
Signed-off-by: Julien Grall
---
xen/arch/arm/arm32/head.S | 48 ---
1 file changed, 9 insertions(+), 39 deletions(-)
diff --git a/xen/arch/arm/arm32/head.S b/xen/arch/arm/arm32/head.S
index 33b038e7e0ca..fec2433e568f 100644
--- a/xen/arch/arm/arm32/head.S
+++ b/xen/arch/arm/arm32/head.S
@@ -183,12 +183,16 @@ past_zImage:
blcheck_cpu_mode
blcpu_init
blcreate_page_tables
+/* Add the UART mapping if requested */
+#ifdef CONFIG_EARLY_PRINTK
+mov_w r0, EARLY_UART_VIRTUAL_ADDRESS
+create_mapping_entry xen_fixmap, r0, r11, type=PT_DEV_L3
+#endif
/* Address in the runtime mapping to jump to after the MMU is enabled
*/
mov_w lr, primary_switched
b enable_mmu
primary_switched:
-blsetup_fixmap
#ifdef CONFIG_EARLY_PRINTK
/* Use a virtual address to access the UART. */
mov_w r11, EARLY_UART_VIRTUAL_ADDRESS
@@ -456,11 +460,6 @@ ENDPROC(cpu_init)
* Rebuild the boot pagetable's first-level entries. The structure
* is described in mm.c.
*
- * After the CPU enables paging it will add the fixmap mapping
- * to these page tables, however this may clash with the 1:1
- * mapping. So each CPU must rebuild the page tables here with
- * the 1:1 in place.
- *
* Inputs:
* r9 : paddr(start)
* r10: phys offset
@@ -488,6 +487,10 @@ create_page_tables:
add r5, r5, #PAGE_SIZE/* r5 := Next table */
.endr
+/* Map the fixmap into boot_second */
+mov_w r0, FIXMAP_ADDR(0)
+create_table_entry boot_second, xen_fixmap, r0, 2
+
/*
* Find the size of Xen in pages and multiply by the size of a
* PTE. This will then be compared in the mapping loop below.
@@ -718,39 +721,6 @@ remove_temporary_mapping:
mov pc, lr
ENDPROC(remove_temporary_mapping)
-/*
- * Map the UART in the fixmap (when earlyprintk is used) and hook the
- * fixmap table in the page tables.
- *
- * The fixmap cannot be mapped in create_page_tables because it may
- * clash with the 1:1 mapping.
- *
- * Inputs:
- * r10: Physical offset
- * r11: Early UART base physical address
- *
- * Clobbers r0 - r4
- */
-setup_fixmap:
-#if defined(CONFIG_EARLY_PRINTK)
-/* Add UART to the fixmap table */
-mov_w r0, EARLY_UART_VIRTUAL_ADDRESS
-create_mapping_entry xen_fixmap, r0, r11, type=PT_DEV_L3
-#endif
-/* Map fixmap into boot_second */
-mov_w r0, FIXMAP_ADDR(0)
-create_table_entry boot_second, xen_fixmap, r0, 2
-/* Ensure any page table updates made above have occurred. */
-dsb nshst
-/*
- * The fixmap area will be used soon after. So ensure no hardware
- * translation happens before the dsb completes.
- */
-isb
-
-mov pc, lr
-ENDPROC(setup_fixmap)
-
/*
* Setup the initial stack and jump to the C world
*
--
2.40.1
[PATCH 2/2] xen/arm32: head: Improve logging in head.S
From: Julien Grall
The sequence to enable the MMU on arm32 is quite complex as we may need
to jump to a temporary mapping to map Xen.
Recently, we had one bug in the logic (see f5a49eb7f8b3 ("xen/arm32:
head: Add mising isb in switch_to_runtime_mapping()") and it was
a pain to debug because there are no logging.
In order to improve the logging in the MMU switch we need to add
support for early printk while running on the identity mapping
and also on the temporary mapping.
For the identity mapping, we have only the first page of Xen mapped.
So all the strings should reside in the first page. For that purpose
a new macro PRINT_ID is introduced.
For the temporary mapping, the fixmap is already linked the temporary
area (and so does the UART). So we just need to update the register
storing the UART address (i.e. r11) to point to the UART temporary
mapping.
Take the opportunity to introduce mov_w_on_cond in order to
conditionally execute mov_w and avoid branches.
Signed-off-by: Julien Grall
---
xen/arch/arm/arm32/head.S | 68 -
xen/arch/arm/include/asm/asm_defns.h| 6 ++-
xen/arch/arm/include/asm/early_printk.h | 3 ++
xen/arch/arm/include/asm/mmu/layout.h | 4 ++
xen/arch/arm/mm.c | 5 ++
xen/arch/arm/xen.lds.S | 1 +
6 files changed, 71 insertions(+), 16 deletions(-)
diff --git a/xen/arch/arm/arm32/head.S b/xen/arch/arm/arm32/head.S
index fec2433e568f..bd61521a9dea 100644
--- a/xen/arch/arm/arm32/head.S
+++ b/xen/arch/arm/arm32/head.S
@@ -46,9 +46,13 @@
* Move an immediate constant into a 32-bit register using movw/movt
* instructions.
*/
+.macro mov_w_on_cond cond, reg, word
+movw\cond \reg, #:lower16:\word
+movt\cond \reg, #:upper16:\word
+.endm
+
.macro mov_w reg, word
-movw \reg, #:lower16:\word
-movt \reg, #:upper16:\word
+mov_w_on_cond al, \reg, \word
.endm
/*
@@ -104,16 +108,26 @@
*/
#ifdef CONFIG_EARLY_PRINTK
/*
- * Macro to print a string to the UART, if there is one.
+ * Macros to print a string to the UART, if there is one.
+ *
+ * There are multiple flavors:
+ * - PRINT_SECT(section, string): The @string will be located in @section
+ * - PRINT(): The string will be located in .rodata.str.
+ * - PRINT_ID(): When Xen is running on the Identity Mapping, it is
+ *only possible to have a limited amount of Xen. This will create
+ *the string in .rodata.idmap which will always be mapped.
*
* Clobbers r0 - r3
*/
-#define PRINT(_s) \
-mov r3, lr ;\
-adr_l r0, 98f ;\
-blputs ;\
-mov lr, r3 ;\
-RODATA_STR(98, _s)
+#define PRINT_SECT(section, string) \
+mov r3, lr ;\
+adr_l r0, 98f ;\
+blputs ;\
+mov lr, r3 ;\
+RODATA_SECT(section, 98, string)
+
+#define PRINT(string) PRINT_SECT(.rodata.str, string)
+#define PRINT_ID(string) PRINT_SECT(.rodata.idmap, string)
/*
* Macro to print the value of register \rb
@@ -129,6 +143,7 @@
#else /* CONFIG_EARLY_PRINTK */
#define PRINT(s)
+#define PRINT_ID(s)
.macro print_reg rb
.endm
@@ -183,11 +198,6 @@ past_zImage:
blcheck_cpu_mode
blcpu_init
blcreate_page_tables
-/* Add the UART mapping if requested */
-#ifdef CONFIG_EARLY_PRINTK
-mov_w r0, EARLY_UART_VIRTUAL_ADDRESS
-create_mapping_entry xen_fixmap, r0, r11, type=PT_DEV_L3
-#endif
/* Address in the runtime mapping to jump to after the MMU is enabled
*/
mov_w lr, primary_switched
@@ -593,6 +603,21 @@ enable_mmu:
mcr CP32(r0, HSCTLR) /* now paging is enabled */
isb /* Now, flush the icache */
+/*
+ * At this stage, the UART address will depend on whether the
+ * temporary mapping was created or not.
+ *
+ * If it was, then the UART will be mapped in the temporary
+ * area. Otherwise, it will be mapped at runtime virtual
+ * mapping.
+ */
+#ifdef CONFIG_EARLY_PRINTK
+teq r12, #1 /* Was the temporary mapping created? */
+mov_w_on_cond eq, r11, TEMPORARY_EARLY_UART_VIRTUAL_ADDRESS
+mov_w_on_cond ne, r11, EARLY_UART_VIRTUAL_ADDRESS
+#endif
+PRINT_ID("- Paging turned on -\r\n")
+
/*
* The MMU is turned on and we are in the 1:1 mapping. Switch
* to the runtime mapping.
@@ -643,12 +668,14 @@ switch_to_runtime_mapping:
teq r12, #0
beq ready_to_switch
+PRINT_ID("- Switching to the temporary mapping -\r\n")
/* We are still in the 1:1 mapping. Jump to the temporary Virtual
address. */
mov_w r0, 1f
add r0, r0, #XEN_TEMPORARY_OFFSET /* r0 := address in temporary
mapping */
mov pc, r0
[PATCH 0/2] xen/arm32: Improve logging during early boot
From: Julien Grall
Hi all,
This small series is based on some debugging I added while investigating
f5a49eb7f8b3 ("xen/arm32: head: Add mising isb in
switch_to_runtime_mapping()").
This will make easier to narrow down where the CPU is stuck while
enabling the MMU.
Julien Grall (2):
xen/arm32: head: Rework how the fixmap and early UART mapping are
prepared
xen/arm32: head: Improve logging in head.S
xen/arch/arm/arm32/head.S | 106 +---
xen/arch/arm/include/asm/asm_defns.h| 6 +-
xen/arch/arm/include/asm/early_printk.h | 3 +
xen/arch/arm/include/asm/mmu/layout.h | 4 +
xen/arch/arm/mm.c | 5 ++
xen/arch/arm/xen.lds.S | 1 +
6 files changed, 75 insertions(+), 50 deletions(-)
--
2.40.1
Re: [QEMU][PATCH v1] Xen: Fix xen_set_irq() and xendevicemodel_set_irq_level()
On Wed, 1 Nov 2023, Vikram Garhwal wrote:
> Remove '=' from 'if CONFIG_XEN_CTRL_INTERFACE_VERSION <= 41500'.
> Because xendevicemodel_set_irq_level() was introduced in 4.15 version.
>
> Also, update xendevicemodel_set_irq_level() to return -1 for older versions.
>
> Signed-off-by: Vikram Garhwal
Reviewed-by: Stefano Stabellini
> ---
> hw/arm/xen_arm.c| 4 +++-
> include/hw/xen/xen_native.h | 4 ++--
> 2 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/hw/arm/xen_arm.c b/hw/arm/xen_arm.c
> index f83b983ec5..a5631529d0 100644
> --- a/hw/arm/xen_arm.c
> +++ b/hw/arm/xen_arm.c
> @@ -75,7 +75,9 @@ static MemoryRegion ram_lo, ram_hi;
>
> static void xen_set_irq(void *opaque, int irq, int level)
> {
> -xendevicemodel_set_irq_level(xen_dmod, xen_domid, irq, level);
> +if (xendevicemodel_set_irq_level(xen_dmod, xen_domid, irq, level)) {
> +error_report("xendevicemodel_set_irq_level failed");
> +}
> }
>
> static void xen_create_virtio_mmio_devices(XenArmState *xam)
> diff --git a/include/hw/xen/xen_native.h b/include/hw/xen/xen_native.h
> index 5d2718261f..6f09c48823 100644
> --- a/include/hw/xen/xen_native.h
> +++ b/include/hw/xen/xen_native.h
> @@ -523,12 +523,12 @@ static inline int xen_set_ioreq_server_state(domid_t
> dom,
> enable);
> }
>
> -#if CONFIG_XEN_CTRL_INTERFACE_VERSION <= 41500
> +#if CONFIG_XEN_CTRL_INTERFACE_VERSION < 41500
> static inline int xendevicemodel_set_irq_level(xendevicemodel_handle *dmod,
> domid_t domid, uint32_t irq,
> unsigned int level)
> {
> -return 0;
> +return -1;
> }
> #endif
>
> --
> 2.17.1
>
Re: [XEN PATCH][for-4.19 v6 2/8] x86: add deviation for asm-only functions
Hi Stefano,
On 01/11/2023 23:10, Stefano Stabellini wrote:
On Wed, 1 Nov 2023, Nicola Vetrini wrote:
As stated in rules.rst, functions used only in asm modules
are allowed to have no prior declaration visible when being
defined, hence these functions are marked with an
'asmlinkage' macro, which is then deviated for MISRA C:2012
Rule 8.4.
Signed-off-by: Nicola Vetrini
---
Changes in v3:
- added SAF deviations for vmx counterparts to svm functions.
Changes in v5:
- drop SAF deviations in favour of the pseudo-attribute asmlinkage
Changes in v6:
- conditioned asmlinkage definition to make it overridable;
- move the pseudo-attribute after the return type
---
automation/eclair_analysis/ECLAIR/deviations.ecl | 9 +
docs/misra/deviations.rst| 6 ++
xen/arch/x86/hvm/svm/intr.c | 2 +-
xen/arch/x86/hvm/svm/nestedsvm.c | 2 +-
xen/arch/x86/hvm/svm/svm.c | 4 ++--
xen/arch/x86/hvm/vmx/intr.c | 2 +-
xen/arch/x86/hvm/vmx/vmx.c | 4 ++--
xen/arch/x86/hvm/vmx/vvmx.c | 2 +-
xen/arch/x86/traps.c | 2 +-
xen/arch/x86/x86_64/traps.c | 2 +-
xen/include/xen/compiler.h | 5 +
11 files changed, 30 insertions(+), 10 deletions(-)
diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl
b/automation/eclair_analysis/ECLAIR/deviations.ecl
index fa56e5c00a27..06619ecf7e8d 100644
--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
+++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
@@ -163,6 +163,15 @@ Therefore the absence of prior declarations is safe."
-config=MC3R1.R8.4,reports+={safe, "first_area(any_loc(file(gcov)))"}
-doc_end
+-doc_begin="Recognize the occurrence of current_stack_pointer as a declaration."
+-file_tag+={asm_defns, "^xen/arch/x86/include/asm/asm_defns\\.h$"}
+-config=MC3R1.R8.4,declarations+={safe,
"loc(file(asm_defns))&&^current_stack_pointer$"}
+-doc_end
+
+-doc_begin="asmlinkage is a marker to indicate that the function is only used to
interface with asm modules."
+-config=MC3R1.R8.4,declarations+={safe,"loc(text(^(?s).*asmlinkage.*$,
-1..0))"}
+-doc_end
+
-doc_begin="The following variables are compiled in multiple translation units
belonging to different executables and therefore are safe."
-config=MC3R1.R8.6,declarations+={safe,
"name(current_stack_pointer||bsearch||sort)"}
diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
index 8511a189253b..d468da2f5ce9 100644
--- a/docs/misra/deviations.rst
+++ b/docs/misra/deviations.rst
@@ -133,6 +133,12 @@ Deviations related to MISRA C:2012 Rules:
configuration. Therefore, the absence of prior declarations is safe.
- Tagged as `safe` for ECLAIR.
+ * - R8.4
+ - Functions and variables used only by asm modules are either marked with
+ the `asmlinkage` macro or with a SAF-1-safe textual deviation
+ (see safe.json).
+ - Tagged as `safe` for ECLAIR.
Reviewed-by: Stefano Stabellini
If Julien prefers a different wording I could modify on commit as needed
I think my comment on the previous version was misunderstood. I have
asked to replace all SAF-1 with asmlinkage and I thought you agreed with
that.
This is a similar situation to octal-ok. I don't think it is right to
have multiple ways to tag a deviation.
I don't particular want to see more added, and I would like the current
ones to be gone. So what's the plan to remove SAF-1-safe?
At minimum, the deviation should be extremely clear that there **must**
be no new use of SAF-1-safe. Something like:
"- Functions and variables used only by asm modules are either marked
with the `asmlinkage` macro. Existing code may use SAF-1-safe textual
deviation (see safe.json) but new code should not use it.
"
Obviously this is not my preference.
Cheers,
--
Julien Grall
[linux-linus test] 183648: regressions - trouble: fail/pass/starved
flight 183648 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/183648/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-examine 8 reboot fail REGR. vs. 183617 test-arm64-arm64-xl-credit1 8 xen-boot fail REGR. vs. 183617 test-arm64-arm64-xl-credit2 8 xen-boot fail REGR. vs. 183617 test-arm64-arm64-libvirt-xsm 8 xen-boot fail REGR. vs. 183617 test-arm64-arm64-xl-thunderx 8 xen-boot fail REGR. vs. 183617 test-arm64-arm64-xl 8 xen-boot fail REGR. vs. 183617 test-arm64-arm64-libvirt-raw 8 xen-boot fail REGR. vs. 183617 test-arm64-arm64-xl-xsm 8 xen-boot fail REGR. vs. 183617 test-arm64-arm64-xl-vhd 8 xen-boot fail REGR. vs. 183617 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 183617 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 183617 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 183617 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 183617 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 183617 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 183617 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 183617 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 183617 test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qcow2 14 migrate-support-checkfail never pass test-amd64-amd64-libvirt-raw 14 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass test-amd64-amd64-dom0pvh-xl-amd 3 hosts-allocate starved n/a version targeted for testing: linux8bc9e6515183935fa0cccaf67455c439afe4982b baseline version: linuxffc253263a1375a65fa6c9f62a893e9767fbebfa Last test of basis 183617 2023-10-30 08:36:55 Z2 days Failing since183625 2023-10-31 02:27:44 Z1 days4 attempts Testing same since 183648 2023-11-01 12:40:22 Z0 days1 attempts 866 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-arm64-pvopspass build-armhf-pvopspass build-i386-pvops
Re: [PATCH for-4.18] x86/time: Fix UBSAN failure in __update_vcpu_system_time()
Hi Andrew,
> On Nov 2, 2023, at 04:37, Andrew Cooper wrote:
>
> As reported:
>
> (XEN)
>
> (XEN) UBSAN: Undefined behaviour in arch/x86/time.c:1542:32
> (XEN) member access within null pointer of type 'union vcpu_info_t'
> (XEN) [ Xen-4.19-unstable x86_64 debug=y ubsan=y Not tainted ]
> ...
> (XEN) Xen call trace:
> (XEN)[] R common/ubsan/ubsan.c#ubsan_epilogue+0xa/0xd2
> (XEN)[] F __ubsan_handle_type_mismatch+0x133/0x49b
> (XEN)[] F __ubsan_handle_type_mismatch_v1+0xfa/0xfc
> (XEN)[] F
> arch/x86/time.c#__update_vcpu_system_time+0x212/0x30f
> (XEN)[] F update_vcpu_system_time+0xe/0x10
> (XEN)[] F
> arch/x86/time.c#local_time_calibration+0x1f7/0x523
> (XEN)[] F common/softirq.c#__do_softirq+0x1f4/0x31a
> (XEN)[] F do_softirq+0x13/0x15
> (XEN)[] F arch/x86/domain.c#idle_loop+0x2e0/0x367
> (XEN)
> (XEN)
>
>
> It is not valid to derive a pointer from vcpu_info() prior to checking that
> the underlying map pointer is good.
>
> Reorder actions so the NULL pointer check is first.
>
> Fixes: 20279afd7323 ("x86: split populating of struct vcpu_time_info into a
> separate function")
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Roger Pau Monné
> CC: Wei Liu
> CC: Henry Wang
>
> 4.18 blocker, or we'll need to issue an XSA/CVE.
Release-acked-by: Henry Wang
Kind regards,
Henry
Re: [PATCH v8 8/8] xen/arm: mmu: move MMU specific P2M code to mmu/p2m.{c,h}
Hi Julien,
> On Nov 2, 2023, at 02:34, Julien Grall wrote:
>
> Hi Henry,
>
> On 23/10/2023 03:13, Henry Wang wrote:
>> From: Penny Zheng
>> Current P2M implementation is designed for MMU system only.
>> We move the MMU-specific codes into mmu/p2m.c, and only keep generic
>> codes in p2m.c, like VMID allocator, etc. We also move MMU-specific
>> definitions and declarations to mmu/p2m.h, such as p2m_tlb_flush_sync().
>> Also expose previously static functions p2m_vmid_allocator_init(),
>> p2m_alloc_vmid() for further MPU usage. Since with the code movement
>> p2m_free_vmid() is now used in two files, also expose p2m_free_vmid().
>> With the code movement, global variable max_vmid is used in multiple
>> files instead of a single file (and will be used in MPU P2M
>> implementation), declare it in the header and remove the "static" of
>> this variable.
>> Also, since p2m_invalidate_root() should be MMU only and after the
>> code movement the only caller of p2m_invalidate_root() outside of
>> mmu/p2m.c is arch_domain_creation_finished(), creating a new function
>> named p2m_domain_creation_finished() in mmu/p2m.c for the original
>> code in arch_domain_creation_finished(), and marking
>> p2m_invalidate_root() as static.
>> Take the opportunity to fix the incorrect coding style when possible.
>> When there is bit shift in macros, take the opportunity to add the
>> missing 'U' as a compliance of MISRA.
>> Signed-off-by: Penny Zheng
>> Signed-off-by: Wei Chen
>> Signed-off-by: Henry Wang
>
> Acked-by: Julien Grall
Thanks!
>
> I think the series is now fully acked. But I will wait for 4.18 to be
> released before merging this series.
I think the third patch "xen/arm: Fold mmu_init_secondary_cpu() to head.S” will
need the
double check from your side :)
Here is what I have locally, to save time I will just show the content here for
you to check,
and I will push it in the next few days:
commit ba72d6dc17fd7ce9a863b9e00b06b33c069c7641
Author: Henry Wang
Date: Wed Aug 23 17:59:50 2023 +0800
xen/arm: Fold mmu_init_secondary_cpu() to head.S
Currently mmu_init_secondary_cpu() only enforces the page table
should not contain mapping that are both Writable and eXecutables
after boot. To ease the arch/arm/mm.c split work, fold this function
to head.S.
For arm32, the WXN bit cannot be set early because at the point when
the MMU is enabled, the page-tables may still contain mapping which
are writable and executable. Therefore, introduce an assembly macro
pt_enforce_wxn. The macro is called before secondary CPUs jumping
into the C world.
For arm64, set the SCTLR_Axx_ELx_WXN flag right when the MMU is
enabled. This would avoid the extra TLB flush and SCTLR dance.
Signed-off-by: Henry Wang
Co-authored-by: Julien Grall
Signed-off-by: Julien Grall
Signed-off-by: Ayan Kumar Halder
---
v9:
- Move pt_enforce_wxn() for arm32 up a few lines.
- Add commit message explaining why WXN cannot be set early for arm32.
- Correct in-code comment for enable_mmu().
v8:
- Change the setting of SCTLR_Axx_ELx_WXN for arm64 to set the
flag right when the MMU is enabled.
v7:
- No change.
v6:
- New patch.
diff --git a/xen/arch/arm/arm32/head.S b/xen/arch/arm/arm32/head.S
index 33b038e7e0..2fea2a872a 100644
--- a/xen/arch/arm/arm32/head.S
+++ b/xen/arch/arm/arm32/head.S
@@ -83,6 +83,25 @@
isb
.endm
+/*
+ * Enforce Xen page-tables do not contain mapping that are both
+ * Writable and eXecutables.
+ *
+ * This should be called on each secondary CPU.
+ */
+.macro pt_enforce_wxn tmp
+mrc CP32(\tmp, HSCTLR)
+orr \tmp, \tmp, #SCTLR_Axx_ELx_WXN
+dsb
+mcr CP32(\tmp, HSCTLR)
+/*
+ * The TLBs may cache SCTLR_EL2.WXN. So ensure it is synchronized
+ * before flushing the TLBs.
+ */
+isb
+flush_xen_tlb_local \tmp
+.endm
+
/*
* Common register usage in this file:
* r0 -
@@ -249,6 +268,7 @@ secondary_switched:
dsb
isb
flush_xen_tlb_local r0
+pt_enforce_wxn r0
#ifdef CONFIG_EARLY_PRINTK
/* Use a virtual address to access the UART. */
diff --git a/xen/arch/arm/arm64/mmu/head.S b/xen/arch/arm/arm64/mmu/head.S
index 88075ef083..34de5df0c7 100644
--- a/xen/arch/arm/arm64/mmu/head.S
+++ b/xen/arch/arm/arm64/mmu/head.S
@@ -263,11 +263,13 @@ ENDPROC(create_page_tables)
*
* Inputs:
* x0 : Physical address of the page tables.
+ * x1 : Extra flags of the SCTLR.
*
- * Clobbers x0 - x4
+ * Clobbers x0 - x5
*/
enable_mmu:
mov x4, x0
+mov x5, x1
PRINT("- Turning on paging -\r\n")
/*
@@ -283,6 +285,7 @@ enable_mmu:
mrs x0, SCTLR_EL2
orr x0, x0, #SCTLR_Axx_ELx_M /* Enable MMU */
orr x0, x0, #SCTLR_Axx_ELx_C /* Enable D-cache */
+orr x0, x0, x5/* Enable extra flags */
dsb s
