[PULL] virtio
The following changes since commit 925a6f0bf8bd122d5d2429af7f0ca0fecf4ae71f: Merge tag 'hwspinlock-3.6-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/ohad/hwspinlock (2012-09-18 11:58:54 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux.git virtio-next for you to fetch changes up to ca16f580a5db7e60bfafe59a50bb133bd3347491: lguest: fix occasional crash in example launcher. (2012-10-04 12:12:59 +0930) New workflow: same git trees pulled by linux-next get sent straight to Linus. Git is awkward at shuffling patches compared with quilt or mq, but that doesn't happen often once things get into my -next branch. Alexey Khoroshilov (1): virtio: console: fix error handling in init() function Asias He (3): virtio-blk: Add bio-based IO path for virtio-blk virtio-blk: Add REQ_FLUSH and REQ_FUA support to bio path virtio-blk: Disable callback in virtblk_done() Brian Foley (2): virtio_mmio: fix off by one error allocating queue virtio_mmio: Don't attempt to create empty virtqueues Dan Carpenter (1): virtio-blk: fix NULL checking in virtblk_alloc_req() Jason Wang (2): virtio-ring: move queue_index to vring_virtqueue virtio: introduce an API to set affinity for a virtqueue Masami Hiramatsu (5): virtio/console: Add splice_write support virtio/console: Add a failback for unstealable pipe buffer virtio/console: Wait until the port is ready on splice ftrace: Allow stealing pages from pipe buffer virtio/console: Allocate scatterlist according to the current pipe size Michael S. Tsirkin (3): virtio-balloon: dependency fix virtio: support reserved vqs virtio: don't crash when device is buggy Peter Senna Tschudin (1): drivers/virtio/virtio_pci.c: fix error return code Rusty Russell (4): virtio_balloon: not EXPERIMENTAL any more. virtio: add help to CONFIG_VIRTIO option. virtio: remove CONFIG_VIRTIO_RING lguest: fix occasional crash in example launcher. Yoshihiro YUNOMAE (2): tools: Add guest trace agent as a user tool tools: Fix pthread flag for Makefile of trace-agent used by virtio-trace arch/s390/Kconfig |1 - arch/x86/lguest/Kconfig |1 - drivers/block/virtio_blk.c | 306 +++ drivers/char/virtio_console.c | 210 -- drivers/lguest/lguest_device.c |5 +- drivers/remoteproc/remoteproc_virtio.c |5 +- drivers/rpmsg/Kconfig |1 - drivers/s390/kvm/kvm_virtio.c |5 +- drivers/virtio/Kconfig | 17 +- drivers/virtio/Makefile |3 +- drivers/virtio/virtio.c |2 +- drivers/virtio/virtio_mmio.c| 29 ++- drivers/virtio/virtio_pci.c | 68 +- drivers/virtio/virtio_ring.c| 14 +- include/linux/virtio.h |2 + include/linux/virtio_config.h | 23 ++ include/linux/virtio_ring.h |3 +- kernel/trace/trace.c|8 +- tools/lguest/lguest.c |1 + tools/virtio/virtio-trace/Makefile | 13 ++ tools/virtio/virtio-trace/README| 118 +++ tools/virtio/virtio-trace/trace-agent-ctl.c | 137 tools/virtio/virtio-trace/trace-agent-rw.c | 192 + tools/virtio/virtio-trace/trace-agent.c | 270 +++ tools/virtio/virtio-trace/trace-agent.h | 75 +++ 25 files changed, 1402 insertions(+), 107 deletions(-) create mode 100644 tools/virtio/virtio-trace/Makefile create mode 100644 tools/virtio/virtio-trace/README create mode 100644 tools/virtio/virtio-trace/trace-agent-ctl.c create mode 100644 tools/virtio/virtio-trace/trace-agent-rw.c create mode 100644 tools/virtio/virtio-trace/trace-agent.c create mode 100644 tools/virtio/virtio-trace/trace-agent.h -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] kvm tools: Fix powerpc build errors caused by recent changes
On Fri, 2012-10-05 at 09:30 +0300, Pekka Enberg wrote: Applied all three patches, thanks Michael! Thanks Pekka. cheers -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] kvm tools: Fix powerpc build errors caused by recent changes
Applied all three patches, thanks Michael! -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] virtio-net: inline header support
Il 04/10/2012 09:44, Rusty Russell ha scritto: -In particular, no implementation should use the descriptor -boundaries to determine the size of any header in a request.[footnote: -The current qemu device implementations mistakenly insist that -the first descriptor cover the header in these cases exactly, so -a cautious driver should arrange it so. +[footnote: +It was previously asserted that framing should be independent of +message contents, yet invariably drivers layed out messages in +reliable ways and devices assumed it. In addition, the +specifications for virtio_blk and virtio_scsi require intuiting +field lengths from frame boundaries. ] Not true for virtio_scsi... Paolo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH] kvm: Set default accelerator to kvm if the host supports it
On 5 October 2012 03:24, Alexander Graf ag...@suse.de wrote: On 05.10.2012, at 04:17, Anthony Liguori wrote: Alexander Graf ag...@suse.de writes: We get similar problems on PPC. Take the following example: $ qemu-system-ppc -M mpc8544ds -kernel uImage -nographic But do you really expect people to do this? I have to believe that people running on PPC hardware and running qemu-system-ppc most likely want to do KVM... Sure. But we wouldn't be able to even tell them what went wrong, as we don't have a negotiation mechanism right now that could tell user space hey, the CPU you selected is unknown to me. On ARM we will at least be able to say what happened, because our kvm_arch_init_vcpu() will fail (when we try the ioctl to tell the kernel be this kind of CPU) and we can print a message there. However QEMU as a whole doesn't have any way of falling back to TCG at that point so it just bails out. -- PMM -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
KVM: WARNING: at .. kvm_release_pfn_clean
Hi, I'm getting this warning while running qemu-kvm 1.2.rc1 on the top of 3.6.0-next-20121001: WARNING: at virt/kvm/kvm_main.c:1325 kvm_release_pfn_clean+0x70/0x80() Hardware name: To Be Filled By O.E.M. Modules linked in: nls_cp437 vfat fat dvb_usb_dib0700 dib0090 dib7000p dib7000m dib0070 dib8000 dib3000mc dibx000_common microcode Pid: 11848, comm: qemu-kvm Tainted: GW 3.6.0-next-20121001_64+ #70 Call Trace: [8107f19f] warn_slowpath_common+0x7f/0xc0 [8107f1fa] warn_slowpath_null+0x1a/0x20 [81004cd0] kvm_release_pfn_clean+0x70/0x80 [81027ac6] paging64_page_fault+0x686/0x830 [81024745] ? paging64_gva_to_gpa+0x35/0x80 [81021121] kvm_mmu_page_fault+0x31/0x100 [81040e81] handle_exception+0x231/0x3d0 [81041fbc] vmx_handle_exit+0xcc/0x780 [8101be44] kvm_arch_vcpu_ioctl_run+0x444/0xf60 [81017117] ? kvm_arch_vcpu_load+0x57/0x1b0 [81005302] kvm_vcpu_ioctl+0x472/0x610 [811aa36b] ? fsnotify+0x24b/0x340 [8117d609] do_vfs_ioctl+0x99/0x580 [810b620b] ? pick_next_task_fair+0x13b/0x1a0 [810b4f68] ? __enqueue_entity+0x78/0x80 [81010114] ? kvm_on_user_return+0x64/0x70 [8117db40] sys_ioctl+0x50/0x90 [816a46e2] system_call_fastpath+0x16/0x1b I.e. is_error_pfn(pfn) is true. regards, -- js suse labs -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 1/2] kvm: Handle undercommitted guest case in PLE handler
On 10/04/2012 12:59 PM, Gleb Natapov wrote:
On Wed, Oct 03, 2012 at 04:56:57PM +0200, Avi Kivity wrote:
On 10/03/2012 04:17 PM, Raghavendra K T wrote:
* Avi Kivity a...@redhat.com [2012-09-30 13:13:09]:
On 09/30/2012 01:07 PM, Gleb Natapov wrote:
On Sun, Sep 30, 2012 at 10:18:17AM +0200, Avi Kivity wrote:
On 09/28/2012 08:16 AM, Raghavendra K T wrote:
+struct pv_sched_info {
+ unsigned long sched_bitmap;
Thinking, whether we need something similar to cpumask here?
Only thing is we are representing guest (v)cpumask.
DECLARE_BITMAP(sched_bitmap, KVM_MAX_VCPUS)
vcpu_id can be greater than KVM_MAX_VCPUS.
Use the index into the vcpu table as the bitmap index then. In fact
it's better because then the lookup to get the vcpu pointer is trivial.
Did you mean, while setting the bitmap,
we should do
for (i = 1..n)
if (kvm-vcpus[i] == vcpu) set ith position in bitmap?
You can store i in the vcpu itself:
set_bit(vcpu-index, kvm-preempted);
This will make the fact that vcpus are stored in an array into API
instead of implementation detail :( There were patches for vcpu
destruction that changed the array to rculist. Well, it will be still
possible to make the array rcu protected and copy it every time vcpu is
deleted/added I guess.
If IUC, summary is, we are going with
- Let vcpu array be rcu protected.
- we use index inside vcpu and should be updated when a vcpu is
added/deleted.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 14/15] KVM: ARM: Handle I/O aborts
On Mon, Oct 01, 2012 at 01:53:26PM +0100, Dave Martin wrote: A good starting point would be load/store emulation as this seems to be a common theme, and we would need a credible deployment for any new framework so that we know it's fit for purpose. Probably not actually, that code is written to be fast, because things like IP stack throughput depend on it - particularly when your network card can only DMA packets to 32-bit aligned addresses (resulting in virtually all network data being misaligned.) -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 1/2] kvm: Handle undercommitted guest case in PLE handler
On 10/04/2012 06:11 PM, Avi Kivity wrote: On 10/04/2012 12:49 PM, Raghavendra K T wrote: On 10/03/2012 10:35 PM, Avi Kivity wrote: On 10/03/2012 02:22 PM, Raghavendra K T wrote: So I think it's worth trying again with ple_window of 2-4. Hi Avi, I ran different benchmarks increasing ple_window, and results does not seem to be encouraging for increasing ple_window. Thanks for testing! Comments below. Results: 16 core PLE machine with 16 vcpu guest. base kernel = 3.6-rc5 + ple handler optimization patch base_pleopt_8k = base kernel + ple window = 8k base_pleopt_16k = base kernel + ple window = 16k base_pleopt_32k = base kernel + ple window = 32k Percentage improvements of benchmarks w.r.t base_pleopt with ple_window = 4096 base_pleopt_8kbase_pleopt_16kbase_pleopt_32k - kernbench_1x-5.54915-15.94529-44.31562 kernbench_2x-7.89399-17.75039-37.73498 So, 44% degradation even with no overcommit? That's surprising. Yes. Kernbench was run with #threads = #vcpu * 2 as usual. Is it spending 8 times the original ple_window cycles for 16 vcpus significant? A PLE exit when not overcommitted cannot do any good, it is better to spin in the guest rather that look for candidates on the host. In fact when we benchmark we often disable PLE completely. I also got perf top output to analyse the difference. Difference comes because of flushtlb (and also spinlock). That's in the guest, yes? Yes. Perf is in guest. Ebizzy run for 4k ple_window - 87.20% [kernel] [k] arch_local_irq_restore - arch_local_irq_restore - 100.00% _raw_spin_unlock_irqrestore + 52.89% release_pages + 47.10% pagevec_lru_move_fn - 5.71% [kernel] [k] arch_local_irq_restore - arch_local_irq_restore + 86.03% default_send_IPI_mask_allbutself_phys + 13.96% default_send_IPI_mask_sequence_phys - 3.10% [kernel] [k] smp_call_function_many smp_call_function_many Ebizzy run for 32k ple_window - 91.40% [kernel] [k] arch_local_irq_restore - arch_local_irq_restore - 100.00% _raw_spin_unlock_irqrestore + 53.13% release_pages + 46.86% pagevec_lru_move_fn - 4.38% [kernel] [k] smp_call_function_many smp_call_function_many - 2.51% [kernel] [k] arch_local_irq_restore - arch_local_irq_restore + 90.76% default_send_IPI_mask_allbutself_phys + 9.24% default_send_IPI_mask_sequence_phys Both the 4k and the 32k results are crazy. Why is arch_local_irq_restore() so prominent? Do you have a very high interrupt rate in the guest? How to measure if I have high interrupt rate in guest? From /proc/interrupt numbers I am not able to judge :( 'vmstat 1' Thanks you. 'll save this. Apart from in,cs I think r: The number of processes waiting for run time, would be useful for me in vmstat. I went back and got the results on a 32 core machine with 32 vcpu guest. Strangely, I got result supporting the claim that increasing ple_window helps for non-overcommitted scenario. 32 core 32 vcpu guest 1x scenarios. ple_gap = 0 kernbench: Elapsed Time 38.61 ebizzy: 7463 records/s ple_window = 4k kernbench: Elapsed Time 43.5067 ebizzy:2528 records/s ple_window = 32k kernebench : Elapsed Time 39.4133 ebizzy: 7196 records/s So maybe something was wrong with the first measurement. May be I was not clear. The first time I had run on x240 (sandybridge) 16 core cpu, Then ran on 32 core x3850 to confirm the perf top results. But yes both had [0.018997] Performance Events: Broken PMU hardware detected, using software events only. problem as rightly pointed by you and PeterZ. after -cpu host, I see that is fixed on x240, [0.017997] Performance Events: 16-deep LBR, SandyBridge events, Intel PMU driver. [0.018868] NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter. So I 'll try it on x240 again. ( Some how mx3850 -cpu host resulted in [0.026995] Performance Events: unsupported p6 CPU model 26 no PMU driver, software events only. I think qemu needs some fix as pointed in http://www.mail-archive.com/kvm@vger.kernel.org/msg55836.html perf top for ebizzy for above: ple_gap = 0 - 84.74% [kernel] [k] arch_local_irq_restore - arch_local_irq_restore - 100.00% _raw_spin_unlock_irqrestore + 50.96% release_pages + 49.02% pagevec_lru_move_fn - 6.57% [kernel] [k] arch_local_irq_restore - arch_local_irq_restore + 92.54% default_send_IPI_mask_allbutself_phys + 7.46% default_send_IPI_mask_sequence_phys - 1.54% [kernel] [k] smp_call_function_many smp_call_function_many Again the numbers are ridiculously high for arch_local_irq_restore. Maybe there's a bad perf/kvm interaction when we're injecting an interrupt, I can't believe we're spending 84% of the time running the popf
Re: [PATCH RFC 0/2] kvm: Improving undercommit,overcommit scenarios in PLE handler
On 10/04/2012 06:14 PM, Avi Kivity wrote:
On 10/04/2012 12:56 PM, Raghavendra K T wrote:
On 10/03/2012 10:55 PM, Avi Kivity wrote:
On 10/03/2012 04:29 PM, Raghavendra K T wrote:
* Avi Kivity a...@redhat.com [2012-09-27 14:03:59]:
On 09/27/2012 01:23 PM, Raghavendra K T wrote:
[...]
2) looking at the result (comparing A C) , I do feel we have
significant in iterating over vcpus (when compared to even vmexit)
so We still would need undercommit fix sugested by PeterZ
(improving by
140%). ?
Looking only at the current runqueue? My worry is that it misses a lot
of cases. Maybe try the current runqueue first and then others.
Okay. Do you mean we can have something like
+ if (rq-nr_running == 1 p_rq-nr_running == 1) {
+ yielded = -ESRCH;
+ goto out_irq;
+ }
in the Peter's patch ?
( I thought lot about or || . Both seem to have their own cons ).
But that should be only when we have short term imbalance, as PeterZ
told.
I'm missing the context. What is p_rq?
p_rq is the run queue of target vcpu.
What I was trying below was to address Rik concern. Suppose
rq of source vcpu has one task, but target probably has two task,
with a eligible vcpu waiting to be scheduled.
What I mean was:
if can_yield_to_process_in_current_rq
do that
else if can_yield_to_process_in_other_rq
do that
else
return -ESRCH
I think you are saying we have to check the run queue of the
source vcpu, if we have a vcpu belonging to same VM and try yield to
that? ignoring whatever the target vcpu we received for yield_to.
Or is it that kvm_vcpu_yield_to should now check the vcpus of same vm
belonging to same run queue first. If we don't succeed, go again for
a vcpu in different runqueue.
Right. Prioritize vcpus that are cheap to yield to. But may return bad
results if all vcpus on the current runqueue are spinners, so probably
not a good idea.
Okay. 'll drop vcpu from same rq idea now.
Does it add more overhead especially in = 1x scenario?
The current runqueue should have just our vcpu in that case, so low
overhead. But it's a bad idea due to the above scenario.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 1/2] kvm: Handle undercommitted guest case in PLE handler
On 10/04/2012 08:11 PM, Andrew Theurer wrote: On Thu, 2012-10-04 at 14:41 +0200, Avi Kivity wrote: On 10/04/2012 12:49 PM, Raghavendra K T wrote: On 10/03/2012 10:35 PM, Avi Kivity wrote: On 10/03/2012 02:22 PM, Raghavendra K T wrote: So I think it's worth trying again with ple_window of 2-4. Hi Avi, I ran different benchmarks increasing ple_window, and results does not seem to be encouraging for increasing ple_window. Thanks for testing! Comments below. Results: 16 core PLE machine with 16 vcpu guest. base kernel = 3.6-rc5 + ple handler optimization patch base_pleopt_8k = base kernel + ple window = 8k base_pleopt_16k = base kernel + ple window = 16k base_pleopt_32k = base kernel + ple window = 32k Percentage improvements of benchmarks w.r.t base_pleopt with ple_window = 4096 base_pleopt_8kbase_pleopt_16kbase_pleopt_32k - kernbench_1x-5.54915-15.94529-44.31562 kernbench_2x-7.89399-17.75039-37.73498 So, 44% degradation even with no overcommit? That's surprising. Yes. Kernbench was run with #threads = #vcpu * 2 as usual. Is it spending 8 times the original ple_window cycles for 16 vcpus significant? A PLE exit when not overcommitted cannot do any good, it is better to spin in the guest rather that look for candidates on the host. In fact when we benchmark we often disable PLE completely. Agreed. However, I really do not understand why the kernbench regressed with bigger ple_window. It should stay the same or improve. Raghu, do you have perf data for the kernbench runs? Andrew, No. 'll get this with perf kvm. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Failed to get host power management capabilities
Hi all, My name is David Torres, I am from Costa Rica. See this is the problem I have with the KVM instalation: 2012-10-03 20:28:17.395+: 25793: warning : qemuCapsInit:856 : Failed to get host power management capabilities 2012-10-03 20:28:17.661+: 25793: error : virExecWithHook:328 : Cannot find 'pm-is-supported' in path: No such file or directory And this error from the kern.log: Oct 4 21:50:53 kvm kernel: [22727.849902] device vnet0 entered promiscuous mode Oct 4 21:50:53 kvm kernel: [22727.883686] br0: port 2(vnet0) entering forwarding state Oct 4 21:50:53 kvm kernel: [22727.883692] br0: port 2(vnet0) entering forwarding state Oct 4 21:50:53 kvm kernel: [22728.130242] br0: port 2(vnet0) entering forwarding state Oct 4 21:50:53 kvm kernel: [22728.134443] br0: port 2(vnet0) entering disabled state Oct 4 21:50:53 kvm kernel: [22728.135238] device vnet0 left promiscuous mode Oct 4 21:50:53 kvm kernel: [22728.135242] br0: port 2(vnet0) entering disabled state Oct 4 21:50:54 kvm kernel: [22728.673620] type=1400 audit(1349409054.320:42): apparmor=STATUS operation=profile_remove name=libvirt-9b75f498-7959-7321-9461-d729d9c60668 pid=6349 comm=apparmor_parser And when I try to create a Virtual Machine from the Virtual Machine Monitor, I got this error message: 2012-10-04 22:59:32.154+: 1333: error : qemuProcessReadLogOutput:1006 : internal error Process exited while reading console log output: char device redirected to /dev/pts/2 Could not access KVM kernel module: Is a directory failed to initialize KVM: Is a directory No accelerator found! I already enabled the virtualization feature on the BIOS and run the modprobe kvm-intel command also. No error message was received during the instalation process. So I am stuck on this problem :( I will appreciate sooo much any help. Thank you so much in advanced Regards -- To unsubscribe from this list: send the line unsubscribe kvm-commits in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: vfio: missing patch in linux 3.6
On Thu, Oct 04, 2012 at 10:28:00AM -0600, Alex Williamson wrote: There are a couple questions in the link above. Since the devices don't expose a PCIe capability, we probably need to add a check to look at the upstream device and verify we're not on a legacy bus where ACS can't be enforced. You can certainly do that, but for existing hardware (with an AMD IOMMU) this check would never be true. These devices are always on a seperate south-bridge chip which is connected to the north-bridge via PCIe. So the topology where you find these devices is always the same in an AMD IOMMU system. Then there's the general question of whether the confirmation of no peer-to-peer applies to every case where we might see this device (some of them seem to have history that pre-dates this specific package implementation) or do we need to try to identify specific package properties in addition to just a device ID? The device ids are kept the same to maintain compatability with older software. Besides that, my statement about the peer-2-peer safety is true for all south-bridges that you can find in an AMD IOMMU capable system. Regards, Joerg -- AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers: Alberto Bozzo Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 3/4] vfio: vfio-pci device assignment driver
On Fri, 2012-10-05 at 16:54 +, Blue Swirl wrote:
On Wed, Sep 26, 2012 at 5:19 PM, Alex Williamson
alex.william...@redhat.com wrote:
+
+typedef struct QEMU_PACKED VFIOIRQSetFD {
+struct vfio_irq_set irq_set;
+int32_t fd;
+} VFIOIRQSetFD;
I'm now getting this error from Clang:
/src/qemu/hw/vfio_pci.c:126:25: error: field 'irq_set' with variable
sized type 'struct vfio_irq_set' not at the end of a struct or class
is a GNU extension [-Werror,-Wgnu]
struct vfio_irq_set irq_set;
Does the kernel really use the fd field, isn't it implicit from the
ioctl fd or are they different?
The kernel side is defined as:
struct vfio_irq_set {
__u32 argsz;
__u32 flags;
__u32 index;
__u32 start;
__u32 count;
__u8data[];
};
Where data is the start of a variable sized array. The data type of the
array depends on the flags. The purpose of VFIOIRQSetFD is simply to
make a data type that I don't need to dynamically allocate. You can
find other cases for MSI and MSIX where we don't know the array size and
do malloc the whole structure. For this interrupt type we know there's
only one entry. If there's a better way to do this, let me know. VFIO
is only available on Linux hosts, so I have no particular reason to
avoid GNU extensions.
+
+static int vfio_enable_intx(VFIODevice *vdev)
+{
+VFIOIRQSetFD irq_set_fd = {
+.irq_set = {
+.argsz = sizeof(irq_set_fd),
+.flags = VFIO_IRQ_SET_DATA_EVENTFD |
VFIO_IRQ_SET_ACTION_TRIGGER,
+.index = VFIO_PCI_INTX_IRQ_INDEX,
+.start = 0,
+.count = 1,
+},
Here the field is not even initialized.
It's initialized later...
+};
+uint8_t pin = vfio_pci_read_config(vdev-pdev, PCI_INTERRUPT_PIN, 1);
+int ret;
+
+if (vdev-intx.disabled || !pin) {
+return 0;
+}
+
+vfio_disable_interrupts(vdev);
+
+vdev-intx.pin = pin - 1; /* Pin A (1) - irq[0] */
+ret = event_notifier_init(vdev-intx.interrupt, 0);
+if (ret) {
+error_report(vfio: Error: event_notifier_init failed\n);
+return ret;
+}
+
+irq_set_fd.fd = event_notifier_get_fd(vdev-intx.interrupt);
Here.
Thanks,
Alex
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 3/4] vfio: vfio-pci device assignment driver
On Fri, Oct 5, 2012 at 5:11 PM, Alex Williamson
alex.william...@redhat.com wrote:
On Fri, 2012-10-05 at 16:54 +, Blue Swirl wrote:
On Wed, Sep 26, 2012 at 5:19 PM, Alex Williamson
alex.william...@redhat.com wrote:
+
+typedef struct QEMU_PACKED VFIOIRQSetFD {
+struct vfio_irq_set irq_set;
+int32_t fd;
+} VFIOIRQSetFD;
I'm now getting this error from Clang:
/src/qemu/hw/vfio_pci.c:126:25: error: field 'irq_set' with variable
sized type 'struct vfio_irq_set' not at the end of a struct or class
is a GNU extension [-Werror,-Wgnu]
struct vfio_irq_set irq_set;
Does the kernel really use the fd field, isn't it implicit from the
ioctl fd or are they different?
The kernel side is defined as:
struct vfio_irq_set {
__u32 argsz;
__u32 flags;
__u32 index;
__u32 start;
__u32 count;
__u8data[];
};
Then the kernel only expects vfio_irq_set structure, not VFIOIRQSetFD,
so you should use irq_set_fd.irq_set instead of irq_set_fd for the
ioctl(). Then VFIOIRQSetFD can be rearranged to have fd field first,
also QEMU_PACKED is not necessary.
Where data is the start of a variable sized array. The data type of the
array depends on the flags. The purpose of VFIOIRQSetFD is simply to
make a data type that I don't need to dynamically allocate. You can
find other cases for MSI and MSIX where we don't know the array size and
do malloc the whole structure. For this interrupt type we know there's
only one entry. If there's a better way to do this, let me know. VFIO
is only available on Linux hosts, so I have no particular reason to
avoid GNU extensions.
+
+static int vfio_enable_intx(VFIODevice *vdev)
+{
+VFIOIRQSetFD irq_set_fd = {
+.irq_set = {
+.argsz = sizeof(irq_set_fd),
+.flags = VFIO_IRQ_SET_DATA_EVENTFD |
VFIO_IRQ_SET_ACTION_TRIGGER,
+.index = VFIO_PCI_INTX_IRQ_INDEX,
+.start = 0,
+.count = 1,
+},
Here the field is not even initialized.
It's initialized later...
+};
+uint8_t pin = vfio_pci_read_config(vdev-pdev, PCI_INTERRUPT_PIN, 1);
+int ret;
+
+if (vdev-intx.disabled || !pin) {
+return 0;
+}
+
+vfio_disable_interrupts(vdev);
+
+vdev-intx.pin = pin - 1; /* Pin A (1) - irq[0] */
+ret = event_notifier_init(vdev-intx.interrupt, 0);
+if (ret) {
+error_report(vfio: Error: event_notifier_init failed\n);
+return ret;
+}
+
+irq_set_fd.fd = event_notifier_get_fd(vdev-intx.interrupt);
Here.
Thanks,
Alex
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 3/4] vfio: vfio-pci device assignment driver
On Fri, 2012-10-05 at 17:22 +, Blue Swirl wrote:
On Fri, Oct 5, 2012 at 5:11 PM, Alex Williamson
alex.william...@redhat.com wrote:
On Fri, 2012-10-05 at 16:54 +, Blue Swirl wrote:
On Wed, Sep 26, 2012 at 5:19 PM, Alex Williamson
alex.william...@redhat.com wrote:
+
+typedef struct QEMU_PACKED VFIOIRQSetFD {
+struct vfio_irq_set irq_set;
+int32_t fd;
+} VFIOIRQSetFD;
I'm now getting this error from Clang:
/src/qemu/hw/vfio_pci.c:126:25: error: field 'irq_set' with variable
sized type 'struct vfio_irq_set' not at the end of a struct or class
is a GNU extension [-Werror,-Wgnu]
struct vfio_irq_set irq_set;
Does the kernel really use the fd field, isn't it implicit from the
ioctl fd or are they different?
The kernel side is defined as:
struct vfio_irq_set {
__u32 argsz;
__u32 flags;
__u32 index;
__u32 start;
__u32 count;
__u8data[];
};
Then the kernel only expects vfio_irq_set structure, not VFIOIRQSetFD,
so you should use irq_set_fd.irq_set instead of irq_set_fd for the
ioctl(). Then VFIOIRQSetFD can be rearranged to have fd field first,
also QEMU_PACKED is not necessary.
Sorry, I was unclear. The kernel sees fd as data[0], that's the point
of the structure, so re-arranging it makes it useless. Thanks,
Alex
Where data is the start of a variable sized array. The data type of the
array depends on the flags. The purpose of VFIOIRQSetFD is simply to
make a data type that I don't need to dynamically allocate. You can
find other cases for MSI and MSIX where we don't know the array size and
do malloc the whole structure. For this interrupt type we know there's
only one entry. If there's a better way to do this, let me know. VFIO
is only available on Linux hosts, so I have no particular reason to
avoid GNU extensions.
+
+static int vfio_enable_intx(VFIODevice *vdev)
+{
+VFIOIRQSetFD irq_set_fd = {
+.irq_set = {
+.argsz = sizeof(irq_set_fd),
+.flags = VFIO_IRQ_SET_DATA_EVENTFD |
VFIO_IRQ_SET_ACTION_TRIGGER,
+.index = VFIO_PCI_INTX_IRQ_INDEX,
+.start = 0,
+.count = 1,
+},
Here the field is not even initialized.
It's initialized later...
+};
+uint8_t pin = vfio_pci_read_config(vdev-pdev, PCI_INTERRUPT_PIN,
1);
+int ret;
+
+if (vdev-intx.disabled || !pin) {
+return 0;
+}
+
+vfio_disable_interrupts(vdev);
+
+vdev-intx.pin = pin - 1; /* Pin A (1) - irq[0] */
+ret = event_notifier_init(vdev-intx.interrupt, 0);
+if (ret) {
+error_report(vfio: Error: event_notifier_init failed\n);
+return ret;
+}
+
+irq_set_fd.fd = event_notifier_get_fd(vdev-intx.interrupt);
Here.
Thanks,
Alex
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 3/4] vfio: vfio-pci device assignment driver
On Fri, Oct 5, 2012 at 5:33 PM, Alex Williamson
alex.william...@redhat.com wrote:
On Fri, 2012-10-05 at 17:22 +, Blue Swirl wrote:
On Fri, Oct 5, 2012 at 5:11 PM, Alex Williamson
alex.william...@redhat.com wrote:
On Fri, 2012-10-05 at 16:54 +, Blue Swirl wrote:
On Wed, Sep 26, 2012 at 5:19 PM, Alex Williamson
alex.william...@redhat.com wrote:
+
+typedef struct QEMU_PACKED VFIOIRQSetFD {
+struct vfio_irq_set irq_set;
+int32_t fd;
+} VFIOIRQSetFD;
I'm now getting this error from Clang:
/src/qemu/hw/vfio_pci.c:126:25: error: field 'irq_set' with variable
sized type 'struct vfio_irq_set' not at the end of a struct or class
is a GNU extension [-Werror,-Wgnu]
struct vfio_irq_set irq_set;
Does the kernel really use the fd field, isn't it implicit from the
ioctl fd or are they different?
The kernel side is defined as:
struct vfio_irq_set {
__u32 argsz;
__u32 flags;
__u32 index;
__u32 start;
__u32 count;
__u8data[];
};
Then the kernel only expects vfio_irq_set structure, not VFIOIRQSetFD,
so you should use irq_set_fd.irq_set instead of irq_set_fd for the
ioctl(). Then VFIOIRQSetFD can be rearranged to have fd field first,
also QEMU_PACKED is not necessary.
Sorry, I was unclear. The kernel sees fd as data[0], that's the point
of the structure, so re-arranging it makes it useless. Thanks,
I see. The example in GCC shows how to statically initialize flexible
array members properly but it does not seem to work:
http://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
Also, Clang does not like that syntax either.
Maybe it's best to use g_malloc with room for the extra int.
Alex
Where data is the start of a variable sized array. The data type of the
array depends on the flags. The purpose of VFIOIRQSetFD is simply to
make a data type that I don't need to dynamically allocate. You can
find other cases for MSI and MSIX where we don't know the array size and
do malloc the whole structure. For this interrupt type we know there's
only one entry. If there's a better way to do this, let me know. VFIO
is only available on Linux hosts, so I have no particular reason to
avoid GNU extensions.
+
+static int vfio_enable_intx(VFIODevice *vdev)
+{
+VFIOIRQSetFD irq_set_fd = {
+.irq_set = {
+.argsz = sizeof(irq_set_fd),
+.flags = VFIO_IRQ_SET_DATA_EVENTFD |
VFIO_IRQ_SET_ACTION_TRIGGER,
+.index = VFIO_PCI_INTX_IRQ_INDEX,
+.start = 0,
+.count = 1,
+},
Here the field is not even initialized.
It's initialized later...
+};
+uint8_t pin = vfio_pci_read_config(vdev-pdev, PCI_INTERRUPT_PIN,
1);
+int ret;
+
+if (vdev-intx.disabled || !pin) {
+return 0;
+}
+
+vfio_disable_interrupts(vdev);
+
+vdev-intx.pin = pin - 1; /* Pin A (1) - irq[0] */
+ret = event_notifier_init(vdev-intx.interrupt, 0);
+if (ret) {
+error_report(vfio: Error: event_notifier_init failed\n);
+return ret;
+}
+
+irq_set_fd.fd = event_notifier_get_fd(vdev-intx.interrupt);
Here.
Thanks,
Alex
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 3/4] vfio: vfio-pci device assignment driver
On Fri, 2012-10-05 at 18:05 +, Blue Swirl wrote:
On Fri, Oct 5, 2012 at 5:33 PM, Alex Williamson
alex.william...@redhat.com wrote:
On Fri, 2012-10-05 at 17:22 +, Blue Swirl wrote:
On Fri, Oct 5, 2012 at 5:11 PM, Alex Williamson
alex.william...@redhat.com wrote:
On Fri, 2012-10-05 at 16:54 +, Blue Swirl wrote:
On Wed, Sep 26, 2012 at 5:19 PM, Alex Williamson
alex.william...@redhat.com wrote:
+
+typedef struct QEMU_PACKED VFIOIRQSetFD {
+struct vfio_irq_set irq_set;
+int32_t fd;
+} VFIOIRQSetFD;
I'm now getting this error from Clang:
/src/qemu/hw/vfio_pci.c:126:25: error: field 'irq_set' with variable
sized type 'struct vfio_irq_set' not at the end of a struct or class
is a GNU extension [-Werror,-Wgnu]
struct vfio_irq_set irq_set;
Does the kernel really use the fd field, isn't it implicit from the
ioctl fd or are they different?
The kernel side is defined as:
struct vfio_irq_set {
__u32 argsz;
__u32 flags;
__u32 index;
__u32 start;
__u32 count;
__u8data[];
};
Then the kernel only expects vfio_irq_set structure, not VFIOIRQSetFD,
so you should use irq_set_fd.irq_set instead of irq_set_fd for the
ioctl(). Then VFIOIRQSetFD can be rearranged to have fd field first,
also QEMU_PACKED is not necessary.
Sorry, I was unclear. The kernel sees fd as data[0], that's the point
of the structure, so re-arranging it makes it useless. Thanks,
I see. The example in GCC shows how to statically initialize flexible
array members properly but it does not seem to work:
http://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
That's not going to like that the data type is actually different for
this use case.
Also, Clang does not like that syntax either.
Maybe it's best to use g_malloc with room for the extra int.
:( Ok, I'll write a patch to make it dynamically allocated. Thanks,
Alex
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Fwd: [PULL 00/56] ppc patch queue 2012-10-04
Hi Avi / Marcelo, Apparently I messed up while sending the pull request yesterday and didn't CC kvm@vger. Do you want me to resend or is this good enough for you? :) Alex Begin forwarded message: From: Alexander Graf ag...@suse.de Subject: [PULL 00/56] ppc patch queue 2012-10-04 Date: 4. Oktober 2012 15:36:28 MESZ To: kvm-...@vger.kernel.org Hi Avi / Marcelo, This is my current patch queue for ppc. Please pull. Changes include: * add support for idle hcall on booke * icache clear on map * mmu notifier support for e500 and book3s_pr * revive the 440 support slightly (still not 100% happy) * unify booke and book3s_pr entry/exit code a bit * add watchdog emulation for booke * reset and migratbility fixes for book3s_64_hv * rework book3s_64_hv memslot locking * small bug fixes Alex The following changes since commit 1e08ec4a130e2745d96df169e67c58df98a07311: Gleb Natapov (1): KVM: optimize apic interrupt delivery are available in the git repository at: git://github.com/agraf/linux-2.6.git for-upstream Alexander Graf (28): KVM: PPC: PR: Use generic tracepoint for guest exit KVM: PPC: Expose SYNC cap based on mmu notifiers KVM: PPC: BookE: Expose remote TLB flushes in debugfs KVM: PPC: E500: Fix clear_tlb_refs KVM: PPC: BookE: Add check_requests helper function KVM: PPC: BookE: Add support for vcpu-mode KVM: PPC: E500: Implement MMU notifiers KVM: PPC: BookE: Add some more trace points KVM: PPC: BookE: No duplicate request != 0 check KVM: PPC: Use same kvmppc_prepare_to_enter code for booke and book3s_pr KVM: PPC: Book3s: PR: Add (dumb) MMU Notifier support KVM: PPC: BookE: Drop redundant vcpu-mode set KVM: PPC: Book3S: PR: Only do resched check once per exit KVM: PPC: Exit guest context while handling exit KVM: PPC: Book3S: PR: Indicate we're out of guest mode KVM: PPC: Consistentify vcpu exit path KVM: PPC: Book3S: PR: Rework irq disabling KVM: PPC: Move kvm_guest_enter call into generic code KVM: PPC: Ignore EXITING_GUEST_MODE mode KVM: PPC: Add return value in prepare_to_enter KVM: PPC: Add return value to core_check_requests KVM: PPC: 44x: Initialize PVR KVM: PPC: BookE: Add MCSR SPR support KVM: PPC: Use symbols for exit trace KVM: PPC: E500: Remove E500_TLB_DIRTY flag KVM: PPC: 440: Implement mtdcrx KVM: PPC: 440: Implement mfdcrx KVM: PPC: BookE: Support FPU on non-hv systems Bharat Bhushan (3): KVM: PPC: booke: Add watchdog emulation booke: Added ONE_REG interface for IAC/DAC debug registers Document IACx/DACx registers access using ONE_REG API Julia Lawall (1): arch/powerpc/kvm/e500_tlb.c: fix error return code Liu Yu-B13201 (3): KVM: PPC: Add support for ePAPR idle hcall in host kernel KVM: PPC: ev_idle hcall support for e500 guests PPC: Don't use hardcoded opcode for ePAPR hcall invocation Mihai Caraman (1): KVM: PPC: bookehv: Allow duplicate calls of DO_KVM macro Paul Mackerras (11): KVM: PPC: Quieten message about allocating linear regions KVM: PPC: Book3S HV: Take the SRCU read lock before looking up memslots KVM: PPC: Move kvm-arch.slot_phys into memslot.arch KVM: PPC: Book3S HV: Handle memory slot deletion and modification correctly KVM: Move some PPC ioctl definitions to the correct place KVM: PPC: Book3S HV: Fix updates of vcpu-cpu KVM: PPC: Book3S HV: Remove bogus update of physical thread IDs KVM: PPC: Book3S HV: Fix calculation of guest phys address for MMIO emulation KVM: PPC: Book3S: Get/set guest SPRs using the GET/SET_ONE_REG interface KVM: PPC: Book3S: Get/set guest FP regs using the GET/SET_ONE_REG interface KVM: PPC: Book3S HV: Provide a way for userspace to get/set per-vCPU areas Scott Wood (5): powerpc/fsl-soc: use CONFIG_EPAPR_PARAVIRT for hcalls powerpc/epapr: export epapr_hypercall_start KVM: PPC: e500: fix allocation size error on g2h_tlb1_map KVM: PPC: e500: MMU API: fix leak of shared_tlb_pages KVM: PPC: set IN_GUEST_MODE before checking requests Stuart Yoder (4): PPC: epapr: create define for return code value of success KVM: PPC: use definitions in epapr header for hcalls KVM: PPC: add pvinfo for hcall opcodes on e500mc/e5500 PPC: select EPAPR_PARAVIRT for all users of epapr hcalls Documentation/virtual/kvm/api.txt | 49 - arch/powerpc/include/asm/Kbuild |1 + arch/powerpc/include/asm/epapr_hcalls.h | 36 ++-- arch/powerpc/include/asm/fsl_hcalls.h | 36 ++-- arch/powerpc/include/asm/kvm.h | 59 + arch/powerpc/include/asm/kvm_book3s.h |2 +- arch/powerpc/include/asm/kvm_booke_hv_asm.h |4 +- arch/powerpc/include/asm/kvm_host.h | 38 +++-
[PATCH] KVM: PPC: 44x: fix DCR read/write
When remembering the direction of a DCR transaction, we should write to the same variable that we interpret on later when doing vcpu_run again. Signed-off-by: Alexander Graf ag...@suse.de --- arch/powerpc/kvm/44x_emulate.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/kvm/44x_emulate.c b/arch/powerpc/kvm/44x_emulate.c index 1a793c4..35ec0a8 100644 --- a/arch/powerpc/kvm/44x_emulate.c +++ b/arch/powerpc/kvm/44x_emulate.c @@ -46,6 +46,7 @@ static int emulate_mtdcr(struct kvm_vcpu *vcpu, int rs, int dcrn) vcpu-run-dcr.dcrn = dcrn; vcpu-run-dcr.data = kvmppc_get_gpr(vcpu, rs); vcpu-run-dcr.is_write = 1; + vcpu-arch.dcr_is_write = 1; vcpu-arch.dcr_needed = 1; kvmppc_account_exit(vcpu, DCR_EXITS); return EMULATE_DO_DCR; @@ -80,6 +81,7 @@ static int emulate_mfdcr(struct kvm_vcpu *vcpu, int rt, int dcrn) vcpu-run-dcr.dcrn = dcrn; vcpu-run-dcr.data = 0; vcpu-run-dcr.is_write = 0; + vcpu-arch.dcr_is_write = 0; vcpu-arch.io_gpr = rt; vcpu-arch.dcr_needed = 1; kvmppc_account_exit(vcpu, DCR_EXITS); -- 1.6.0.2 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] kvm tools: Fix powerpc build errors caused by recent changes
On Fri, 2012-10-05 at 09:30 +0300, Pekka Enberg wrote: Applied all three patches, thanks Michael! Thanks Pekka. cheers -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] kvm tools: Fix powerpc build errors caused by recent changes
Applied all three patches, thanks Michael! -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Fwd: [PULL 00/56] ppc patch queue 2012-10-04
Hi Avi / Marcelo, Apparently I messed up while sending the pull request yesterday and didn't CC kvm@vger. Do you want me to resend or is this good enough for you? :) Alex Begin forwarded message: From: Alexander Graf ag...@suse.de Subject: [PULL 00/56] ppc patch queue 2012-10-04 Date: 4. Oktober 2012 15:36:28 MESZ To: kvm-ppc@vger.kernel.org Hi Avi / Marcelo, This is my current patch queue for ppc. Please pull. Changes include: * add support for idle hcall on booke * icache clear on map * mmu notifier support for e500 and book3s_pr * revive the 440 support slightly (still not 100% happy) * unify booke and book3s_pr entry/exit code a bit * add watchdog emulation for booke * reset and migratbility fixes for book3s_64_hv * rework book3s_64_hv memslot locking * small bug fixes Alex The following changes since commit 1e08ec4a130e2745d96df169e67c58df98a07311: Gleb Natapov (1): KVM: optimize apic interrupt delivery are available in the git repository at: git://github.com/agraf/linux-2.6.git for-upstream Alexander Graf (28): KVM: PPC: PR: Use generic tracepoint for guest exit KVM: PPC: Expose SYNC cap based on mmu notifiers KVM: PPC: BookE: Expose remote TLB flushes in debugfs KVM: PPC: E500: Fix clear_tlb_refs KVM: PPC: BookE: Add check_requests helper function KVM: PPC: BookE: Add support for vcpu-mode KVM: PPC: E500: Implement MMU notifiers KVM: PPC: BookE: Add some more trace points KVM: PPC: BookE: No duplicate request != 0 check KVM: PPC: Use same kvmppc_prepare_to_enter code for booke and book3s_pr KVM: PPC: Book3s: PR: Add (dumb) MMU Notifier support KVM: PPC: BookE: Drop redundant vcpu-mode set KVM: PPC: Book3S: PR: Only do resched check once per exit KVM: PPC: Exit guest context while handling exit KVM: PPC: Book3S: PR: Indicate we're out of guest mode KVM: PPC: Consistentify vcpu exit path KVM: PPC: Book3S: PR: Rework irq disabling KVM: PPC: Move kvm_guest_enter call into generic code KVM: PPC: Ignore EXITING_GUEST_MODE mode KVM: PPC: Add return value in prepare_to_enter KVM: PPC: Add return value to core_check_requests KVM: PPC: 44x: Initialize PVR KVM: PPC: BookE: Add MCSR SPR support KVM: PPC: Use symbols for exit trace KVM: PPC: E500: Remove E500_TLB_DIRTY flag KVM: PPC: 440: Implement mtdcrx KVM: PPC: 440: Implement mfdcrx KVM: PPC: BookE: Support FPU on non-hv systems Bharat Bhushan (3): KVM: PPC: booke: Add watchdog emulation booke: Added ONE_REG interface for IAC/DAC debug registers Document IACx/DACx registers access using ONE_REG API Julia Lawall (1): arch/powerpc/kvm/e500_tlb.c: fix error return code Liu Yu-B13201 (3): KVM: PPC: Add support for ePAPR idle hcall in host kernel KVM: PPC: ev_idle hcall support for e500 guests PPC: Don't use hardcoded opcode for ePAPR hcall invocation Mihai Caraman (1): KVM: PPC: bookehv: Allow duplicate calls of DO_KVM macro Paul Mackerras (11): KVM: PPC: Quieten message about allocating linear regions KVM: PPC: Book3S HV: Take the SRCU read lock before looking up memslots KVM: PPC: Move kvm-arch.slot_phys into memslot.arch KVM: PPC: Book3S HV: Handle memory slot deletion and modification correctly KVM: Move some PPC ioctl definitions to the correct place KVM: PPC: Book3S HV: Fix updates of vcpu-cpu KVM: PPC: Book3S HV: Remove bogus update of physical thread IDs KVM: PPC: Book3S HV: Fix calculation of guest phys address for MMIO emulation KVM: PPC: Book3S: Get/set guest SPRs using the GET/SET_ONE_REG interface KVM: PPC: Book3S: Get/set guest FP regs using the GET/SET_ONE_REG interface KVM: PPC: Book3S HV: Provide a way for userspace to get/set per-vCPU areas Scott Wood (5): powerpc/fsl-soc: use CONFIG_EPAPR_PARAVIRT for hcalls powerpc/epapr: export epapr_hypercall_start KVM: PPC: e500: fix allocation size error on g2h_tlb1_map KVM: PPC: e500: MMU API: fix leak of shared_tlb_pages KVM: PPC: set IN_GUEST_MODE before checking requests Stuart Yoder (4): PPC: epapr: create define for return code value of success KVM: PPC: use definitions in epapr header for hcalls KVM: PPC: add pvinfo for hcall opcodes on e500mc/e5500 PPC: select EPAPR_PARAVIRT for all users of epapr hcalls Documentation/virtual/kvm/api.txt | 49 - arch/powerpc/include/asm/Kbuild |1 + arch/powerpc/include/asm/epapr_hcalls.h | 36 ++-- arch/powerpc/include/asm/fsl_hcalls.h | 36 ++-- arch/powerpc/include/asm/kvm.h | 59 + arch/powerpc/include/asm/kvm_book3s.h |2 +- arch/powerpc/include/asm/kvm_booke_hv_asm.h |4 +- arch/powerpc/include/asm/kvm_host.h | 38 +++-
[PATCH] KVM: PPC: 44x: fix DCR read/write
When remembering the direction of a DCR transaction, we should write to the same variable that we interpret on later when doing vcpu_run again. Signed-off-by: Alexander Graf ag...@suse.de --- arch/powerpc/kvm/44x_emulate.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/kvm/44x_emulate.c b/arch/powerpc/kvm/44x_emulate.c index 1a793c4..35ec0a8 100644 --- a/arch/powerpc/kvm/44x_emulate.c +++ b/arch/powerpc/kvm/44x_emulate.c @@ -46,6 +46,7 @@ static int emulate_mtdcr(struct kvm_vcpu *vcpu, int rs, int dcrn) vcpu-run-dcr.dcrn = dcrn; vcpu-run-dcr.data = kvmppc_get_gpr(vcpu, rs); vcpu-run-dcr.is_write = 1; + vcpu-arch.dcr_is_write = 1; vcpu-arch.dcr_needed = 1; kvmppc_account_exit(vcpu, DCR_EXITS); return EMULATE_DO_DCR; @@ -80,6 +81,7 @@ static int emulate_mfdcr(struct kvm_vcpu *vcpu, int rt, int dcrn) vcpu-run-dcr.dcrn = dcrn; vcpu-run-dcr.data = 0; vcpu-run-dcr.is_write = 0; + vcpu-arch.dcr_is_write = 0; vcpu-arch.io_gpr = rt; vcpu-arch.dcr_needed = 1; kvmppc_account_exit(vcpu, DCR_EXITS); -- 1.6.0.2 -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
