search for: cr8

...wrote: >> On Jul 15, 2019, at 8:16 AM, Andrew Cooper <andrew.cooper3 at citrix.com> wrote: >> >> There is a lot of infrastructure for functionality which is used >> exclusively in __{save,restore}_processor_state() on the suspend/resume >> path. >> >> cr8 is an alias of APIC_TASKPRI, and APIC_TASKPRI is saved/restored by >> lapic_{suspend,resume}(). Saving and restoring cr8 independently of the >> rest of the Local APIC state isn't a clever thing to be doing. >> >> Delete the suspend/resume cr8 handling, which shrinks th...

...wrote: >> On Jul 15, 2019, at 8:16 AM, Andrew Cooper <andrew.cooper3 at citrix.com> wrote: >> >> There is a lot of infrastructure for functionality which is used >> exclusively in __{save,restore}_processor_state() on the suspend/resume >> path. >> >> cr8 is an alias of APIC_TASKPRI, and APIC_TASKPRI is saved/restored by >> lapic_{suspend,resume}(). Saving and restoring cr8 independently of the >> rest of the Local APIC state isn't a clever thing to be doing. >> >> Delete the suspend/resume cr8 handling, which shrinks th...

There is a lot of infrastructure for functionality which is used exclusively in __{save,restore}_processor_state() on the suspend/resume path. cr8 is an alias of APIC_TASKPRI, and APIC_TASKPRI is saved/restored by lapic_{suspend,resume}(). Saving and restoring cr8 independently of the rest of the Local APIC state isn't a clever thing to be doing. Delete the suspend/resume cr8 handling, which shrinks the size of struct saved_context, and...

There is a lot of infrastructure for functionality which is used exclusively in __{save,restore}_processor_state() on the suspend/resume path. cr8 is an alias of APIC_TASKPRI, and APIC_TASKPRI is saved/restored by lapic_{suspend,resume}(). Saving and restoring cr8 independently of the rest of the Local APIC state isn't a clever thing to be doing. Delete the suspend/resume cr8 handling, which shrinks the size of struct saved_context, and...

Any advice about the patch cr8-acceleration-3.patch? Hi Keir, could you give some comments? Thanks! -- Dexuan -----Original Message----- From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Cui, Dexuan Sent: 2006年10月25日 11:12 To: Keir.Fraser@cl.cam.ac.uk Cc: xen-devel@lists.xe...

This patch adds CR8 virtualization. It''s the initial patch for booting HVM x64 Windows guest, and just let every CR8 access issues vmexit. And later we will do acceleration to it. Signed-off-by: Xiaohui Xin <xiaohui.xin@intel.com> _______________________________________________ Xen-devel mailin...

...9, at 8:16 AM, Andrew Cooper <andrew.cooper3 at citrix.com> wrote: > >> > >> There is a lot of infrastructure for functionality which is used > >> exclusively in __{save,restore}_processor_state() on the suspend/resume > >> path. > >> > >> cr8 is an alias of APIC_TASKPRI, and APIC_TASKPRI is saved/restored by > >> lapic_{suspend,resume}(). Saving and restoring cr8 independently of the > >> rest of the Local APIC state isn't a clever thing to be doing. > >> > >> Delete the suspend/resume cr8 handli...

Thanks for your advice. I will re-organize the patch. Thanks -- Dexuan -----Original Message----- From: Li, Xin B Sent: 2006年10月24日 18:08 To: Petersson, Mats; Cui, Dexuan; Betak, Travis Cc: xen-devel@lists.xensource.com Subject: RE: [Xen-devel] [Patch] Add hardware CR8 acceleration for TPRaccessing >> From: xen-devel-bounces@lists.xensource.com >> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of >> Cui, Dexuan >> Sent: 24 October 2006 10:35 >> To: Betak, Travis >> Cc: xen-devel@lists.xensource.com >> Subjec...

...ch...) -- Dexuan -----Original Message----- From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Cui, Dexuan Sent: 2006年10月25日 11:07 To: Keir.Fraser@cl.cam.ac.uk Cc: xen-devel@lists.xensource.com Subject: [Xen-devel] [Patch][RESEND] Add hardware CR8 acceleration for TPRaccessing x64 Windows uses CR8 to access TPR very frequently. This patch enables TPR shadow and allows mov-from/to-CR8 to access it directly; tests indicates it can boost greatly the performance of x64 Windows 2003. Thanks -- Dexuan Signed-off-by: Eddie Dong <eddie.dong@i...

There is a lot of infrastructure for functionality which is used exclusively in __{save,restore}_processor_state() on the suspend/resume path. cr8 is an alias of APIC_TASKPRI, and APIC_TASKPRI is saved/restored independently by lapic_{suspend,resume}(). Delete the saving and restoration of cr8, which allows for the removal of both PVOPS. Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com> --- CC: x86 at kernel.org CC: virtuali...

There is a lot of infrastructure for functionality which is used exclusively in __{save,restore}_processor_state() on the suspend/resume path. cr8 is an alias of APIC_TASKPRI, and APIC_TASKPRI is saved/restored independently by lapic_{suspend,resume}(). Delete the saving and restoration of cr8, which allows for the removal of both PVOPS. Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com> --- CC: x86 at kernel.org CC: virtuali...

> On Jul 15, 2019, at 8:16 AM, Andrew Cooper <andrew.cooper3 at citrix.com> wrote: > > There is a lot of infrastructure for functionality which is used > exclusively in __{save,restore}_processor_state() on the suspend/resume > path. > > cr8 is an alias of APIC_TASKPRI, and APIC_TASKPRI is saved/restored by > lapic_{suspend,resume}(). Saving and restoring cr8 independently of the > rest of the Local APIC state isn't a clever thing to be doing. > > Delete the suspend/resume cr8 handling, which shrinks the size of struc...

This patch is a small fix for CR8 acceleration on 64bit guest. For current CR8 acceleration, we do not call update_tpr_threshold() at every VMEXIT. But at some situations, we cannot inject guest interrupts in time. And at some critical time, it will bring up a blue screen to 64bit Windows guest. Try this scenario: 1)...

...6:23 AM Juergen Gross <jgross at suse.com> wrote: > > On 15.07.19 15:00, Andrew Cooper wrote: > > There is a lot of infrastructure for functionality which is used > > exclusively in __{save,restore}_processor_state() on the suspend/resume > > path. > > > > cr8 is an alias of APIC_TASKPRI, and APIC_TASKPRI is saved/restored > > independently by lapic_{suspend,resume}(). > > Aren't those called only with CONFIG_PM set? > Unless I'm missing something, we only build any of the restore code (including the write_cr8() call) if CONFIG_P...

...6:23 AM Juergen Gross <jgross at suse.com> wrote: > > On 15.07.19 15:00, Andrew Cooper wrote: > > There is a lot of infrastructure for functionality which is used > > exclusively in __{save,restore}_processor_state() on the suspend/resume > > path. > > > > cr8 is an alias of APIC_TASKPRI, and APIC_TASKPRI is saved/restored > > independently by lapic_{suspend,resume}(). > > Aren't those called only with CONFIG_PM set? > Unless I'm missing something, we only build any of the restore code (including the write_cr8() call) if CONFIG_P...

...ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT> Features2=0x802009<SSE3,MON,CX16,<b23>> AMD Features=0xee500800<SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM,3DNow!+,3DNow!> AMD Features2=0x7ff<LAHF,CMP,SVM,ExtAPIC,CR8,<b5>,<b6>,<b7>,Prefetch,<b9>,<b10>> Cores per package: 4 usable memory = 8547172352 (8151 MB) avail memory = 8268722176 (7885 MB) ACPI APIC Table: <102408 APIC2239> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): API...

...<jgross at suse.com> wrote: >> >> On 15.07.19 15:00, Andrew Cooper wrote: >>> There is a lot of infrastructure for functionality which is used >>> exclusively in __{save,restore}_processor_state() on the suspend/resume >>> path. >>> >>> cr8 is an alias of APIC_TASKPRI, and APIC_TASKPRI is saved/restored >>> independently by lapic_{suspend,resume}(). >> >> Aren't those called only with CONFIG_PM set? >> > > > Unless I'm missing something, we only build any of the restore code > (includin...

...30 occurred in module "zfs" due to a NULL pointer dereference sched: #pf Page fault Bad kernel fault at addr=0x30 pid=0, pc=0xfffffffff3ee322e, sp=0xfffffe80005c3a70, eflags=0x10206 cr0: 8005003b<pg,wp,ne,et,ts,mp,pe> cr4: 6f0<xmme,fxsr,pge,mce,pae,pse> cr2: 30 cr3: a49a000 cr8: c rdi: fffffe80f0aa2b40 rsi: ffffffff89c3a050 rdx: 6352 rcx: 2f r8: 0 r9: 30 rax: 64f2 rbx: 20000 rbp: fffffe80005c3aa0 r10: fffffe80f0c979 r11: bd7189449a7087 r12: ffffffff89c3a...

Hi, At Ingo's request, here it goes a new patchset, that actually applies ontop of the x86 tree (mm branch). Besides this issue, I've also included a patch that remove the cr8 references, as Andi suggested.

Hi, At Ingo's request, here it goes a new patchset, that actually applies ontop of the x86 tree (mm branch). Besides this issue, I've also included a patch that remove the cr8 references, as Andi suggested.