flight 167679 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167679/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 167668
test-armhf-armhf-libvirt 16 saver
On 13.01.22 02:00, Stefano Stabellini wrote:
From: Luca Miccio
When running as dom0less guest (HVM domain on ARM) the xenstore event
channel is available at domain creation but the shared xenstore
interface page only becomes available later on.
In that case, wait for a notification on the xens
flight 167677 xen-unstable real [real]
flight 167681 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/167677/
http://logs.test-lab.xenproject.org/osstest/logs/167681/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
commit 0fdb48ffe7a1 "libxl: Make sure devices added by pci-attach are
reflected in the config" broken PCI hotplug (xl pci-attach) for PV
domains when it moved libxl__create_pci_backend() later in the function.
This also broke HVM + stubdom PCI passthrough coldplug. For that, the
PCI devices are h
Hi, Stefano
Thanks for this reply.
Stefano Stabellini 于2022年1月13日周四 09:52写道：
>
> On Wed, 12 Jan 2022, Dongjiu Geng wrote:
> > > > diff --git a/xen/arch/arm/platforms/Kconfig
> > > > b/xen/arch/arm/platforms/Kconfig
> > > > index c93a6b2756..925f6ef8da 100644
> > > > --- a/xen/arch/arm/platfo
On Wed, 12 Jan 2022, Dongjiu Geng wrote:
> > > diff --git a/xen/arch/arm/platforms/Kconfig
> > > b/xen/arch/arm/platforms/Kconfig
> > > index c93a6b2756..925f6ef8da 100644
> > > --- a/xen/arch/arm/platforms/Kconfig
> > > +++ b/xen/arch/arm/platforms/Kconfig
> > > @@ -15,7 +15,7 @@ config ALL_PLAT
Hi all,
This small patch series for Linux implements support for initializing
xenstore later when booting as Dom0less kernel (HVM guest on ARM). With
this small patch series applied, it is possible to use PV drivers in
Linux when Linux is booted as dom0less kernel.
Cheers,
Stefano
Luca Miccio (
From: Luca Miccio
When running as dom0less guest (HVM domain on ARM) the xenstore event
channel is available at domain creation but the shared xenstore
interface page only becomes available later on.
In that case, wait for a notification on the xenstore event channel,
then complete the xenstore
From: Luca Miccio
When xs_introduce_domain is called, send out a notification on the
xenstore event channel so that any (dom0less) domain waiting for the
xenstore interface to be ready can continue with the initialization.
The extra notification is harmless for domains that don't require it.
Si
From: Luca Miccio
Add an example application that can be run in dom0 to complete the
dom0less domains initialization so that they can get access to xenstore
and use PV drivers.
Signed-off-by: Luca Miccio
Signed-off-by: Stefano Stabellini
CC: Wei Liu
CC: Anthony PERARD
CC: Juergen Gross
---
From: Luca Miccio
If "xen,enhanced" is enabled, then add to dom0less domains:
- the hypervisor node in device tree
- the xenstore event channel
The xenstore event channel is also used for the first notification to
let the guest know that xenstore has become available.
Signed-off-by: Luca Micci
From: Stefano Stabellini
Introduce a new "xen,enhanced" dom0less property to enable/disable PV
driver interfaces for dom0less guests. Currently only "enabled" and
"disabled" are supported property values (and empty). Leave the option
open to implement further possible values in the future (e.g.
"
From: Stefano Stabellini
get_free_port will soon be used to allocate the xenstore event channel
for dom0less domains.
Signed-off-by: Stefano Stabellini
CC: Julien Grall
CC: Volodymyr Babchuk
CC: Bertrand Marquis
CC: Jan Beulich
CC: Andrew Cooper
---
xen/common/event_channel.c | 2 +-
xen/
Hi all,
Currently dom0less guests cannot use PV drivers because they don't have
access to xenstore. Also, the hypervisor node in device tree is missing
so they don't detect that they are running on Xen (thus, they don't try
to enable PV interfaces.)
This patch series enables dom0less guests (on A
On Sat, 8 Jan 2022, Marek Marczykowski-Górecki wrote:
> On Fri, Jan 07, 2022 at 04:49:11PM -0800, Stefano Stabellini wrote:
> > From: Luca Miccio
> >
> > If the function is called with late_init set then also notify the domain
> > using the xenstore event channel.
> >
> > Signed-off-by: Luca Mic
On Sat, 8 Jan 2022, Marek Marczykowski-Górecki wrote:
> On Fri, Jan 07, 2022 at 04:49:08PM -0800, Stefano Stabellini wrote:
> > From: Luca Miccio
> >
> > Add a late_init argument to xs_introduce_domain to handle dom0less
> > guests whose xenstore interfaces are initialized after boot.
> >
> > Th
On Wed, 12 Jan 2022, Jan Beulich wrote:
> On 11.01.2022 23:49, Stefano Stabellini wrote:
> > On Mon, 10 Jan 2022, Jan Beulich wrote:
> >> On 08.01.2022 01:49, Stefano Stabellini wrote:
> >>> @@ -284,11 +285,32 @@ void evtchn_free(struct domain *d, struct evtchn
> >>> *chn)
> >>> xsm_evtchn_cl
The pull request you sent on Wed, 12 Jan 2022 16:50:11 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
> for-linus-5.17-rc1-tag
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/ce990f1de0bc6ff3de43d385e0985efa980fba24
Thank you!
--
Deet-doot-dot, I
flight 167675 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167675/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail like 167665
test-amd64-amd64-xl-qemuu-win7-amd6
flight 167674 qemu-upstream-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167674/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail baseline
untested
test-arm64-arm64-libv
flight 167668 linux-linus real [real]
flight 167678 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/167668/
http://logs.test-lab.xenproject.org/osstest/logs/167678/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-arm64-
A couple more comments I realized while walking the dog.
On Thu, Nov 25, 2021 at 01:02:43PM +0200, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Add relevant vpci register handlers when assigning PCI device to a domain
> and remove those when de-assigning. This allows having
The virtqueue host notifier API
virtio_queue_aio_set_host_notifier_handler() polls the virtqueue for new
buffers. AioContext previously required a bool progress return value
indicating whether an event was handled or not. This is no longer
necessary because the AioContext polling API has been split
Now that virtio-blk and virtio-scsi are ready, get rid of
the handle_aio_output() callback. It's no longer needed.
Signed-off-by: Stefan Hajnoczi
Reviewed-by: Stefano Garzarella
Message-id: 20211207132336.36627-7-stefa...@redhat.com
Signed-off-by: Stefan Hajnoczi
---
include/hw/virtio/virtio.h
The difference between ->handle_output() and ->handle_aio_output() was
that ->handle_aio_output() returned a bool return value indicating
progress. This was needed by the old polling API but now that the bool
return value is gone, the two functions can be unified.
Signed-off-by: Stefan Hajnoczi
R
Prepare virtio_scsi_handle_cmd() to be used by both dataplane and
non-dataplane by making the condition for starting ioeventfd more
specific. This way it won't trigger when dataplane has already been
started.
Signed-off-by: Stefan Hajnoczi
Reviewed-by: Stefano Garzarella
Message-id: 202112071323
The return value of virtio_blk_handle_vq() is no longer used. Get rid of
it. This is a step towards unifying the dataplane and non-dataplane
virtqueue handler functions.
Prepare virtio_blk_handle_output() to be used by both dataplane and
non-dataplane by making the condition for starting ioeventfd
Adaptive polling measures the execution time of the polling check plus
handlers called when a polled event becomes ready. Handlers can take a
significant amount of time, making it look like polling was running for
a long time when in fact the event handler was running for a long time.
For example,
The following changes since commit 91f5f7a5df1fda8c34677a7c49ee8a4bb5b56a36:
Merge remote-tracking branch
'remotes/lvivier-gitlab/tags/linux-user-for-7.0-pull-request' into staging
(2022-01-12 11:51:47 +)
are available in the Git repository at:
https://gitlab.com/stefanha/qemu.git tags
On Sun, Jan 09, 2022 at 01:04:36PM -0500, Jason Andryuk wrote:
> commit 0fdb48ffe7a1 "libxl: Make sure devices added by pci-attach are
> reflected in the config" broken PCI hotplug (xl pci-attach) for PV
> domains when it moved libxl__create_pci_backend() later in the function.
>
> This also broke
On 10.01.2022 13:37, Roger Pau Monné wrote:
> On Fri, Jan 07, 2022 at 12:39:04PM +0100, Jan Beulich wrote:
>> @@ -415,16 +416,35 @@ static int64_t __init init_hpet(struct p
>>
>> pts->frequency = hpet_rate;
>>
>> +for(i = 0; i < 16; ++i) {//temp
>> count = hpet_read32(HPET_COUNTER);
>
flight 167669 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167669/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 151777
build-arm64-libvirt
If we are in libvxl_list_vcpu() and we are returning NULL, let's avoid
touching the output parameter *nr_vcpus_out (which should contain the
number of vcpus in the list). Ideally, the caller initialized it to 0,
which is therefore consistent with us returning NULL (or, as an alternative,
we can exp
If libxl_vcpu_list() returned NULL, we should not call
libxl_numainfo_list_free() as:
1) it'll fail trying to (double) free() *list
2) there should be nothing to free anyway
Signed-off-by: Dario Faggioli
Tested-by: James Fehlig
---
Cc: Wei Liu
Cc: Anthony PERARD
Cc: Juergen Gross
---
tools/l
It is possible to encounter a segfault in libxl during concurrent domain
create and destroy operations.
This is because Placement of existing domains on the host's CPUs is examined
when creating a new domain, but the existing logic does not tolerate well a
domain disappearing during the examinatio
On 12.01.2022 16:42, Roger Pau Monné wrote:
> On Wed, Jan 12, 2022 at 03:57:36PM +0100, Jan Beulich wrote:
>> On 25.11.2021 12:02, Oleksandr Andrushchenko wrote:
>>> @@ -379,7 +396,6 @@ uint32_t vpci_read(pci_sbdf_t sbdf, unsigned int reg,
>>> unsigned int size)
>>>
>>> data = merge_res
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-5.17-rc1-tag
xen: branch for v5.17-rc1
It contains the following patches:
- a fix of the Xen gntdev driver
- a fix for running as Xen dom0 booted via EFI and the EFI framebuffer
be
On Wed, Jan 12, 2022 at 03:57:36PM +0100, Jan Beulich wrote:
> On 25.11.2021 12:02, Oleksandr Andrushchenko wrote:
> > @@ -379,7 +396,6 @@ uint32_t vpci_read(pci_sbdf_t sbdf, unsigned int reg,
> > unsigned int size)
> >
> > data = merge_result(data, tmp_data, size - data_offset,
> > da
On 25.11.2021 12:02, Oleksandr Andrushchenko wrote:
> @@ -145,6 +148,53 @@ int vpci_add_handlers(struct pci_dev *pdev)
> }
>
> #ifdef CONFIG_HAS_VPCI_GUEST_SUPPORT
> +int vpci_add_virtual_device(struct pci_dev *pdev)
> +{
> +struct domain *d = pdev->domain;
> +pci_sbdf_t sbdf = { 0 };
>
On 25.11.2021 12:02, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> When a vPCI is removed for a PCI device it is possible that we have
> scheduled a delayed work for map/unmap operations for that device.
> For example, the following scenario can illustrate the problem:
>
> p
flight 167676 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167676/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 12.01.2022 16:15, Roger Pau Monné wrote:
> On Thu, Nov 25, 2021 at 01:02:44PM +0200, Oleksandr Andrushchenko wrote:
>> --- a/xen/drivers/vpci/header.c
>> +++ b/xen/drivers/vpci/header.c
>> @@ -137,45 +137,86 @@ bool vpci_process_pending(struct vcpu *v)
>> return false;
>>
>> spin
On Thu, Nov 25, 2021 at 01:02:44PM +0200, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Instead of handling a single range set, that contains all the memory
> regions of all the BARs and ROM, have them per BAR.
> As the range sets are now created when a PCI device is added an
On 25.11.2021 12:02, Oleksandr Andrushchenko wrote:
> @@ -68,12 +84,13 @@ int vpci_add_handlers(struct pci_dev *pdev)
> /* We should not get here twice for the same device. */
> ASSERT(!pdev->vpci);
>
> -pdev->vpci = xzalloc(struct vpci);
> -if ( !pdev->vpci )
> +vpci = xzal
On Wed, Jan 12, 2022 at 9:20 AM Ronny Wagner wrote:
>
> Hello,
Hi
> i restart my windows domU today.
>
> And now, the domU don't start. Have anyone a idea, why? I am not change
> any config on the Host.
>
> Thank you for helping!
>
> Fail-Message:
> root@server ~ # xl create -f /etc/xen/domU.cfg
On 11.01.2022 16:17, Roger Pau Monné wrote:
> On Thu, Nov 25, 2021 at 01:02:40PM +0200, Oleksandr Andrushchenko wrote:
>> diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c
>> index 657697fe3406..ceaac4516ff8 100644
>> --- a/xen/drivers/vpci/vpci.c
>> +++ b/xen/drivers/vpci/vpci.c
>> @@
Hello,
i restart my windows domU today.
And now, the domU don't start. Have anyone a idea, why? I am not change
any config on the Host.
Thank you for helping!
Fail-Message:
root@server ~ # xl create -f /etc/xen/domU.cfg
Parsing config from /etc/xen/domU.cfg
libxl: error: libxl_dm.c:3131:device_
flight 167667 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167667/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-rtds 18 guest-start/debian.repeat fail pass in 167661
test-amd64-amd64-xl-qemut-debian
On 12.01.22 08:22, Juergen Gross wrote:
On 11.01.22 20:56, Andrew Cooper wrote:
On 11/01/2022 15:03, Juergen Gross wrote:
diff --git a/tools/libs/evtchn/minios.c b/tools/libs/evtchn/minios.c
index e5dfdc5ef5..c3a5ce3b98 100644
--- a/tools/libs/evtchn/minios.c
+++ b/tools/libs/evtchn/minios.c
> On 12 Jan 2022, at 08:45, Jan Beulich wrote:
>
> From: Sergey Temerkhanov
>
> This helps overcome problems observed with some UEFI implementations
> which don't set the Attributes field in memery descriptors properly.
>
> Signed-off-by: Sergey Temerkhanov
> Signed-off-by: Jan Beulich
H
On Thu, Nov 25, 2021 at 01:02:43PM +0200, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Add relevant vpci register handlers when assigning PCI device to a domain
> and remove those when de-assigning. This allows having different
> handlers for different domains, e.g. hwdom an
On Thu, Nov 25, 2021 at 01:02:42PM +0200, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> When a PCI device gets assigned/de-assigned some work on vPCI side needs
> to be done for that device. Introduce a pair of hooks so vPCI can handle
> that.
>
> Signed-off-by: Oleksandr An
Julien Grall 于2021年12月28日周二 18:39写道：
>
> Hi,
>
> On Tue, 28 Dec 2021 at 05:14, Dongjiu Geng wrote:
> >
> > Trying to select PLATFORM_QEMU with NEW_VGIC will result to Kconfig
> > complain about unmet dependencies:
> >
> > tools/kconfig/conf --syncconfig Kconfig
> >
> > WARNING: unmet direct depe
On 12/01/2022 11:32, Juergen Gross wrote:
> On 12.01.22 12:28, Andrew Cooper wrote:
>> On 11/01/2022 15:12, Juergen Gross wrote:
>>> diff --git a/lib/sys.c b/lib/sys.c
>>> index 3a8aa68..12deaed 100644
>>> --- a/lib/sys.c
>>> +++ b/lib/sys.c
>>> @@ -99,11 +99,70 @@ static struct file_ops file_ops_n
On 12.01.2022 11:53, Roger Pau Monné wrote:
> On Wed, Jan 12, 2022 at 09:56:12AM +0100, Jan Beulich wrote:
>> While the problem report was for extreme errors, even smaller ones would
>> better be avoided: The calculated period to run calibration loops over
>> can (and usually will) be shorter than
On 12.01.22 12:28, Andrew Cooper wrote:
On 11/01/2022 15:12, Juergen Gross wrote:
diff --git a/lib/sys.c b/lib/sys.c
index 3a8aa68..12deaed 100644
--- a/lib/sys.c
+++ b/lib/sys.c
@@ -99,11 +99,70 @@ static struct file_ops file_ops_none = {
.name = "none",
};
+#ifdef HAVE_LWIP
+static
On 12.01.22 12:25, Andrew Cooper wrote:
On 11/01/2022 15:12, Juergen Gross wrote:
+static int socket_write(int fd, const void *buf, size_t nbytes)
+{
+return lwip_write(fd, (void *)buf, nbytes);
This void cast was bogus before, and can be dropped. lwip_write()
already takes a const pointe
On 12.01.22 12:23, Andrew Cooper wrote:
On 11/01/2022 15:12, Juergen Gross wrote:
+static int savefile_write(int fd, const void *buf, size_t nbytes)
+{
+int ret = 0, tot = nbytes;
+struct file *file = get_file_from_fd(fd);
+
+while ( nbytes > 0 )
+{
+ret = xencons_ring_se
On 12/01/2022 11:28, Jan Beulich wrote:
> Macros with arguments need to be invoked via $(call ...); don't misguide
> people looking up usage of such macros.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
Macros with arguments need to be invoked via $(call ...); don't misguide
people looking up usage of such macros.
Signed-off-by: Jan Beulich
--- a/xen/scripts/Kbuild.include
+++ b/xen/scripts/Kbuild.include
@@ -43,15 +43,15 @@ define as-option-add-closure
endif
endef
-# $(if-success,,,)
+
On 11/01/2022 15:12, Juergen Gross wrote:
> diff --git a/lib/sys.c b/lib/sys.c
> index 3a8aa68..12deaed 100644
> --- a/lib/sys.c
> +++ b/lib/sys.c
> @@ -99,11 +99,70 @@ static struct file_ops file_ops_none = {
> .name = "none",
> };
>
> +#ifdef HAVE_LWIP
> +static int socket_read(int fd, vo
On 11/01/2022 15:12, Juergen Gross wrote:
> +static int socket_write(int fd, const void *buf, size_t nbytes)
> +{
> +return lwip_write(fd, (void *)buf, nbytes);
This void cast was bogus before, and can be dropped. lwip_write()
already takes a const pointer.
~Andrew
On 11/01/2022 15:12, Juergen Gross wrote:
> +static int savefile_write(int fd, const void *buf, size_t nbytes)
> +{
> +int ret = 0, tot = nbytes;
> +struct file *file = get_file_from_fd(fd);
> +
> +while ( nbytes > 0 )
> +{
> +ret = xencons_ring_send(file->dev, (char *)buf,
flight 167671 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167671/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On Wed, Jan 12, 2022 at 09:56:12AM +0100, Jan Beulich wrote:
> While the problem report was for extreme errors, even smaller ones would
> better be avoided: The calculated period to run calibration loops over
> can (and usually will) be shorter than the actual time elapsed between
> first and last
flight 167665 qemu-mainline real [real]
flight 167672 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/167665/
http://logs.test-lab.xenproject.org/osstest/logs/167672/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-ar
Juergen Gross, le mer. 12 janv. 2022 08:57:07 +0100, a ecrit:
> On 11.01.22 21:35, Samuel Thibault wrote:
> > Juergen Gross, le mar. 11 janv. 2022 16:12:12 +0100, a ecrit:
> > > +static int consfront_fstat(int fd, struct stat *buf)
> > > +{
> > > +struct file *file = get_file_from_fd(fd);
> > >
Juergen Gross, le mar. 11 janv. 2022 16:12:13 +0100, a ecrit:
> Even with some special handling needed in select_poll(), add a struct
> file_ops for FTYPE_SOCKET. Due to the need of the special handling it
> isn't possible to use a dynamically allocated file type.
>
> Most functions calling the fi
Juergen Gross, le mar. 11 janv. 2022 16:12:12 +0100, a ecrit:
> Add struct file_ops for the console related file types (FTYPE_CONSOLE
> and savefile). FTYPE_CONSOLE remains statically defined, as it is used
> to statically init stdin, stdout and stderr.
>
> Instead of directly accessing the files[
On Wed, Jan 12, 2022 at 09:55:17AM +0100, Jan Beulich wrote:
> Looping until reaching/exceeding a certain value is error prone: If the
> target value is close enough to the wrapping point, the loop may not
> terminate at all. Switch to using delta values, which then allows to
> fold the two loops e
flight 167673 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167673/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 22891e12a45f9bb2e1dbb5daf2ba39cbe002e4f4
baseline version:
xen ced5
On 12.01.2022 10:17, Andrew Cooper wrote:
> On 12/01/2022 08:58, Jan Beulich wrote:
>> Except in the "clocksource=tsc" case we can replace the indirect calls
>> involved in accessing the platform timers by direct ones, as they get
>> established once and never changed.
>>
>> Signed-off-by: Jan Beul
On 12.01.2022 10:22, Andrew Cooper wrote:
> On 12/01/2022 09:00, Jan Beulich wrote:
>> When the macro's "return value" is not used, the macro use can be
>> replaced by a simply division, avoiding some obfuscation.
>>
>> According to my observations, no change to generated code.
>>
>> Signed-off-by:
On 12/01/2022 09:00, Jan Beulich wrote:
> When the macro's "return value" is not used, the macro use can be
> replaced by a simply division, avoiding some obfuscation.
>
> According to my observations, no change to generated code.
>
> Signed-off-by: Jan Beulich
I like this change in principle, bu
On 12/01/2022 08:58, Jan Beulich wrote:
> Except in the "clocksource=tsc" case we can replace the indirect calls
> involved in accessing the platform timers by direct ones, as they get
> established once and never changed.
>
> Signed-off-by: Jan Beulich
> ---
> Sort of RFC, for both the whether an
When the macro's "return value" is not used, the macro use can be
replaced by a simply division, avoiding some obfuscation.
According to my observations, no change to generated code.
Signed-off-by: Jan Beulich
---
Arguably the ULL suffix (in write_watchdog_counter()) or the cast to
uint64_t (in
Except in the "clocksource=tsc" case we can replace the indirect calls
involved in accessing the platform timers by direct ones, as they get
established once and never changed.
Signed-off-by: Jan Beulich
---
Sort of RFC, for both the whether and the how aspects.
TBD: Overriding X86_FEATURE_ALWAY
While the problem report was for extreme errors, even smaller ones would
better be avoided: The calculated period to run calibration loops over
can (and usually will) be shorter than the actual time elapsed between
first and last platform timer and TSC reads. Adjust values returned from
the init fu
Looping until reaching/exceeding a certain value is error prone: If the
target value is close enough to the wrapping point, the loop may not
terminate at all. Switch to using delta values, which then allows to
fold the two loops each into just one.
Fixes: 93340297802b ("x86/time: calibrate TSC aga
While it'll take some time to know whether presumably the 2nd these
changes will help with the originally reported issue, there are
immediate positive effects even beyond that issue, which is why I
didn't want to wait with the submission. There's at least one more
issue to take care of (see the res
From: Sergey Temerkhanov
This helps overcome problems observed with some UEFI implementations
which don't set the Attributes field in memery descriptors properly.
Signed-off-by: Sergey Temerkhanov
Signed-off-by: Jan Beulich
---
v4: Drop EFI_MEMORY_CACHEABILITY_MASK. Fold with pre-existing if()
On 12/01/2022 07:27, Juergen Gross wrote:
> On 11.01.22 21:08, Andrew Cooper wrote:
>
>> The least bad way I can think of doing this would be to leave void
>> minios_gnttab_close_fd(int fd) exactly as it was, and instead of
>> converting it's use here, use a separate static function straight away
>
On 12.01.22 09:19, Andrew Cooper wrote:
On 12/01/2022 07:34, Juergen Gross wrote:
On 11.01.22 19:08, Andrew Cooper wrote:
On 11/01/2022 14:58, Juergen Gross wrote:
+
+off_t lseek_default(int fd, off_t offset, int whence);
+bool select_yes(int fd);
+bool select_read_flag(int fd);
+
LIST_HEAD
On 12/01/2022 07:34, Juergen Gross wrote:
> On 11.01.22 19:08, Andrew Cooper wrote:
>> On 11/01/2022 14:58, Juergen Gross wrote:
>>> +
>>> +off_t lseek_default(int fd, off_t offset, int whence);
>>> +bool select_yes(int fd);
>>> +bool select_read_flag(int fd);
>>> +
>>> LIST_HEAD(evtchn_port_list
On 12/01/2022 07:54, Juergen Gross wrote:
> On 11.01.22 21:29, Andrew Cooper wrote:
>> On 11/01/2022 15:12, Juergen Gross wrote:
>>> diff --git a/tpm_tis.c b/tpm_tis.c
>>> index 477f555..abea7a1 100644
>>> --- a/tpm_tis.c
>>> +++ b/tpm_tis.c
>>> @@ -1093,6 +1097,23 @@ ssize_t tpm_getcap(struct tpm_
On 12/01/2022 07:52, Juergen Gross wrote:
> On 11.01.22 21:21, Andrew Cooper wrote:
>> On 11/01/2022 15:12, Juergen Gross wrote:
>>> void xs_daemon_close(struct xs_handle *h)
>>> {
>>> - int fd = _xs_fileno(h);
>>> - struct xenbus_event *event, *next;
>>> - for (event = files[fd].dev;
86 matches
Mail list logo
