similar to: [PATCH][HVM] add mmio decoder 0x38 and some cleanup

> -----Original Message----- > From: xen-devel-bounces@lists.xensource.com > [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of > Gerd Hoffmann > Sent: 17 May 2006 07:43 > To: Petersson, Mats > Cc: xen-devel@lists.xensource.com; xen-changelog@lists.xensource.com > Subject: Re: [Xen-devel] RE: [Xen-changelog] Fix MOVS > instruction emulation for HVM MMIO. >

Add MOVSX instr support to VMX MMIO decoder. Signed-off-by: Xin Li <xin.b.li@intel.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

Hi, Selon "Zhang, Xiantao" <xiantao.zhang at intel.com>: > >From 5f82ea88c095cf89cbae920944c05e578f35365f Mon Sep 17 00:00:00 2001 > From: Xiantao Zhang <xiantao.zhang at intel.com> > Date: Wed, 12 Mar 2008 14:48:09 +0800 > Subject: [PATCH] kvm/ia64: Add mmio decoder for kvm/ia64. [...] > + post_update = (inst.M5.i << 7) + inst.M5.imm7; > + if

Hi, This patch fixed the size problem in the MMIO decoder. Signed-off-by: Chengyuan Li <chengyuan.li@intel.com> Thanks, Chengyuan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

Hi Steven, I onced played with your PV-on-HVM driver before it is checked in into unstable, I remember at that time, there is a XENFEAT_64bit_shared_info flag to handle situation of 32bit guest on 64bit hypervisor, at least vnif works fine with it. Later, when the code is checked in, this flag is gone. At first I though this was an effort to make hypervisor more transparent to HVM guest, but now

Some instructions, like "add $imm8, r/m16"/"MOV $imm32, r/m64" require the src immediate operand be sign-extented befere the op is executed, but this is omitted in the current Xcode. The patch fixes this. The patch also fixes an issue in handling address-size override prefix, and fixes an issue in get_immediate(). Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>

Hi folk, I''m recently doing some work on VNIF driver, however, when I enabled both qemu-dm devices and pv devices, the pv driver complains. It seems two kinds of devices have very similar entries in xenstore, which misled the driver. I remembered in the past, there is a `type:ioemu'' entry in xenstore to represent dm devices, but it was removed. There used to be a

I''ve been trying to pass through a GPU to a domU, so far with a lot of trouble but finally a success. PCI passthrough works, I''ve had the usb hubs work successfully. Today I tried to pass through my ATI card to an ubuntu hvm domU with no gfx_passthru and got this: [...] (XEN) memory_map:add: dom14 gfn=f3040 mfn=f7c40 nr=4 (XEN) memory_map:remove: dom14 gfn=f3040 mfn=f7c40 nr=4

Hi, 2013/10/25 Pekka Paalanen <pq at iki.fi> > > Just curious, how do you detect interesting instructions to > instrument from uninteresting instructions that do not access mmio > areas? > > As I currently use this for data race detection in general, there is no need to separate accesses to mmio areas from the accesses to other memory. The tool just tracks all except the

Hi, this is continuation for the MMIO accessor rewrite and cleanup. I am currently running nv28 with these patches applied, but I cannot test on PPC. Please, review and comment. If the direction is good, I'll do the same to INSTANCE_{RD,WR} as I did for nv_{rd,wr}32, and change PRAMIN from drm_local_map to simple ioremap. Can the same be done for channel specific mappings, that is

>>What kinds of things are going to be added? ''platform.h'' is vague >>enough it could end up a dumping ground for all kinds of crud. >> > >To support HVM guest with RAM above 4G physical address space, we need >define a constant HVM_RAM_LIMIT_BELOW_4G, and physical address space >from HVM_RAM_LIMIT_BELOW_4G to 4G is reserved for PCI device MMIO use.

Hi Folks, I make I new approach to pimp up my xen-Kernel in higher version-numbers. Currently I run a selfcompiled 2.6.27-Kernel from: hg clone http://xenbits.xensource.com/ext/linux-2.6.27-xen.hg In the next step I want to run the kernel from jemery: git clone git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git I tried the last couple of days to get pci-passtrough work with jeremys

From: Joerg Roedel <jroedel at suse.de> Add handling for emulation the MOVS instruction on MMIO regions, as done by the memcpy_toio() and memcpy_fromio() functions. Signed-off-by: Joerg Roedel <jroedel at suse.de> --- arch/x86/kernel/sev-es.c | 78 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 78 insertions(+) diff --git a/arch/x86/kernel/sev-es.c

So, I made a mistake a bought four systems with the Intel Core i3 processors, without doing my homework to make sure that these systems actually supported VTd. Turns out there''s plenty of information out there indicating that the Core i3 processors do *not* support VTd. I was counting on VTd for two applications: Graphics Passthrough and passing through a PCIe 4-port serial card. Of

These patches add a test device, useful to measure speed of MMIO versus PIO, in different configurations. As I didn't want to reserve a hardcoded range of memory, I added pci device for this instead. Used together with the kvm unittest patches I posted on kvm mailing list. To use, simply add the device on the pci bus. Example test output: vmcall 1519 .... outl_to_kernel 1745

These patches add a test device, useful to measure speed of MMIO versus PIO, in different configurations. As I didn't want to reserve a hardcoded range of memory, I added pci device for this instead. Used together with the kvm unittest patches I posted on kvm mailing list. To use, simply add the device on the pci bus. Example test output: vmcall 1519 .... outl_to_kernel 1745

On 2014/11/6 9:59, Shannon Zhao wrote: > > > On 2014/11/5 16:43, Eric Auger wrote: >> On 10/27/2014 12:23 PM, Li Liu wrote: >>> >>> >>> On 2014/10/27 17:37, Peter Maydell wrote: >>>> On 25 October 2014 09:24, john.liuli <john.liuli at huawei.com> wrote: >>>>> To get the interrupt reason to support such VIRTIO_NET_F_STATUS

On 2014/11/5 16:43, Eric Auger wrote: > On 10/27/2014 12:23 PM, Li Liu wrote: >> >> >> On 2014/10/27 17:37, Peter Maydell wrote: >>> On 25 October 2014 09:24, john.liuli <john.liuli at huawei.com> wrote: >>>> To get the interrupt reason to support such VIRTIO_NET_F_STATUS >>>> features I add a new register offset VIRTIO_MMIO_ISRMEM which

On 2014/11/5 16:43, Eric Auger wrote: > On 10/27/2014 12:23 PM, Li Liu wrote: >> >> >> On 2014/10/27 17:37, Peter Maydell wrote: >>> On 25 October 2014 09:24, john.liuli <john.liuli at huawei.com> wrote: >>>> To get the interrupt reason to support such VIRTIO_NET_F_STATUS >>>> features I add a new register offset VIRTIO_MMIO_ISRMEM which

On Sat, Oct 25, 2014 at 04:24:52PM +0800, john.liuli wrote: > From: Li Liu <john.liuli at huawei.com> > > This set of patches try to implemet irqfd support of vhost-net > based on virtio-mmio. > > I had posted a mail to talking about the status of vhost-net > on kvm-arm refer to http://www.spinics.net/lists/kvm-arm/msg10804.html. > Some dependent patches are