On Fri, 26 Jul 2024 at 01:29, Joe Damato wrote:
>
> On Thu, Jul 25, 2024 at 09:31:02AM +0800, Cindy Lu wrote:
> [...]
> > diff --git a/drivers/vdpa/vdpa.c b/drivers/vdpa/vdpa.c
> > index 8d391947eb8d..532cf3b52b26 100644
> > --- a/drivers/vdpa/vdpa.c
> > +++ b/drivers/vdpa/vdpa.c
> > @@ -1361,6
On Fri, 2024-07-26 at 09:14 -0400, Michael S. Tsirkin wrote:
> For purposes of virtio, should we label all the fields here
> __le?
Yes. Peter and I discussed that, and it's mostly just a cosmetic change
at this point. The simple ACPI thing only exists on LE platforms for
*now* anyway.
We also
On Fri, 26 Jul 2024 at 01:29, Joe Damato wrote:
>
> On Thu, Jul 25, 2024 at 09:31:02AM +0800, Cindy Lu wrote:
> [...]
> > diff --git a/drivers/vdpa/vdpa.c b/drivers/vdpa/vdpa.c
> > index 8d391947eb8d..532cf3b52b26 100644
> > --- a/drivers/vdpa/vdpa.c
> > +++ b/drivers/vdpa/vdpa.c
> > @@ -1361,6
On Fri, 26 Jul 2024 at 01:25, Joe Damato wrote:
>
> On Thu, Jul 25, 2024 at 09:31:01AM +0800, Cindy Lu wrote:
> > Add support for setting the MAC address using the VDPA tool.
> > This feature will allow setting the MAC address using the VDPA tool.
> > For example, in vdpa_sim_net, the
On Fri, Jul 26, 2024 at 01:28:17PM +0100, David Woodhouse wrote:
> diff --git a/include/uapi/linux/vmclock-abi.h
> b/include/uapi/linux/vmclock-abi.h
> new file mode 100644
> index ..7b1b4759363c
> --- /dev/null
> +++ b/include/uapi/linux/vmclock-abi.h
> @@ -0,0 +1,187 @@
> +/*
On Fri, 2024-07-26 at 09:04 -0400, Michael S. Tsirkin wrote:
> On Fri, Jul 26, 2024 at 02:00:25PM +0100, David Woodhouse wrote:
> > On Fri, 2024-07-26 at 08:52 -0400, Michael S. Tsirkin wrote:
> > > On Fri, Jul 26, 2024 at 09:35:51AM +0100, David Woodhouse wrote:
> > > > But for this use case, we
On Fri, Jul 26, 2024 at 02:00:25PM +0100, David Woodhouse wrote:
> On Fri, 2024-07-26 at 08:52 -0400, Michael S. Tsirkin wrote:
> > On Fri, Jul 26, 2024 at 09:35:51AM +0100, David Woodhouse wrote:
> > > But for this use case, we only need a memory region that the hypervisor
> > > can update. We
On Fri, 2024-07-26 at 08:52 -0400, Michael S. Tsirkin wrote:
> On Fri, Jul 26, 2024 at 09:35:51AM +0100, David Woodhouse wrote:
> > But for this use case, we only need a memory region that the hypervisor
> > can update. We don't need any of that complexity of gratuitously
> > interrupting all the
On Fri, Jul 26, 2024 at 09:35:51AM +0100, David Woodhouse wrote:
> But for this use case, we only need a memory region that the hypervisor
> can update. We don't need any of that complexity of gratuitously
> interrupting all the vCPUs just to ensure that none of them can be
> running userspace
On Fri, 2024-07-26 at 08:47 -0400, Michael S. Tsirkin wrote:
> On Fri, Jul 26, 2024 at 09:06:29AM +0100, David Woodhouse wrote:
> > That's great. You don't even need it to be per-vCPU if you let the
> > hypervisor write directly to the single physical location that's mapped
> > to userspace. It
On Fri, Jul 26, 2024 at 09:06:29AM +0100, David Woodhouse wrote:
> That's great. You don't even need it to be per-vCPU if you let the
> hypervisor write directly to the single physical location that's mapped
> to userspace. It can do that before it even starts *running* the vCPUs
> after
On Fri, Jul 26, 2024 at 5:45 AM Steven Rostedt wrote:
>
> From: Steven Rostedt
>
> When eventfs was introduced, special care had to be done to coordinate the
> freeing of the file meta data with the files that are exposed to user
> space. The file meta data would have a ref count that is set
From: David Woodhouse
The vmclock "device" provides a shared memory region with precision clock
information. By using shared memory, it is safe across Live Migration.
Like the KVM PTP clock, this can convert TSC-based cross timestamps into
KVM clock values. Unlike the KVM PTP clock, it does so
On 26.07.24 02:15, Steven Rostedt wrote:
> From: Steven Rostedt
>
> When eventfs was introduced, special care had to be done to coordinate the
> freeing of the file meta data with the files that are exposed to user
> space. The file meta data would have a ref count that is set when the file
> is
On Fri, 2024-07-26 at 02:06 -0400, Michael S. Tsirkin wrote:
> On Thu, Jul 25, 2024 at 11:20:56PM +0100, David Woodhouse wrote:
> > We're rolling out the AMZNVCLK device for internal use cases, and plan
> > to add it in public instances some time later.
>
> Let's be real. If amazon does something
On 26.07.24 01:06, Steven Rostedt wrote:
> On Thu, 25 Jul 2024 23:32:30 +0200
> Mathias Krause wrote:
>
>> That was for a single run of
>> tools/testing/selftests/user_events/ftrace_test with the read loop of
>> /sys/kernel/tracing/events/user_events/__test_event/format in a
>> different shell.
On Fri, 2024-07-26 at 01:55 -0400, Michael S. Tsirkin wrote:
> On Fri, Jul 26, 2024 at 01:09:24AM -0400, Michael S. Tsirkin wrote:
> > On Thu, Jul 25, 2024 at 10:29:18PM +0100, David Woodhouse wrote:
> > > > > > Then can't we fix it by interrupting all CPUs right after LM?
> > > > > >
> > > > > >
On Wed, Jul 10, 2024 at 11:03:42AM +0800, Jason Wang wrote:
> On Tue, Jul 9, 2024 at 9:28 PM Michael S. Tsirkin wrote:
> >
> > On Tue, Jul 09, 2024 at 04:02:14PM +0800, Jason Wang wrote:
> > > This patch synchronize operstate with admin state per RFC2863.
> > >
> > > This is done by trying to
On Thu, Jul 25, 2024 at 11:20:56PM +0100, David Woodhouse wrote:
> We're rolling out the AMZNVCLK device for internal use cases, and plan
> to add it in public instances some time later.
Let's be real. If amazon does something in its own hypervisor, and the
only way to use that is to expose the
On Fri, Jul 26, 2024 at 01:09:24AM -0400, Michael S. Tsirkin wrote:
> On Thu, Jul 25, 2024 at 10:29:18PM +0100, David Woodhouse wrote:
> > > > > Then can't we fix it by interrupting all CPUs right after LM?
> > > > >
> > > > > To me that seems like a cleaner approach - we then compartmentalize
>
On Thu, Jul 25, 2024 at 10:29:18PM +0100, David Woodhouse wrote:
> > > > Then can't we fix it by interrupting all CPUs right after LM?
> > > >
> > > > To me that seems like a cleaner approach - we then compartmentalize
> > > > the ABI issue - kernel has its own ABI against userspace,
> > > >
From: Steven Rostedt
When eventfs was introduced, special care had to be done to coordinate the
freeing of the file meta data with the files that are exposed to user
space. The file meta data would have a ref count that is set when the file
is created and would be decremented and freed after the
On Thu, 25 Jul 2024 23:32:30 +0200
Mathias Krause wrote:
> That was for a single run of
> tools/testing/selftests/user_events/ftrace_test with the read loop of
> /sys/kernel/tracing/events/user_events/__test_event/format in a
> different shell.
>
> >
> > destroy_user_event() which is under
On Thu, 2024-07-25 at 17:47 -0400, Michael S. Tsirkin wrote:
> On Thu, Jul 25, 2024 at 10:29:18PM +0100, David Woodhouse wrote:
> > Those people included me. I wanted to interrupt all the vCPUs, even the
> > ones which were in userspace at the moment of migration, and have the
> > kernel deal with
On Thu, 25 Jul 2024 08:42:09 +0700, Dang Huynh wrote:
> This patch series expand F(x)tec Pro1X (QX1050) device tree to support
> various components of the device.
>
> Most notably:
> + SD Card slot
> + Touchscreen
> + MDSS, DRM display panel
> + WLAN (ATH10K)
> + Hall sensor and camera button
>
On Thu, Jul 25, 2024 at 10:29:18PM +0100, David Woodhouse wrote:
> > > > Then can't we fix it by interrupting all CPUs right after LM?
> > > >
> > > > To me that seems like a cleaner approach - we then compartmentalize
> > > > the ABI issue - kernel has its own ABI against userspace,
> > > >
On Thu, 2024-07-25 at 17:04 -0400, Michael S. Tsirkin wrote:
> On Thu, Jul 25, 2024 at 10:00:24PM +0100, David Woodhouse wrote:
> > On Thu, 2024-07-25 at 16:50 -0400, Michael S. Tsirkin wrote:
> > > On Thu, Jul 25, 2024 at 08:35:40PM +0100, David Woodhouse wrote:
> > > > On Thu, 2024-07-25 at
On Thu, 25 Jul 2024 22:41:23 +0200
Mathias Krause wrote:
> > diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
> > index 6ef29eba90ce..5fbfa1c885de 100644
> > --- a/kernel/trace/trace_events.c
> > +++ b/kernel/trace/trace_events.c
> > @@ -1627,12 +1627,14 @@ static int
On Thu, Jul 25, 2024 at 10:00:24PM +0100, David Woodhouse wrote:
> On Thu, 2024-07-25 at 16:50 -0400, Michael S. Tsirkin wrote:
> > On Thu, Jul 25, 2024 at 08:35:40PM +0100, David Woodhouse wrote:
> > > On Thu, 2024-07-25 at 12:38 -0400, Michael S. Tsirkin wrote:
> > > > On Thu, Jul 25, 2024 at
On Thu, 2024-07-25 at 16:50 -0400, Michael S. Tsirkin wrote:
> On Thu, Jul 25, 2024 at 08:35:40PM +0100, David Woodhouse wrote:
> > On Thu, 2024-07-25 at 12:38 -0400, Michael S. Tsirkin wrote:
> > > On Thu, Jul 25, 2024 at 04:18:43PM +0100, David Woodhouse wrote:
> > > > The use case isn't
On Thu, Jul 25, 2024 at 08:35:40PM +0100, David Woodhouse wrote:
> On Thu, 2024-07-25 at 12:38 -0400, Michael S. Tsirkin wrote:
> > On Thu, Jul 25, 2024 at 04:18:43PM +0100, David Woodhouse wrote:
> > > The use case isn't necessarily for all users of gettimeofday(), of
> > > course; this is for
On 25.07.24 22:15, Steven Rostedt wrote:
> On Thu, 25 Jul 2024 21:42:41 +0200
> Mathias Krause wrote:
>
>> Right. But the point is, that 'event_call' is really some '>call'.
>> With 'user' being free'd memory, what gives? Dereferencing 'event_call'
>> is UB, so this function is doomed to fail
On Thu, 25 Jul 2024 21:42:41 +0200
Mathias Krause wrote:
> Right. But the point is, that 'event_call' is really some '>call'.
> With 'user' being free'd memory, what gives? Dereferencing 'event_call'
> is UB, so this function is doomed to fail because it cannot know if its
> only argument points
On 25.07.24 21:05, Steven Rostedt wrote:
> Here's the proper fix:
>
> diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
> index 6ef29eba90ce..3a2d2ff1625b 100644
> --- a/kernel/trace/trace_events.c
> +++ b/kernel/trace/trace_events.c
> @@ -3140,8 +3140,10 @@
On 25.07.24 21:05, Steven Rostedt wrote:
> On Thu, 25 Jul 2024 20:12:33 +0200
> Mathias Krause wrote:
@@ -973,6 +975,11 @@ size_t copy_nofault(void *addr, size_t bytes, struct
iov_iter *i)
static struct list_head *user_event_get_fields(struct trace_event_call
*call)
{
On Thu, 2024-07-25 at 12:38 -0400, Michael S. Tsirkin wrote:
> On Thu, Jul 25, 2024 at 04:18:43PM +0100, David Woodhouse wrote:
> > The use case isn't necessarily for all users of gettimeofday(), of
> > course; this is for those applications which *need* precision time.
> > Like distributed
Hello Lucas,
On 2024-07-25 19:18, Lucas De Marchi wrote:
On Thu, Jul 25, 2024 at 04:39:40PM GMT, Steven Price wrote:
On 25/07/2024 15:29, Lucas De Marchi wrote:
On Thu, Jul 25, 2024 at 01:37:46PM GMT, Dragan Simic wrote:
Panfrost and Lima DRM drivers use devfreq to perform DVFS, which is
On Thu, 25 Jul 2024 20:12:33 +0200
Mathias Krause wrote:
>
> >
> >> +
> >>if (WARN_ON_ONCE(!schedule_work(>put_work))) {
> >>/*
> >> * If we fail we must wait for an admin to attempt delete or
> >> @@ -973,6 +975,11 @@ size_t copy_nofault(void *addr, size_t bytes,
On 25.07.24 19:16, Steven Rostedt wrote:
> On Thu, 25 Jul 2024 13:10:21 -0400
> Steven Rostedt wrote:
>>
>> diff --git a/kernel/trace/trace_events_user.c
>> b/kernel/trace/trace_events_user.c
>> index 3a2b46847c8b..e9ed2826ff46 100644
>> --- a/kernel/trace/trace_events_user.c
>> +++
On Thu, Jul 25, 2024 at 09:31:04AM +0800, Cindy Lu wrote:
> Add the function to support setting the MAC address.
> For vdpa/mlx5, the function will use mlx5_mpfs_add_mac
> to set the mac address
>
> Tested in ConnectX-6 Dx device
>
> Signed-off-by: Cindy Lu
> ---
>
On Thu, Jul 25, 2024 at 09:31:02AM +0800, Cindy Lu wrote:
[...]
> diff --git a/drivers/vdpa/vdpa.c b/drivers/vdpa/vdpa.c
> index 8d391947eb8d..532cf3b52b26 100644
> --- a/drivers/vdpa/vdpa.c
> +++ b/drivers/vdpa/vdpa.c
> @@ -1361,6 +1361,81 @@ static int vdpa_nl_cmd_dev_config_get_doit(struct
>
On Thu, Jul 25, 2024 at 09:31:01AM +0800, Cindy Lu wrote:
> Add support for setting the MAC address using the VDPA tool.
> This feature will allow setting the MAC address using the VDPA tool.
> For example, in vdpa_sim_net, the implementation sets the MAC address
> to the config space. However,
On Thu, Jul 25, 2024 at 04:39:40PM GMT, Steven Price wrote:
On 25/07/2024 15:29, Lucas De Marchi wrote:
On Thu, Jul 25, 2024 at 01:37:46PM GMT, Dragan Simic wrote:
Panfrost and Lima DRM drivers use devfreq to perform DVFS, which is
supported
on the associated platforms, while using
On Thu, 25 Jul 2024 13:10:21 -0400
Steven Rostedt wrote:
>
> diff --git a/kernel/trace/trace_events_user.c
> b/kernel/trace/trace_events_user.c
> index 3a2b46847c8b..e9ed2826ff46 100644
> --- a/kernel/trace/trace_events_user.c
> +++ b/kernel/trace/trace_events_user.c
> @@ -321,6 +321,8 @@
On Thu, 25 Jul 2024 22:00:14 +0530
Ajay Kaher wrote:
> Thread A (read event) Thread B (remove event)
>
> . worker_thread()
> . delayed_destroy_user_event()
> .
On Thu, 25 Jul 2024 21:45:03 +0530
Ajay Kaher wrote:
> On Mon, Jul 22, 2024 at 5:38 PM Mathias Krause wrote:
> >
> > On 22.07.24 13:13, Ajay Kaher wrote:
> > > On Sat, Jul 20, 2024 at 2:17 AM Mathias Krause
> > > wrote:
> > >>
> > >> I noticed, the user events ftrace selftest is crashing
On Thu, Jul 25, 2024 at 04:18:43PM +0100, David Woodhouse wrote:
> On Thu, 2024-07-25 at 10:11 -0400, Michael S. Tsirkin wrote:
> > On Thu, Jul 25, 2024 at 02:50:50PM +0100, David Woodhouse wrote:
> > > Even if the virtio-rtc specification were official today, and I was
> > > able to expose it via
On Thu, Jul 25, 2024 at 9:45 PM Ajay Kaher wrote:
>
> On Mon, Jul 22, 2024 at 5:38 PM Mathias Krause wrote:
> >
> > On 22.07.24 13:13, Ajay Kaher wrote:
> > > On Sat, Jul 20, 2024 at 2:17 AM Mathias Krause
> > > wrote:
> > >>
> > >> I noticed, the user events ftrace selftest is crashing every
On Mon, Jul 22, 2024 at 5:38 PM Mathias Krause wrote:
>
> On 22.07.24 13:13, Ajay Kaher wrote:
> > On Sat, Jul 20, 2024 at 2:17 AM Mathias Krause
> > wrote:
> >>
> >> I noticed, the user events ftrace selftest is crashing every now and
> >> then in our automated tests. Digging into, I found
On 25/07/2024 15:29, Lucas De Marchi wrote:
> On Thu, Jul 25, 2024 at 01:37:46PM GMT, Dragan Simic wrote:
>> Panfrost and Lima DRM drivers use devfreq to perform DVFS, which is
>> supported
>> on the associated platforms, while using simple_ondemand devfreq
>> governor by
>> default. This makes
Hello Lucas,
On 2024-07-25 16:29, Lucas De Marchi wrote:
On Thu, Jul 25, 2024 at 01:37:46PM GMT, Dragan Simic wrote:
Panfrost and Lima DRM drivers use devfreq to perform DVFS, which is
supported
on the associated platforms, while using simple_ondemand devfreq
governor by
default. This makes
On Thu, 2024-07-25 at 10:11 -0400, Michael S. Tsirkin wrote:
> On Thu, Jul 25, 2024 at 02:50:50PM +0100, David Woodhouse wrote:
> > Even if the virtio-rtc specification were official today, and I was
> > able to expose it via PCI, I probably wouldn't do it that way. There's
> > just far more in
On Wed, 24 Jul 2024 at 16:04, Tanmay Shah wrote:
>
> Hello Mathieu,
>
> Thanks for reviews.
>
> All the comments looks good, I will send next revision addressing them all.
>
> On 7/22/24 11:39 AM, Mathieu Poirier wrote:
> > Good morning,
> >
> > On Mon, Jul 15, 2024 at 06:39:54PM -0700, Tanmay
Miroslav Benes writes:
>
> Do we still need klp_state->data member? Now that it can be easily coupled
> with shadow variables, is there a reason to preserve it?
I would say yes, it could point to e.g. some lock protecting an
associated shadow variable's usage. Or be used to conveniently pass
On Thu, Jul 25, 2024 at 01:37:46PM GMT, Dragan Simic wrote:
Panfrost and Lima DRM drivers use devfreq to perform DVFS, which is supported
on the associated platforms, while using simple_ondemand devfreq governor by
default. This makes the simple_ondemand module a hard dependency for both
Hi Petr,
On Fri, 10 Nov 2023, Petr Mladek wrote:
> This POC is a material for the discussion "Simplify Livepatch Callbacks,
> Shadow Variables, and States handling" at LPC 2013, see
> https://lpc.events/event/17/contributions/1541/
>
> It obsoletes the patchset adding the garbage collection of
On Fri, 10 Nov 2023, Josh Poimboeuf wrote:
> On Fri, Nov 10, 2023 at 06:04:21PM +0100, Petr Mladek wrote:
> > This POC is a material for the discussion "Simplify Livepatch Callbacks,
> > Shadow Variables, and States handling" at LPC 2013, see
> > https://lpc.events/event/17/contributions/1541/
>
On Fri, 10 Nov 2023, Petr Mladek wrote:
> The livepatch state API was added to help with maintaining:
>
>+ changes done by livepatch callbasks
>+ lifetime of shadow variables
>
> The original API was hard to use. Both objectives are better handled
> by the new per-state callbacks. They
On Thu, Jul 25, 2024 at 02:50:50PM +0100, David Woodhouse wrote:
> Even if the virtio-rtc specification were official today, and I was
> able to expose it via PCI, I probably wouldn't do it that way. There's
> just far more in virtio-rtc than we need; the simple shared memory
> region is perfectly
On Thu, 2024-07-25 at 08:33 -0400, Michael S. Tsirkin wrote:
> On Thu, Jul 25, 2024 at 01:31:19PM +0100, David Woodhouse wrote:
> > On Thu, 2024-07-25 at 08:29 -0400, Michael S. Tsirkin wrote:
> > > On Thu, Jul 25, 2024 at 01:27:49PM +0100, David Woodhouse wrote:
> > > > On Thu, 2024-07-25 at
On Mon, Jul 22, 2024 at 5:38 PM Mathias Krause wrote:
>
> On 22.07.24 13:13, Ajay Kaher wrote:
> > On Sat, Jul 20, 2024 at 2:17 AM Mathias Krause
> > wrote:
> >>
> >> I noticed, the user events ftrace selftest is crashing every now and
> >> then in our automated tests. Digging into, I found
Hello:
This patch was applied to riscv/linux.git (for-next)
by Palmer Dabbelt :
On Thu, 13 Jun 2024 19:13:47 +0800 you wrote:
> Since commit 7caa9765465f60 ("ftrace: riscv: move from REGS to ARGS"),
> kprobe on ftrace is not supported by riscv, because riscv's support for
> FTRACE_WITH_REGS has
On 25/07/2024 12:37, Dragan Simic wrote:
> Panfrost and Lima DRM drivers use devfreq to perform DVFS, which is supported
> on the associated platforms, while using simple_ondemand devfreq governor by
> default. This makes the simple_ondemand module a hard dependency for both
> Panfrost and Lima,
On 7/22/24 12:23, Masahiro Yamada wrote:
> On Mon, Jul 22, 2024 at 6:07 PM Petr Pavlu wrote:
>>
>> The kernel configuration allows specifying a module compression mode. If
>> one is selected then each module gets compressed during
>> 'make modules_install' and additionally one can also enable
On Thu, Jul 25, 2024 at 01:31:19PM +0100, David Woodhouse wrote:
> On Thu, 2024-07-25 at 08:29 -0400, Michael S. Tsirkin wrote:
> > On Thu, Jul 25, 2024 at 01:27:49PM +0100, David Woodhouse wrote:
> > > On Thu, 2024-07-25 at 08:17 -0400, Michael S. Tsirkin wrote:
> > > > On Thu, Jul 25, 2024 at
On Thu, 2024-07-25 at 08:29 -0400, Michael S. Tsirkin wrote:
> On Thu, Jul 25, 2024 at 01:27:49PM +0100, David Woodhouse wrote:
> > On Thu, 2024-07-25 at 08:17 -0400, Michael S. Tsirkin wrote:
> > > On Thu, Jul 25, 2024 at 10:56:05AM +0100, David Woodhouse wrote:
> > > > > Do you want to just help
On Thu, Jul 25, 2024 at 01:27:49PM +0100, David Woodhouse wrote:
> On Thu, 2024-07-25 at 08:17 -0400, Michael S. Tsirkin wrote:
> > On Thu, Jul 25, 2024 at 10:56:05AM +0100, David Woodhouse wrote:
> > > > Do you want to just help complete virtio-rtc then? Would be easier than
> > > > trying to
Function kvm_arch_para_features() is to detect supported paravirt features,
it can be used by device driver to detect and enable paravirt features,
such as extioi irqchip driver can detect KVM_FEATURE_VIRT_EXTIOI and do
some optimization.
Signed-off-by: Bibo Mao
---
Export kernel paravirt features to user space, so that VMM can control
the single paravirt feature. By default paravirt features will the same
with kvm supported features if VMM does not set it.
Also a new feature KVM_FEATURE_VIRT_EXTIOI is added which can be set from
user space. This feature
KVM_FEATURE_VIRT_EXTIOI is paravirt feature defined with EXTIOI
interrupt controller, it can route interrupt to 256 CPUs and cpu
interface IP0-IP7. Now irqchip is emulated in user space rather than
kernel space, here interface is provide for VMM to pass it to KVM
hyperviso.
Also interface is
On Thu, 2024-07-25 at 08:17 -0400, Michael S. Tsirkin wrote:
> On Thu, Jul 25, 2024 at 10:56:05AM +0100, David Woodhouse wrote:
> > > Do you want to just help complete virtio-rtc then? Would be easier than
> > > trying to keep two specs in sync.
> >
> > The ACPI version is much more lightweight
> diff --git a/lib/livepatch/test_klp_speaker.c
> b/lib/livepatch/test_klp_speaker.c
> index d2d31072639a..d8e42267f5cd 100644
> --- a/lib/livepatch/test_klp_speaker.c
> +++ b/lib/livepatch/test_klp_speaker.c
> @@ -9,23 +9,174 @@
>
> #include
> #include
> +#include
> +#include
> +
>
On 2024/7/22 4:41, Alexander Duyck wrote:
> On Fri, Jul 19, 2024 at 2:37 AM Yunsheng Lin wrote:
>>
>> Currently the page_frag API is returning 'virtual address'
>> or 'va' when allocing and expecting 'virtual address' or
>> 'va' as input when freeing.
>>
>> As we are about to support new use
On Thu, Jul 25, 2024 at 10:56:05AM +0100, David Woodhouse wrote:
> > Do you want to just help complete virtio-rtc then? Would be easier than
> > trying to keep two specs in sync.
>
> The ACPI version is much more lightweight and doesn't take up a
> valuable PCI slot#. (I know, you can do virtio
On Thu, Jul 25, 2024 at 12:53:34PM +0100, David Woodhouse wrote:
> On Thu, 2024-07-25 at 12:31 +0100, Daniel P. Berrangé wrote:
> > On Thu, Jul 25, 2024 at 10:56:05AM +0100, David Woodhouse wrote:
> > > Hi Michael, thanks for the review!
> > >
> > > On Thu, 2024-07-25 at 01:48 -0400, Michael S.
On Thu, 2024-07-25 at 12:31 +0100, Daniel P. Berrangé wrote:
> On Thu, Jul 25, 2024 at 10:56:05AM +0100, David Woodhouse wrote:
> > Hi Michael, thanks for the review!
> >
> > On Thu, 2024-07-25 at 01:48 -0400, Michael S. Tsirkin wrote:
> > > Do you want to just help complete virtio-rtc then?
On Thu, 2024-07-25 at 13:20 +0200, Paolo Abeni wrote:
>
>
> Just a bunch of 'nits below
Thank you. Fixed in
https://git.infradead.org/users/dwmw2/linux.git/shortlog/refs/heads/vmclock
I'll post a new version once I've finished resolving mst's and any
other feedback.
smime.p7s
Description:
Hi,
On Fri, 10 Nov 2023, Petr Mladek wrote:
> Recent changes in the livepatch core have allowed to connect states,
> shadow variables, and callbacks. Use these new features in
> the state tests.
>
> Use the shadow variable API to store the original loglevel. It is
> better suited for this
Panfrost and Lima DRM drivers use devfreq to perform DVFS, which is supported
on the associated platforms, while using simple_ondemand devfreq governor by
default. This makes the simple_ondemand module a hard dependency for both
Panfrost and Lima, because the presence of the simple_ondemand
On Thu, Jul 25, 2024 at 10:56:05AM +0100, David Woodhouse wrote:
> Hi Michael, thanks for the review!
>
> On Thu, 2024-07-25 at 01:48 -0400, Michael S. Tsirkin wrote:
> > On Wed, Jul 24, 2024 at 06:16:37PM +0100, David Woodhouse wrote:
> > > From: David Woodhouse
> > >
> > > The vmclock
> diff --git a/kernel/livepatch/state.c b/kernel/livepatch/state.c
> index 6693d808106b..4ec65afe3a43 100644
> --- a/kernel/livepatch/state.c
> +++ b/kernel/livepatch/state.c
> @@ -198,11 +198,17 @@ void klp_release_states(struct klp_patch *patch)
> if
Hi,
Just a bunch of 'nits below
On 7/24/24 19:16, David Woodhouse wrote:
diff --git a/drivers/ptp/ptp_vmclock.c b/drivers/ptp/ptp_vmclock.c
new file mode 100644
index ..9c508c21c062
--- /dev/null
+++ b/drivers/ptp/ptp_vmclock.c
[...]
+/*
+ * Multiply a 64-bit count by a 64-bit
On 25.07.2024 3:42 AM, Dang Huynh wrote:
> Fxtec Pro1x uses the same display (BOE BF060Y8M-AJ0) as Pro1.
>
> Signed-off-by: Dang Huynh
> ---
Reviewed-by: Konrad Dybcio
Konrad
On 25.07.2024 3:42 AM, Dang Huynh wrote:
> Fxtec Pro1X has two card slots and allow either 2xSIM cards or
> 1xSIM, 1xSD Card configuration.
>
> Signed-off-by: Dang Huynh
> ---
Reviewed-by: Konrad Dybcio
Konrad
On 25.07.2024 3:42 AM, Dang Huynh wrote:
> The Pro1X has a caps lock LED on the keyboard.
>
> Signed-off-by: Dang Huynh
> ---
Reviewed-by: Konrad Dybcio
Konrad
On 25.07.2024 3:42 AM, Dang Huynh wrote:
> Enable onboard Wi-Fi on the F(x)tec Pro1X.
>
> For reference, HW/SW identifies as:
> qmi chip_id 0x120 chip_family 0x4007 board_id 0xff soc_id 0x4067
> qmi fw_version 0x324103d6 fw_build_timestamp 2021-12-02 08:20
> fw_build_id
On Thu, 2024-07-25 at 01:54 -0400, Michael S. Tsirkin wrote:
> one other thing worth mentioning is that this design can't work
> with confidential computing setups. By comparison, mapping e.g. a
> range in a PCI BAR would work for these setups.
Why so? This is just like mapping a PCI BAR, isn't
Hi Michael, thanks for the review!
On Thu, 2024-07-25 at 01:48 -0400, Michael S. Tsirkin wrote:
> On Wed, Jul 24, 2024 at 06:16:37PM +0100, David Woodhouse wrote:
> > From: David Woodhouse
> >
> > The vmclock "device" provides a shared memory region with precision clock
> > information. By
On Wed, Jul 24, 2024 at 06:16:37PM +0100, David Woodhouse wrote:
> From: David Woodhouse
>
> The vmclock "device" provides a shared memory region with precision clock
> information. By using shared memory, it is safe across Live Migration.
>
> Like the KVM PTP clock, this can convert TSC-based
On Wed, Jul 24, 2024 at 06:16:37PM +0100, David Woodhouse wrote:
> From: David Woodhouse
>
> The vmclock "device" provides a shared memory region with precision clock
> information. By using shared memory, it is safe across Live Migration.
>
> Like the KVM PTP clock, this can convert TSC-based
On 5/07/2024 7:45 pm, Dmitrii Kuvaiskii wrote:
SGX_ENCL_PAGE_BEING_RECLAIMED flag is set when the enclave page is being
reclaimed (moved to the backing store). This flag however has two
logical meanings:
1. Don't attempt to load the enclave page (the page is busy).
2. Don't attempt to remove
Enable onboard Wi-Fi on the F(x)tec Pro1X.
For reference, HW/SW identifies as:
qmi chip_id 0x120 chip_family 0x4007 board_id 0xff soc_id 0x4067
qmi fw_version 0x324103d6 fw_build_timestamp 2021-12-02 08:20
fw_build_id QC_IMAGE_VERSION_STRING=WLAN.HL.3.2.4-00982-QCAHLSWMTPLZ-1
Signed-off-by:
Enable [A,C]DSP and MPSS remote processor on this device.
Reviewed-by: Konrad Dybcio
Signed-off-by: Dang Huynh
---
arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
This device has an RGB LED. It is used for notifications.
Reviewed-by: Konrad Dybcio
Signed-off-by: Dang Huynh
---
arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts | 27 +
1 file changed, 27 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
The USB-C port is used for powering external devices and transfer
data from/to them.
Reviewed-by: Konrad Dybcio
Signed-off-by: Dang Huynh
---
arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts | 51 +++--
1 file changed, 48 insertions(+), 3 deletions(-)
diff --git
The Pro1X has a caps lock LED on the keyboard.
Signed-off-by: Dang Huynh
---
arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
b/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
The F(x)tec Pro1X supports USB 3.0 through it's USB-C port.
Reviewed-by: Konrad Dybcio
Signed-off-by: Dang Huynh
---
arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
Fxtec Pro1x uses the same display (BOE BF060Y8M-AJ0) as Pro1.
Signed-off-by: Dang Huynh
---
arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts | 60 +++--
1 file changed, 56 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
Fxtec Pro1X has two card slots and allow either 2xSIM cards or
1xSIM, 1xSD Card configuration.
Signed-off-by: Dang Huynh
---
arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts | 32 +
1 file changed, 32 insertions(+)
diff --git
The Fxtec Pro1X touchscreen uses Goodix GT9286 chip.
Signed-off-by: Dang Huynh
---
arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts | 49 +
1 file changed, 49 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
201 - 300 of 4335962 matches
Mail list logo
