search for: emulate_privileged_op

In this patch, we change read_segment_register to take vcpu and regs parameters for PVH (in upcoming patches). No functionality change. also, make emulate_privileged_op() public for later. Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com> diff -r 93d95f6dd693 -r 0339f85f6068 xen/arch/x86/domain.c --- a/xen/arch/x86/domain.c Fri Jan 11 16:22:57 2013 -0800 +++ b/xen/arch/x86/domain.c Fri Jan 11 16:24:00 2013 -0800 @@ -1370,10 +1370,10 @@ static void s...

Hello, I recently tried Xen 3.0.3-testing on my 2x Opteron-244 SMP machine. Everything works well exept one detail, which is not unimportant to me: the powernow-k8 driver fails to switch frequencies. A closer look on the powernow-k8 source reveals, that some MSR write operations seem to be without any effect. A rdmsr() before and after the wrmsr() call reveals that no real change on the register

...l.com> Index: 2007-08-08/xen/arch/x86/traps.c =================================================================== --- 2007-08-08.orig/xen/arch/x86/traps.c 2007-08-08 11:37:08.000000000 +0200 +++ 2007-08-08/xen/arch/x86/traps.c 2007-08-08 11:40:02.000000000 +0200 @@ -1696,6 +1696,8 @@ static int emulate_privileged_op(struct break; case 0x30: /* WRMSR */ + data = regs->eax; + res = ((u64)regs->edx << 32) | data; switch ( regs->ecx ) { #ifdef CONFIG_X86_64 @@ -1704,24 +1706,21 @@ static int emulate_privileged_op(struct goto fail;...

Could anyone summarize what the support status of cpu frequency changes is at present. I don''t seem to recall generic changes to the hpyervisor in that respect, but the linux tree has fairly extensive changes to the powernow-k8 driver (which would make sense to me only if all other cpufreq drivers are fully supported now, too). Thanks, Jan

1: correct LDT checks 2: add address validity check to guest_map_l1e() 3: use {rd,wr}{fs,gs}base when available 4: check for canonical address before doing page walks Signed-off-by: Jan Beulich <jbeulich@suse.com>

...construct_dom0: 968 0xffff8300001b1dbc vmx_vmexit_handler: 632 0xffff8300001b2f58 vmx_vmexit_handler: 632 0xffff8300001313ff arch_do_dom0_op: 552 0xffff8300001327f3 arch_do_dom0_op: 552 0xffff830000158660 emulate_privileged_op: 520 0xffff83000015a06c emulate_privileged_op: 520 0xffff830000114ce9 memory_exchange: 488 0xffff83000011598a memory_exchange: 488 0xffff83000010ce29 do_event_channel_op: 464 0xffff83000014b033 do_mmu_update:...

Hi everyone, I was trying to build a new machine but the system keeps rebooting. I used the lasted unstable version from xen-unstable.hg. I have tried with Fedora 16 (kernel 3.3.0-8) and Xubuntu 11.10 (3.0.0.17-generic). The output to my serial console is attached. Cheers, Francisco _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org

These two patches provide the neccessary infrastructure changes for the processor-passthru driver [www.spinics.net/lists/linux-acpi/msg34655.html] to properly function. The first one is quite easy - we just modprobe the processor-passthru driver. The second allows it to work under AMD machines by exposing the PM RDMSR to dom0. It has been tested with 2.6.32 kernel as well to make sure it does

We really don''t want the mmconf window to move/disappear whenever we use is ourselves, not only when we enabled it. Signed-off-by: Jan Beulich <jbeulich@novell.com> --- a/xen/arch/x86/traps.c +++ b/xen/arch/x86/traps.c @@ -2297,8 +2297,7 @@ static int emulate_privileged_op(struct goto fail; if ( #ifdef CONFIG_X86_64 - (pci_probe & PCI_PROBE_MMCONF) && - (pci_probe & PCI_CHECK_ENABLE_AMD_MMCONF) ? + (pci_probe & PCI_PROBE_MASK) == PCI_PROBE_MMCONF ? va...

This patch series is a reworking of a series developed by Mukesh Rathor at Oracle. The entirety of the design and development was done by him; I have only reworked, reorganized, and simplified things in a way that I think makes more sense. The vast majority of the credit for this effort therefore goes to him. This version is labelled v13 because it is based on his most recent series, v11.

...ble THERM_CONTROL MSR write for dom0 even cpufreq=xen Signed-off-by: Wei Gang <gang.wei@intel.com> diff -r bd683e0397b4 xen/arch/x86/traps.c --- a/xen/arch/x86/traps.c Tue Feb 17 22:29:38 2009 +0800 +++ b/xen/arch/x86/traps.c Wed Feb 25 11:23:01 2009 +0800 @@ -2187,10 +2187,17 @@ static int emulate_privileged_op(struct case MSR_IA32_MPERF: case MSR_IA32_APERF: case MSR_IA32_PERF_CTL: + if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL ) + goto fail; + if ( !is_cpufreq_controller(v->domain) ) + break; + if ( wrmsr_...

This set of patches converts the way frames gets created from using PUSHes/POPs to using MOVes, thus allowing (in certain cases) to avoid saving/restoring part of the register set. While the place where the (small) win from this comes from varies between CPUs, the net effect is a 1 to 2% reduction on a combined interruption entry and exit when the full state save can be avoided. 1: use MOV

...do have two bitmaps, and hence we could at least allow those port accesses to go without interception that Xen doesn''t need to do any internal state keeping on (and of course also only for those the guest is allowed to access). That would make - for PVH - unnecessary a significant part of emulate_privileged_op(): In essence, all you''d need to wire up are guest_io_read() and guest_io_write(). In particular it would then hopefully be safe to do all that without the on-stack emulation stub, as this ought to be necessary only for Dom0, which ought to always have direct access to such "special&...

...__clear_bit(X86_FEATURE_PSE, &d); + if (!opt_allow_hugepage) + __clear_bit(X86_FEATURE_PSE, &d); __clear_bit(X86_FEATURE_PGE, &d); __clear_bit(X86_FEATURE_MCE, &d); __clear_bit(X86_FEATURE_MCA, &d); @@ -2002,9 +2003,12 @@ static int emulate_privileged_op(struct case 4: /* Read CR4 */ /* * Guests can read CR4 to see what features Xen has enabled. We - * therefore lie about PGE & PSE as they are unavailable to guests. + * therefore lie about PGE as it is unavailable to guests. +...

...p;v->arch.trap_bounce; v->arch.guest_context.ctrlreg[2] = addr; - v->vcpu_info->arch.cr2 = addr; + arch_set_cr2(v, addr); /* Re-set error_code.user flag appropriately for the guest. */ error_code &= ~PFEC_user_mode; @@ -1393,7 +1394,7 @@ static int emulate_privileged_op(struct case 2: /* Write CR2 */ v->arch.guest_context.ctrlreg[2] = *reg; - v->vcpu_info->arch.cr2 = *reg; + arch_set_cr2(v, *reg); break; case 3: /* Write CR3 */ @@ -1611,7 +1612,7 @@ static void nmi_dom0_repor...

The first patch really isn''t as much of a follow-up than what triggered the security issues to be noticed in the first place. 1: x86: preserve FPU selectors for 32-bit guest code 2: x86: fix XCR0 handling 3: x86/xsave: adjust state management 4: x86/fxsave: bring in line with recent xsave adjustments The first two I would see as candidates for 4.3 (as well as subsequent backporting,