Boqun Feng writes:
> Similar to x86, add a new vclock_mode VCLOCK_HVCLOCK, and reuse the
> hv_read_tsc_page() for userspace to read tsc page clocksource.
>
> Signed-off-by: Boqun Feng (Microsoft)
> ---
> arch/arm64/include/asm/clocksource.h | 3 ++-
> arch/arm64/include/asm/mshyperv.h
f7d ("xen-netfront: Fix race between device setup and open")
Signed-off-by: Vitaly Kuznetsov
---
drivers/net/xen-netfront.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index a57daecf1d57..1b40b648ed5c 100644
we need to make this node writable.
Signed-off-by: Vitaly Kuznetsov
---
- Linux code will need to be modified too. With this patch we get something
like
sysrq: SysRq : Emergency Sync
xen:manage: Error -34 reading sysrq code in control/sysrq
Emergency Sync complete
This new ERANGE fault happens b
Wei Liu writes:
> On Tue, Sep 04, 2018 at 01:39:29PM +0200, Vitaly Kuznetsov wrote:
>> 'xl sysrq' command doesn't work with modern Linux guests with the following
>> message in guest's log:
>>
>> xen:manage: sysrq_handler: Error -13 writing sysrq
Wei Liu writes:
> Also CC Linux maintainers.
>
> On Tue, Sep 04, 2018 at 07:27:31PM +0200, Vitaly Kuznetsov wrote:
>> Wei Liu writes:
>>
>> > On Tue, Sep 04, 2018 at 01:39:29PM +0200, Vitaly Kuznetsov wrote:
>> >> 'xl sysrq' co
rgency Sync complete
xen:manage: Error -34 reading sysrq code in control/sysrq
Ignore -ERANGE the same way we already ignore -ENOENT, empty value in
control/sysrq is totally legal.
Signed-off-by: Vitaly Kuznetsov
---
This is a follow-up to my Xen toolstack patch:
https://lists.xenproject.org/archives/ht
Roger Pau Monne writes:
> And instead use NOW which is based on the TSC. This was already used
> when running in shim mode, since there's likely no PIT in that
> environment.
>
> Remove printing the CPU frequency, since it's already printed earlier
> at boot, and getting the CPU frequency against
David Hildenbrand writes:
> On 02/10/2018 15:47, Michal Hocko wrote:
...
>>
>> Why do you need a generic hotplug rule in the first place? Why don't you
>> simply provide different set of rules for different usecases? Let users
>> decide which usecase they prefer rather than try to be clever whic
Michal Hocko writes:
> On Wed 03-10-18 15:38:04, Vitaly Kuznetsov wrote:
>> David Hildenbrand writes:
>>
>> > On 02/10/2018 15:47, Michal Hocko wrote:
>> ...
>> >>
>> >> Why do you need a generic hotplug rule in the first place? Why don
Dave Hansen writes:
> On 10/03/2018 06:52 AM, Vitaly Kuznetsov wrote:
>> It is more than just memmaps (e.g. forking udev process doing memory
>> onlining also needs memory) but yes, the main idea is to make the
>> onlining synchronous with hotplug.
>
> That's a g
Ajay Kaher writes:
> During boot-time there are many PCI config reads, these could be performed
> either using Port IO instructions (PIO) or memory mapped I/O (MMIO).
>
> PIO are less efficient than MMIO, they require twice as many PCI accesses
> and PIO instructions are serializing. As a result,
Ajay Kaher writes:
> Note: Corrected the Subject.
>
>> On 07/09/22, 8:50 PM, "Vitaly Kuznetsov" wrote:
>>
>>> diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
>>> index ddb7986..1e5a8f7 100644
>>> --- a/arch/x86/pci/comm
I'm observing a deadlock every time I try to unplug a xen-blkfront
device. With 5.14-rc1+ the deadlock looks like:
[ 513.682405]
[ 513.686617] WARNING: possible recursive locking detected
[ 513.691020] 5.14.0-rc1+ #370 Not tainted
[ 513.694272]
Christoph Hellwig writes:
> On Thu, Jul 15, 2021 at 11:16:30AM +0200, Vitaly Kuznetsov wrote:
>> I'm observing a deadlock every time I try to unplug a xen-blkfront
>> device. With 5.14-rc1+ the deadlock looks like:
>
> I did actually stumble over this a few days ago j
Christoph Hellwig writes:
> On Thu, Jul 15, 2021 at 03:17:37PM +0200, Vitaly Kuznetsov wrote:
>> Christoph Hellwig writes:
>>
>> > On Thu, Jul 15, 2021 at 11:16:30AM +0200, Vitaly Kuznetsov wrote:
>> >> I'm observing a deadlock every time I try to unpl
Tianyu Lan writes:
> From: Tianyu Lan
>
> Add new hvcall guest address host visibility support. Mark vmbus
> ring buffer visible to host when create gpadl buffer and mark back
> to not visible when tear down gpadl buffer.
>
> Co-developed-by: Sunil Muthuswamy
> Signed-off-by: Tianyu Lan
> ---
Tianyu Lan writes:
> From: Tianyu Lan
>
> In Isolation VM, all shared memory with host needs to mark visible
> to host via hvcall. vmbus_establish_gpadl() has already done it for
> netvsc rx/tx ring buffer. The page buffer used by vmbus_sendpacket_
> pagebuffer() still need to handle. Use DMA AP
Dongli Zhang writes:
> As mentioned in the linux kernel development document, "sched_clock() is
> used for scheduling and timestamping". While there is a default native
> implementation, many paravirtualizations have their own implementations.
>
> About KVM, it uses kvm_sched_clock_read() and the
Ajay Kaher writes:
>> On 13/09/22, 7:05 PM, "Vitaly Kuznetsov" wrote:
>>>
>>> Thanks Vitaly for your response.
>>>
>>> 1. we have multiple objects of struct pci_raw_ops, 2. adding 'priority'
>>> field to struct pci_raw
Nadav Amit writes:
> On Oct 3, 2022, at 8:03 AM, Vitaly Kuznetsov wrote:
>
>> Not my but rather PCI maintainer's call but IMHO dropping 'const' is
>> better, introducing a new global var is our 'last resort' and should be
>> avoide
Alexander Potapenko writes:
> Hi,
>
> While investigating KMSAN's incompatibilities with the default Ubuntu
> config (https://github.com/google/kmsan/issues/89#issuecomment-1310702949),
> I figured out that a kernel won't boot with both CONFIG_KMSAN=y and
> CONFIG_XEN_PV=y.
>
> In particular, it
21 matches
Mail list logo