On Thu, Sep 08, 2022 at 10:17:12AM -0500, Scott Cheloha wrote:
> > On Sep 8, 2022, at 9:05 AM, Mike Larkin wrote:
> > [...]
> >
> > You could compile this and then objdump -D it and see for yourself...
>
> I can't make heads or tails of it. Please explain what I am looking
> at and why it is, o
y wrote:
>>>>>>>>
>>>>>>>> ???On Fri, Sep 02, 2022 at 06:00:25PM -0500, Scott Cheloha wrote:
>>>>>>>>> dv@ suggested coming to the list to request testing for the pvclock(4)
>>>>>>>>> driver. A
t 02:22, Jonathan Gray wrote:
>>>>>>>>
>>>>>>>> ???On Fri, Sep 02, 2022 at 06:00:25PM -0500, Scott Cheloha wrote:
>>>>>>>>> dv@ suggested coming to the list to request testing for the pvclock(4)
>>>>>>
t; > > > > ???On Fri, Sep 02, 2022 at 06:00:25PM -0500, Scott Cheloha wrote:
> > > > > > >> dv@ suggested coming to the list to request testing for the
> > > > > > >> pvclock(4)
> > > > > > >> driver. Attached is a pat
; > ???On Fri, Sep 02, 2022 at 06:00:25PM -0500, Scott Cheloha wrote:
> > > > > > >> dv@ suggested coming to the list to request testing for the
> > > > > > >> pvclock(4)
> > > > > > >> driver. Attached is a patch that c
; > ???On Fri, Sep 02, 2022 at 06:00:25PM -0500, Scott Cheloha wrote:
> > > > > > >> dv@ suggested coming to the list to request testing for the
> > > > > > >> pvclock(4)
> > > > > > >> driver. Attached is a patch that c
gt; On Sat, Sep 03, 2022 at 06:52:20AM -0500, Scott Cheloha wrote:
> > > > > > On Sep 3, 2022, at 02:22, Jonathan Gray wrote:
> > > > > >
> > > > > > ???On Fri, Sep 02, 2022 at 06:00:25PM -0500, Scott Cheloha wrote:
> > &g
gt; > On Sep 3, 2022, at 02:22, Jonathan Gray wrote:
> > > > >
> > > > > ???On Fri, Sep 02, 2022 at 06:00:25PM -0500, Scott Cheloha wrote:
> > > > >> dv@ suggested coming to the list to request testing for the
> > > > >> pvclo
> > > ???On Fri, Sep 02, 2022 at 06:00:25PM -0500, Scott Cheloha wrote:
> > > >> dv@ suggested coming to the list to request testing for the pvclock(4)
> > > >> driver. Attached is a patch that corrects several bugs. Most of
> > > >>
> >> dv@ suggested coming to the list to request testing for the pvclock(4)
> > >> driver. Attached is a patch that corrects several bugs. Most of
> > >> these changes will only matter in the non-TSC_STABLE case on a
> > >> multiprocessor VM.
> >
gt;> dv@ suggested coming to the list to request testing for the pvclock(4)
>>>> driver. Attached is a patch that corrects several bugs. Most of
>>>> these changes will only matter in the non-TSC_STABLE case on a
>>>> multiprocessor VM.
>>>>
>>
On Sat, Sep 03, 2022 at 06:52:20AM -0500, Scott Cheloha wrote:
> > On Sep 3, 2022, at 02:22, Jonathan Gray wrote:
> >
> > On Fri, Sep 02, 2022 at 06:00:25PM -0500, Scott Cheloha wrote:
> >> dv@ suggested coming to the list to request testing for the pvclock(4)
> &
> On Sep 3, 2022, at 02:22, Jonathan Gray wrote:
>
> On Fri, Sep 02, 2022 at 06:00:25PM -0500, Scott Cheloha wrote:
>> dv@ suggested coming to the list to request testing for the pvclock(4)
>> driver. Attached is a patch that corrects several bugs. Most of
>> these
On Fri, Sep 02, 2022 at 06:00:25PM -0500, Scott Cheloha wrote:
> dv@ suggested coming to the list to request testing for the pvclock(4)
> driver. Attached is a patch that corrects several bugs. Most of
> these changes will only matter in the non-TSC_STABLE case on a
> multi
On Fri, Sep 02, 2022 at 06:00:25PM -0500, Scott Cheloha wrote:
> dv@ suggested coming to the list to request testing for the pvclock(4)
> driver. Attached is a patch that corrects several bugs. Most of
> these changes will only matter in the non-TSC_STABLE case on a
> multi
On Fri, Sep 02, 2022 at 06:00:25PM -0500, Scott Cheloha wrote:
> dv@ suggested coming to the list to request testing for the pvclock(4)
> driver. Attached is a patch that corrects several bugs. Most of
> these changes will only matter in the non-TSC_STABLE case on a
> multi
dv@ suggested coming to the list to request testing for the pvclock(4)
driver. Attached is a patch that corrects several bugs. Most of
these changes will only matter in the non-TSC_STABLE case on a
multiprocessor VM.
Ideally, nothing should break.
- pvclock yields a 64-bit value. The BSD
On 2018 Dec 04 (Tue) at 15:14:51 +0100 (+0100), Reyk Floeter wrote:
:On Tue, Dec 04, 2018 at 05:43:48AM -0800, Chris Cappuccio wrote:
:> Of course printf instead of panic for testers
:>
:
:Oh, right, thanks!
:
:@john: Does this "slightly less simple" diff work for you?
:
:@phessler, Chris: Maybe
Reyk Floeter 於 2018-12-04 22:14 寫到:
On Tue, Dec 04, 2018 at 05:43:48AM -0800, Chris Cappuccio wrote:
Of course printf instead of panic for testers
Oh, right, thanks!
@john: Does this "slightly less simple" diff work for you?
Hi Reyk,
Yes, your patch also work for me, I can boot without m
On Tue, Dec 04, 2018 at 05:43:48AM -0800, Chris Cappuccio wrote:
> Of course printf instead of panic for testers
>
Oh, right, thanks!
@john: Does this "slightly less simple" diff work for you?
@phessler, Chris: Maybe we should get this fix tested and in, wait for
reports, and I can use the ti
On Tue, Dec 04, 2018 at 12:46:06PM +0100, Peter Hessler wrote:
> On 2018 Dec 03 (Mon) at 16:56:10 -0800 (-0800), Chris Cappuccio wrote:
> :Reyk Floeter [r...@openbsd.org] wrote:
> :>
> :> Yes, KVM???s stable bit is not a reliable indication as it is seems to
> depend on the capabilities of the KVM
On Mon, Dec 03, 2018 at 04:56:10PM -0800, Chris Cappuccio wrote:
> Reyk Floeter [r...@openbsd.org] wrote:
> >
> > Yes, KVM???s stable bit is not a reliable indication as it is seems to
> > depend on the capabilities of the KVM version and not the actual
> > availability of the feature on the part
On 2018 Dec 03 (Mon) at 16:56:10 -0800 (-0800), Chris Cappuccio wrote:
:Reyk Floeter [r...@openbsd.org] wrote:
:>
:> Yes, KVM???s stable bit is not a reliable indication as it is seems to
depend on the capabilities of the KVM version and not the actual availability
of the feature on the particula
Chris Cappuccio 於 2018-12-04 08:56 寫到:
Reyk Floeter [r...@openbsd.org] wrote:
Yes, KVM???s stable bit is not a reliable indication as it is seems to
depend on the capabilities of the KVM version and not the actual
availability of the feature on the particular hardware. How annoying.
As ment
Reyk Floeter [r...@openbsd.org] wrote:
>
> Yes, KVM???s stable bit is not a reliable indication as it is seems to depend
> on the capabilities of the KVM version and not the actual availability of the
> feature on the particular hardware. How annoying.
>
> As mentioned before: I???d like to disab
> Am 04.12.2018 um 00:52 schrieb Chris Cappuccio :
>
> johnw [johnw.m...@gmail.com] wrote:
>>
>> Hi, after disable pvclock, it can boot with new kernel again, thanks.
> ...
>> cpu0: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz, 105.29 MHz, 06-17-0a
>> cpu0:
>> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,
johnw [johnw.m...@gmail.com] wrote:
>
> Hi, after disable pvclock, it can boot with new kernel again, thanks.
...
> cpu0: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz, 105.29 MHz, 06-17-0a
> cpu0:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,
johnw 於 2018-11-29 17:38 寫到:
Reyk Floeter 於 2018-11-29 14:09 寫到:
Do you have a full dmesg for me?
Yes, attached dmesg.log, thanks.
Hi, after disable pvclock, it can boot with new kernel again, thanks.
--
Key fingerprint: CDB3 6C62 254B C088 1E5D DD32 182C 97DB CF2C 80AC
OpenBSD 6.4-curre
Reyk Floeter 於 2018-11-29 14:09 寫到:
Do you have a full dmesg for me?
Yes, attached dmesg.log, thanks.
--
Key fingerprint: CDB3 6C62 254B C088 1E5D DD32 182C 97DB CF2C 80AC
OpenBSD 6.4-current (GENERIC.MP) #447: Sun Nov 18 17:25:58 MST 2018
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd6
Hi,
> Am 29.11.2018 um 05:27 schrieb johnw :
>
>
>> So far I only got positive reports. Where are the problems? ;)
>
>> Otherwise: OK?
>
>> Reyk
>
> Hi, my kvm/quest/openbsd-amd64 can not boot, after upgrade to today current
> (28-nov-2018).
>
thanks for reporting.
Do you have a full dme
So far I only got positive reports. Where are the problems? ;)
Otherwise: OK?
Reyk
Hi, my kvm/quest/openbsd-amd64 can not boot, after upgrade to today
current (28-nov-2018).
It work before upgrade (OpenBSD 6.4-current (GENERIC.MP) #447: Sun Nov
18 17:25:58 MST 2018)
Host: 4.18.0-
n stable clock
>
> The host is running
> OpenBSD 6.4-current (GENERIC.MP) #456: Tue Nov 20 08:46:59 MST 2018
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>
> The VM kernel at the time was built at "zap 10 tab leading whitespace before
> 'str
.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
The VM kernel at the time was built at "zap 10 tab leading whitespace
before 'struct evp_pkey_ctx_st {'", so maybe "only attach pvclock(4) inside
a KVM guest" would've fixed it?
Thanks
Greg
; the attached diff is another attempt at implementing a pvclock(4)
> > > > guest driver. This improves the clock on KVM and replaces the need
> > > > for using the VM-expensive acpihpet(4).
> > > >
> > >
> > > So far I only got positiv
On Thu, Nov 22, 2018 at 07:44:01AM -0800, Mike Larkin wrote:
> On Thu, Nov 22, 2018 at 04:37:49PM +0100, Reyk Floeter wrote:
> > On Mon, Nov 19, 2018 at 01:12:46PM +0100, Reyk Floeter wrote:
> > > the attached diff is another attempt at implementing a pvclock(4)
> > > g
On Thu, Nov 22, 2018 at 04:37:49PM +0100, Reyk Floeter wrote:
> On Mon, Nov 19, 2018 at 01:12:46PM +0100, Reyk Floeter wrote:
> > the attached diff is another attempt at implementing a pvclock(4)
> > guest driver. This improves the clock on KVM and replaces the need
> > for u
On Mon, Nov 19, 2018 at 01:12:46PM +0100, Reyk Floeter wrote:
> the attached diff is another attempt at implementing a pvclock(4)
> guest driver. This improves the clock on KVM and replaces the need
> for using the VM-expensive acpihpet(4).
>
So far I only got positive reports. W
On Mon, Nov 19, 2018 at 01:12:46PM +0100, Reyk Floeter wrote:
> Hi,
>
> the attached diff is another attempt at implementing a pvclock(4)
> guest driver. This improves the clock on KVM and replaces the need
> for using the VM-expensive acpihpet(4).
>
> While pvclock(4) is
Reyk Floeter(r...@openbsd.org) on 2018.11.19 13:12:46 +0100:
> Feedback? Tests? OKs?
test on my incarnation of kvm:
OpenBSD 6.4-current (GENERIC.MP) #0: Mon Nov 19 18:32:29 CET 2018
ben...@test.openbsd.fluchtwagenfahrer.de:/sys/arch/amd64/compile/GENERIC.MP
real mem = 2097004544 (1999MB)
avai
Hi,
the attached diff is another attempt at implementing a pvclock(4)
guest driver. This improves the clock on KVM and replaces the need
for using the VM-expensive acpihpet(4).
While pvclock(4) is available on KVM, Xen, Hyper-V (in a modified
form), it currently only attaches under KVM:
pvbus0
40 matches
Mail list logo