Re: Windows 7 VM BSOD
I briefly tested Penryn, Westmere. Bug still could reproduce. how could I set level, model and enforce on libvirt ?! I could also test it if you could tell me how to add those options on libvirtd. On Wed, Dec 10, 2014 at 2:19 PM, Vadim Rozenfeld wrote: > On Wed, 2014-12-10 at 08:51 +0800, t...@tetrioncapital.com wrote: >> Hi, >> >> Anything you want me to try on my side? >> > There is an open bug in bugzilla which looks > pretty similar to your problem > https://bugzilla.redhat.com/show_bug.cgi?id=1139928 > > Please take a look at comment #18 posted by Eduardo > https://bugzilla.redhat.com/show_bug.cgi?id=1139928#c18 > > Best regards, > Vadim. > >> Sent from my BlackBerry 10 smartphone. >> >> Thomas Lau >> Director of Infrastructure >> Tetrion Capital Limited >> >> Direct: +852-3976-8903 >> Mobile: +852-9323-9670 >> Address: 20/F, IFC 1, Central district, Hong Kong >> Original Message >> From: Thomas Lau >> Sent: Tuesday, 9 December, 2014 4:24 PM >> To: Vadim Rozenfeld >> Cc: Zhang Haoyu; kvm; imammedo >> Subject: Re: Windows 7 VM BSOD >> >> Hi Vadim, >> >> Now turning on is OK somehow, shutdown still stuck. >> >> On Tue, Dec 9, 2014 at 4:03 PM, Vadim Rozenfeld wrote: >> > On Tue, 2014-12-09 at 15:54 +0800, Thomas Lau wrote: >> >> I changed CPU type to Westmere, it boot up with 0x05C BSOD >> > >> > It should be four parameters printed on the screen, right below >> > the error code string. Could you please post them? >> > >> > Vadim. >> > >> >> >> >> On Tue, Dec 9, 2014 at 3:10 PM, Vadim Rozenfeld >> >> wrote: >> >> > On Tue, 2014-12-09 at 11:54 +0800, Thomas Lau wrote: >> >> >> Hi Vadim, >> >> >> >> >> >> I want to quote back to your original post back in early 2014: >> >> >> https://www.mail-archive.com/kvm@vger.kernel.org/msg99782.html >> >> >> >> >> >> >> >> >> According to >> >> >> http://msdn.microsoft.com/en-us/library/windows/hardware/ff559069(v=vs.85).aspx >> >> >> the 0x5C means HAL_INITIALIZATION_FAILED >> >> >> >> >> >> Problem matched exactly, which I am using CPU IvyBridge-EP and I got >> >> >> same BSOD as well. >> >> > >> >> > Some CPU flags (feature bits) should be missing. >> >> > Can you try changing cpu type? >> >> > >> >> > Best regards, >> >> > Vadim. >> >> > >> >> >> >> >> >> Are we missing some hyperv feature? >> >> >> >> >> >> On Wed, Dec 3, 2014 at 7:29 PM, Vadim Rozenfeld >> >> >> wrote: >> >> >> > If you run WS2008(R2) or Win7 - always turn on relaxed timing. >> >> >> > Otherwise >> >> >> > it's just a matter of time when you hit 101 BOSD. >> >> >> > Bugcheck 78 is quite rare one. What is your setup, and how easy it's >> >> >> > reproducible? >> >> >> > >> >> >> > Best regards, >> >> >> > Vadim. >> >> >> > >> >> >> > On Wed, 2014-12-03 at 19:13 +0800, Thomas Lau wrote: >> >> >> >> "it works on your side" meaning that you had such issue but >> >> >> >> afterwards >> >> >> >> it's all fixed by apply hv_relaxed ? >> >> >> >> >> >> >> >> On Wed, Dec 3, 2014 at 7:08 PM, Zhang Haoyu >> >> >> >> wrote: >> >> >> >> >> https://bugzilla.redhat.com/show_bug.cgi?id=893857 >> >> >> >> >> >> >> >> >> >> In fact I am doing testing now, but are we fixing one problem and >> >> >> >> >> introduce other problem?! >> >> >> >> >> >> >> >> >> > I'm not sure about this, but it works on my side, >> >> >> >> > I think BSOD(error:0x0078) has been fixed, >> >> >> >> > please show your environment. >> >> >> >> > >> >> >> >> > Thanks, >> >> >> >> > Zhang Haoyu >> >> >> >> >> On Wed, Dec 3, 2014 at 6:36 PM, Thomas Lau >> >> >> >> >> wrote: >> >> >> >> >> > Hi, >> >> >> >> >> > >> >> >> >> >> > How do I know if my qemu-kvm version support this? >> >> >> >> >> > >> >> >> >> >> > On Wed, Dec 3, 2014 at 6:25 PM, Zhang Haoyu >> >> >> >> >> > wrote: >> >> >> >> >> >>> Hi All, >> >> >> >> >> >>> >> >> >> >> >> >>> I am running 3.13.0-24-generic kernel on Ubuntu 14, Windows >> >> >> >> >> >>> 7 VM >> >> >> >> >> >>> installation was fine, but it does random reboot by itself, >> >> >> >> >> >>> the error >> >> >> >> >> >>> code is 0x0101, does anyone know how to fix this? >> >> >> >> >> >> Could you try hv_relaxed, like "-cpu kvm64,hv_relaxed". >> >> >> >> >> >> >> >> >> >> >> >> Thanks, >> >> >> >> >> >> Zhang Haoyu >> >> >> >> > >> >> >> >> -- >> >> >> >> 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 >> >> >> > >> >> >> > >> >> >> >> >> >> >> >> >> >> >> > >> >> > >> >> >> >> >> >> >> > >> > >> >> >> > > -- Thomas Lau Director of Infrastructure Tetrion Capital Limited Direct: +852-3976-8903 Mobile: +852-9323-9670 Address: 20/F, IFC 1, Central district, Hong Kong -- 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: [Intel-gfx] [ANNOUNCE][RFC] KVMGT - the implementation of Intel GVT-g(full GPU virtualization) for KVM
> From: Song, Jike > Sent: Wednesday, December 10, 2014 2:34 PM > > CC Kevin. > > > On 12/09/2014 05:54 PM, Jan Kiszka wrote: > > On 2014-12-04 03:24, Jike Song wrote: > >> Hi all, > >> > >> We are pleased to announce the first release of KVMGT project. KVMGT > is > >> the implementation of Intel GVT-g technology, a full GPU virtualization > >> solution. Under Intel GVT-g, a virtual GPU instance is maintained for > >> each VM, with part of performance critical resources directly assigned. > >> The capability of running native graphics driver inside a VM, without > >> hypervisor intervention in performance critical paths, achieves a good > >> balance of performance, feature, and sharing capability. > >> > >> > >> KVMGT is still in the early stage: > >> > >>- Basic functions of full GPU virtualization works, guest can see a > >> full-featured vGPU. > >> We ran several 3D workloads such as lightsmark, nexuiz, urbanterror > >> and warsow. > >> > >>- Only Linux guest supported so far, and PPGTT must be disabled in > >> guest through a > >> kernel parameter(see README.kvmgt in QEMU). > >> > >>- This drop also includes some Xen specific changes, which will be > >> cleaned up later. > >> > >>- Our end goal is to upstream both XenGT and KVMGT, which shares > ~90% > >> logic for vGPU > >> device model (will be part of i915 driver), with only difference in > >> hypervisor > >> specific services > >> > >>- insufficient test coverage, so please bear with stability issues :) > >> > >> > >> > >> There are things need to be improved, esp. the KVM interfacing part: > >> > >> 1a domid was added to each KVMGT guest > >> > >> An ID is needed for foreground OS switching, e.g. > >> > >> # echo > > /sys/kernel/vgt/control/foreground_vm > >> > >> domid 0 is reserved for host OS. > >> > >> > >> 2SRCU workarounds. > >> > >> Some KVM functions, such as: > >> > >> kvm_io_bus_register_dev > >> install_new_memslots > >> > >> must be called *without* &kvm->srcu read-locked. Otherwise it > >> hangs. > >> > >> In KVMGT, we need to register an iodev only *after* BAR > >> registers are > >> written by guest. That means, we already have &kvm->srcu > hold - > >> trapping/emulating PIO(BAR registers) makes us in such a > condition. > >> That will make kvm_io_bus_register_dev hangs. > >> > >> Currently we have to disable rcu_assign_pointer() in such > >> functions. > >> > >> These were dirty workarounds, your suggestions are high > welcome! > >> > >> > >> 3syscalls were called to access "/dev/mem" from kernel > >> > >> An in-kernel memslot was added for aperture, but using syscalls > >> like > >> open and mmap to open and access the character device > "/dev/mem", > >> for pass-through. > >> > >> > >> > >> > >> The source codes(kernel, qemu as well as seabios) are available at github: > >> > >> git://github.com/01org/KVMGT-kernel > >> git://github.com/01org/KVMGT-qemu > >> git://github.com/01org/KVMGT-seabios > >> > >> In the KVMGT-qemu repository, there is a "README.kvmgt" to be referred. > >> > >> > >> > >> More information about Intel GVT-g and KVMGT can be found at: > >> > >> > https://www.usenix.org/conference/atc14/technical-sessions/presentation/tia > n > >> > >> > http://events.linuxfoundation.org/sites/events/files/slides/KVMGT-a%20Full%2 > 0GPU%20Virtualization%20Solution_1.pdf > >> > >> > >> > >> Appreciate your comments, BUG reports, and contributions! > >> > > > > There is an even increasing interest to keep KVM's in-kernel guest > > interface as small as possible, specifically for security reasons. I'm > > sure there are some good performance reasons to create a new in-kernel > > device model, but I suppose those will need good evidences why things > > are done in the way they finally should be - and not via a user-space > > device model. This is likely not a binary decision (all userspace vs. no > > userspace), it is more about the size and robustness of the in-kernel > > model vs. its performance. Thanks for explaining the background. We're not against the userspace model if applied, but based on our analysis we figured out the in-kernel model is the best suite, not just for performance reason, but also for the tight couple to i915 functionalities (scheduling, interrupt, security, etc.) and hypervisor functionalities (GPU shadow page table, etc.) which are best handled in kernel directly. Definitely we don't want to split it just for performance reason, w/o a functionally clear separation, because that just creates unnecessary/messy user/kernel interfaces. And now we've got i915 community's signal that they're willing to pick the core code into i915 driver, which we're currently working on. So, not to eliminate the possibility of user/kernel split, how about we first loo
Re: [Intel-gfx] [ANNOUNCE][RFC] KVMGT - the implementation of Intel GVT-g(full GPU virtualization) for KVM
CC Kevin. On 12/09/2014 05:54 PM, Jan Kiszka wrote: On 2014-12-04 03:24, Jike Song wrote: Hi all, We are pleased to announce the first release of KVMGT project. KVMGT is the implementation of Intel GVT-g technology, a full GPU virtualization solution. Under Intel GVT-g, a virtual GPU instance is maintained for each VM, with part of performance critical resources directly assigned. The capability of running native graphics driver inside a VM, without hypervisor intervention in performance critical paths, achieves a good balance of performance, feature, and sharing capability. KVMGT is still in the early stage: - Basic functions of full GPU virtualization works, guest can see a full-featured vGPU. We ran several 3D workloads such as lightsmark, nexuiz, urbanterror and warsow. - Only Linux guest supported so far, and PPGTT must be disabled in guest through a kernel parameter(see README.kvmgt in QEMU). - This drop also includes some Xen specific changes, which will be cleaned up later. - Our end goal is to upstream both XenGT and KVMGT, which shares ~90% logic for vGPU device model (will be part of i915 driver), with only difference in hypervisor specific services - insufficient test coverage, so please bear with stability issues :) There are things need to be improved, esp. the KVM interfacing part: 1a domid was added to each KVMGT guest An ID is needed for foreground OS switching, e.g. # echo >/sys/kernel/vgt/control/foreground_vm domid 0 is reserved for host OS. 2SRCU workarounds. Some KVM functions, such as: kvm_io_bus_register_dev install_new_memslots must be called *without* &kvm->srcu read-locked. Otherwise it hangs. In KVMGT, we need to register an iodev only *after* BAR registers are written by guest. That means, we already have &kvm->srcu hold - trapping/emulating PIO(BAR registers) makes us in such a condition. That will make kvm_io_bus_register_dev hangs. Currently we have to disable rcu_assign_pointer() in such functions. These were dirty workarounds, your suggestions are high welcome! 3syscalls were called to access "/dev/mem" from kernel An in-kernel memslot was added for aperture, but using syscalls like open and mmap to open and access the character device "/dev/mem", for pass-through. The source codes(kernel, qemu as well as seabios) are available at github: git://github.com/01org/KVMGT-kernel git://github.com/01org/KVMGT-qemu git://github.com/01org/KVMGT-seabios In the KVMGT-qemu repository, there is a "README.kvmgt" to be referred. More information about Intel GVT-g and KVMGT can be found at: https://www.usenix.org/conference/atc14/technical-sessions/presentation/tian http://events.linuxfoundation.org/sites/events/files/slides/KVMGT-a%20Full%20GPU%20Virtualization%20Solution_1.pdf Appreciate your comments, BUG reports, and contributions! There is an even increasing interest to keep KVM's in-kernel guest interface as small as possible, specifically for security reasons. I'm sure there are some good performance reasons to create a new in-kernel device model, but I suppose those will need good evidences why things are done in the way they finally should be - and not via a user-space device model. This is likely not a binary decision (all userspace vs. no userspace), it is more about the size and robustness of the in-kernel model vs. its performance. One aspect could also be important: Are there hardware improvements in sight that will eventually help to reduce the in-kernel device model and make the overall design even more robust? How will those changes fit best into a proposed user/kernel split? Jan -- Thanks, Jike ___ Intel-gfx mailing list intel-...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- 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: [ANNOUNCE][RFC] KVMGT - the implementation of Intel GVT-g(full GPU virtualization) for KVM
CC Kevin. On 12/09/2014 05:54 PM, Jan Kiszka wrote: On 2014-12-04 03:24, Jike Song wrote: Hi all, We are pleased to announce the first release of KVMGT project. KVMGT is the implementation of Intel GVT-g technology, a full GPU virtualization solution. Under Intel GVT-g, a virtual GPU instance is maintained for each VM, with part of performance critical resources directly assigned. The capability of running native graphics driver inside a VM, without hypervisor intervention in performance critical paths, achieves a good balance of performance, feature, and sharing capability. KVMGT is still in the early stage: - Basic functions of full GPU virtualization works, guest can see a full-featured vGPU. We ran several 3D workloads such as lightsmark, nexuiz, urbanterror and warsow. - Only Linux guest supported so far, and PPGTT must be disabled in guest through a kernel parameter(see README.kvmgt in QEMU). - This drop also includes some Xen specific changes, which will be cleaned up later. - Our end goal is to upstream both XenGT and KVMGT, which shares ~90% logic for vGPU device model (will be part of i915 driver), with only difference in hypervisor specific services - insufficient test coverage, so please bear with stability issues :) There are things need to be improved, esp. the KVM interfacing part: 1a domid was added to each KVMGT guest An ID is needed for foreground OS switching, e.g. # echo >/sys/kernel/vgt/control/foreground_vm domid 0 is reserved for host OS. 2SRCU workarounds. Some KVM functions, such as: kvm_io_bus_register_dev install_new_memslots must be called *without* &kvm->srcu read-locked. Otherwise it hangs. In KVMGT, we need to register an iodev only *after* BAR registers are written by guest. That means, we already have &kvm->srcu hold - trapping/emulating PIO(BAR registers) makes us in such a condition. That will make kvm_io_bus_register_dev hangs. Currently we have to disable rcu_assign_pointer() in such functions. These were dirty workarounds, your suggestions are high welcome! 3syscalls were called to access "/dev/mem" from kernel An in-kernel memslot was added for aperture, but using syscalls like open and mmap to open and access the character device "/dev/mem", for pass-through. The source codes(kernel, qemu as well as seabios) are available at github: git://github.com/01org/KVMGT-kernel git://github.com/01org/KVMGT-qemu git://github.com/01org/KVMGT-seabios In the KVMGT-qemu repository, there is a "README.kvmgt" to be referred. More information about Intel GVT-g and KVMGT can be found at: https://www.usenix.org/conference/atc14/technical-sessions/presentation/tian http://events.linuxfoundation.org/sites/events/files/slides/KVMGT-a%20Full%20GPU%20Virtualization%20Solution_1.pdf Appreciate your comments, BUG reports, and contributions! There is an even increasing interest to keep KVM's in-kernel guest interface as small as possible, specifically for security reasons. I'm sure there are some good performance reasons to create a new in-kernel device model, but I suppose those will need good evidences why things are done in the way they finally should be - and not via a user-space device model. This is likely not a binary decision (all userspace vs. no userspace), it is more about the size and robustness of the in-kernel model vs. its performance. One aspect could also be important: Are there hardware improvements in sight that will eventually help to reduce the in-kernel device model and make the overall design even more robust? How will those changes fit best into a proposed user/kernel split? Jan -- Thanks, Jike -- 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: Windows 7 VM BSOD
On Wed, 2014-12-10 at 08:51 +0800, t...@tetrioncapital.com wrote: > Hi, > > Anything you want me to try on my side? > There is an open bug in bugzilla which looks pretty similar to your problem https://bugzilla.redhat.com/show_bug.cgi?id=1139928 Please take a look at comment #18 posted by Eduardo https://bugzilla.redhat.com/show_bug.cgi?id=1139928#c18 Best regards, Vadim. > Sent from my BlackBerry 10 smartphone. > > Thomas Lau > Director of Infrastructure > Tetrion Capital Limited > > Direct: +852-3976-8903 > Mobile: +852-9323-9670 > Address: 20/F, IFC 1, Central district, Hong Kong > Original Message > From: Thomas Lau > Sent: Tuesday, 9 December, 2014 4:24 PM > To: Vadim Rozenfeld > Cc: Zhang Haoyu; kvm; imammedo > Subject: Re: Windows 7 VM BSOD > > Hi Vadim, > > Now turning on is OK somehow, shutdown still stuck. > > On Tue, Dec 9, 2014 at 4:03 PM, Vadim Rozenfeld wrote: > > On Tue, 2014-12-09 at 15:54 +0800, Thomas Lau wrote: > >> I changed CPU type to Westmere, it boot up with 0x05C BSOD > > > > It should be four parameters printed on the screen, right below > > the error code string. Could you please post them? > > > > Vadim. > > > >> > >> On Tue, Dec 9, 2014 at 3:10 PM, Vadim Rozenfeld > >> wrote: > >> > On Tue, 2014-12-09 at 11:54 +0800, Thomas Lau wrote: > >> >> Hi Vadim, > >> >> > >> >> I want to quote back to your original post back in early 2014: > >> >> https://www.mail-archive.com/kvm@vger.kernel.org/msg99782.html > >> >> > >> >> > >> >> According to > >> >> http://msdn.microsoft.com/en-us/library/windows/hardware/ff559069(v=vs.85).aspx > >> >> the 0x5C means HAL_INITIALIZATION_FAILED > >> >> > >> >> Problem matched exactly, which I am using CPU IvyBridge-EP and I got > >> >> same BSOD as well. > >> > > >> > Some CPU flags (feature bits) should be missing. > >> > Can you try changing cpu type? > >> > > >> > Best regards, > >> > Vadim. > >> > > >> >> > >> >> Are we missing some hyperv feature? > >> >> > >> >> On Wed, Dec 3, 2014 at 7:29 PM, Vadim Rozenfeld > >> >> wrote: > >> >> > If you run WS2008(R2) or Win7 - always turn on relaxed timing. > >> >> > Otherwise > >> >> > it's just a matter of time when you hit 101 BOSD. > >> >> > Bugcheck 78 is quite rare one. What is your setup, and how easy it's > >> >> > reproducible? > >> >> > > >> >> > Best regards, > >> >> > Vadim. > >> >> > > >> >> > On Wed, 2014-12-03 at 19:13 +0800, Thomas Lau wrote: > >> >> >> "it works on your side" meaning that you had such issue but > >> >> >> afterwards > >> >> >> it's all fixed by apply hv_relaxed ? > >> >> >> > >> >> >> On Wed, Dec 3, 2014 at 7:08 PM, Zhang Haoyu > >> >> >> wrote: > >> >> >> >> https://bugzilla.redhat.com/show_bug.cgi?id=893857 > >> >> >> >> > >> >> >> >> In fact I am doing testing now, but are we fixing one problem and > >> >> >> >> introduce other problem?! > >> >> >> >> > >> >> >> > I'm not sure about this, but it works on my side, > >> >> >> > I think BSOD(error:0x0078) has been fixed, > >> >> >> > please show your environment. > >> >> >> > > >> >> >> > Thanks, > >> >> >> > Zhang Haoyu > >> >> >> >> On Wed, Dec 3, 2014 at 6:36 PM, Thomas Lau > >> >> >> >> wrote: > >> >> >> >> > Hi, > >> >> >> >> > > >> >> >> >> > How do I know if my qemu-kvm version support this? > >> >> >> >> > > >> >> >> >> > On Wed, Dec 3, 2014 at 6:25 PM, Zhang Haoyu > >> >> >> >> > wrote: > >> >> >> >> >>> Hi All, > >> >> >> >> >>> > >> >> >> >> >>> I am running 3.13.0-24-generic kernel on Ubuntu 14, Windows 7 > >> >> >> >> >>> VM > >> >> >> >> >>> installation was fine, but it does random reboot by itself, > >> >> >> >> >>> the error > >> >> >> >> >>> code is 0x0101, does anyone know how to fix this? > >> >> >> >> >> Could you try hv_relaxed, like "-cpu kvm64,hv_relaxed". > >> >> >> >> >> > >> >> >> >> >> Thanks, > >> >> >> >> >> Zhang Haoyu > >> >> >> > > >> >> >> -- > >> >> >> 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 > >> >> > > >> >> > > >> >> > >> >> > >> >> > >> > > >> > > >> > >> > >> > > > > > > > -- 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] KVM: x86: nVMX: support for MSR loading/storing
2014-12-10 5:12 GMT+08:00 Eugene Korenevsky : >> I have added Jan and Wincy to the CC list since they reviewed your earlier >> proposal. >> I think it would be better to split this up as I mentioned earlier, however, >> if the other reviewers and the maintainer don't have objections, I am ok :) > > OK, the final patch is following. > Hi, Eugene, is it okay to split my part up? Thanks, WIncy -- 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
Lack of support on Ivy Bridge - EP processor
Hi all, Does anyone from Intel or Redhat mind to submit patch to support Ivy Bridge - EP on KVM? The problem is very bad because Windows guest can't shutdown on this CPU structure, even I changed CPU type on guest, still doesn't help. Sent from my BlackBerry 10 smartphone. Thomas Lau Director of Infrastructure Tetrion Capital Limited Direct: +852-3976-8903 Mobile: +852-9323-9670 Address: 20/F, IFC 1, Central district, Hong Kong -- 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: Windows 7 VM BSOD
Hi, Anything you want me to try on my side? Sent from my BlackBerry 10 smartphone. Thomas Lau Director of Infrastructure Tetrion Capital Limited Direct: +852-3976-8903 Mobile: +852-9323-9670 Address: 20/F, IFC 1, Central district, Hong Kong Original Message From: Thomas Lau Sent: Tuesday, 9 December, 2014 4:24 PM To: Vadim Rozenfeld Cc: Zhang Haoyu; kvm; imammedo Subject: Re: Windows 7 VM BSOD Hi Vadim, Now turning on is OK somehow, shutdown still stuck. On Tue, Dec 9, 2014 at 4:03 PM, Vadim Rozenfeld wrote: > On Tue, 2014-12-09 at 15:54 +0800, Thomas Lau wrote: >> I changed CPU type to Westmere, it boot up with 0x05C BSOD > > It should be four parameters printed on the screen, right below > the error code string. Could you please post them? > > Vadim. > >> >> On Tue, Dec 9, 2014 at 3:10 PM, Vadim Rozenfeld wrote: >> > On Tue, 2014-12-09 at 11:54 +0800, Thomas Lau wrote: >> >> Hi Vadim, >> >> >> >> I want to quote back to your original post back in early 2014: >> >> https://www.mail-archive.com/kvm@vger.kernel.org/msg99782.html >> >> >> >> >> >> According to >> >> http://msdn.microsoft.com/en-us/library/windows/hardware/ff559069(v=vs.85).aspx >> >> the 0x5C means HAL_INITIALIZATION_FAILED >> >> >> >> Problem matched exactly, which I am using CPU IvyBridge-EP and I got >> >> same BSOD as well. >> > >> > Some CPU flags (feature bits) should be missing. >> > Can you try changing cpu type? >> > >> > Best regards, >> > Vadim. >> > >> >> >> >> Are we missing some hyperv feature? >> >> >> >> On Wed, Dec 3, 2014 at 7:29 PM, Vadim Rozenfeld >> >> wrote: >> >> > If you run WS2008(R2) or Win7 - always turn on relaxed timing. Otherwise >> >> > it's just a matter of time when you hit 101 BOSD. >> >> > Bugcheck 78 is quite rare one. What is your setup, and how easy it's >> >> > reproducible? >> >> > >> >> > Best regards, >> >> > Vadim. >> >> > >> >> > On Wed, 2014-12-03 at 19:13 +0800, Thomas Lau wrote: >> >> >> "it works on your side" meaning that you had such issue but afterwards >> >> >> it's all fixed by apply hv_relaxed ? >> >> >> >> >> >> On Wed, Dec 3, 2014 at 7:08 PM, Zhang Haoyu >> >> >> wrote: >> >> >> >> https://bugzilla.redhat.com/show_bug.cgi?id=893857 >> >> >> >> >> >> >> >> In fact I am doing testing now, but are we fixing one problem and >> >> >> >> introduce other problem?! >> >> >> >> >> >> >> > I'm not sure about this, but it works on my side, >> >> >> > I think BSOD(error:0x0078) has been fixed, >> >> >> > please show your environment. >> >> >> > >> >> >> > Thanks, >> >> >> > Zhang Haoyu >> >> >> >> On Wed, Dec 3, 2014 at 6:36 PM, Thomas Lau >> >> >> >> wrote: >> >> >> >> > Hi, >> >> >> >> > >> >> >> >> > How do I know if my qemu-kvm version support this? >> >> >> >> > >> >> >> >> > On Wed, Dec 3, 2014 at 6:25 PM, Zhang Haoyu >> >> >> >> > wrote: >> >> >> >> >>> Hi All, >> >> >> >> >>> >> >> >> >> >>> I am running 3.13.0-24-generic kernel on Ubuntu 14, Windows 7 VM >> >> >> >> >>> installation was fine, but it does random reboot by itself, the >> >> >> >> >>> error >> >> >> >> >>> code is 0x0101, does anyone know how to fix this? >> >> >> >> >> Could you try hv_relaxed, like "-cpu kvm64,hv_relaxed". >> >> >> >> >> >> >> >> >> >> Thanks, >> >> >> >> >> Zhang Haoyu >> >> >> > >> >> >> -- >> >> >> 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 >> >> > >> >> > >> >> >> >> >> >> >> > >> > >> >> >> > > -- Thomas Lau Director of Infrastructure Tetrion Capital Limited Direct: +852-3976-8903 Mobile: +852-9323-9670 Address: 20/F, IFC 1, Central district, Hong Kong -- 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 v2 1/2] x86, platform, xen, kconfig: clarify kvmconfig is for kvm
On Tue, Dec 09, 2014 at 03:35:37PM -0800, Luis R. Rodriguez wrote: > From: "Luis R. Rodriguez" > > We'll be adding options for xen as well. > > Cc: Josh Triplett > Cc: Borislav Petkov > Cc: Pekka Enberg > Cc: David Rientjes > Cc: Michal Marek > Cc: Randy Dunlap > Cc: penb...@kernel.org > Cc: levinsasha...@gmail.com > Cc: mtosa...@redhat.com > Cc: fengguang...@intel.com > Cc: David Vrabel > Cc: Ian Campbell > Cc: Konrad Rzeszutek Wilk > Cc: xen-de...@lists.xenproject.org > Acked-by: David Rientjes > Acked-by: Borislav Petkov > Signed-off-by: Luis R. Rodriguez Reviewed-by: Josh Triplett > scripts/kconfig/Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile > index 9645c07..ff612b0 100644 > --- a/scripts/kconfig/Makefile > +++ b/scripts/kconfig/Makefile > @@ -141,7 +141,7 @@ help: > @echo ' randconfig - New config with random answer to all > options' > @echo ' listnewconfig - List new options' > @echo ' olddefconfig- Same as silentoldconfig but sets new > symbols to their default value' > - @echo ' kvmconfig - Enable additional options for guest kernel > support' > + @echo ' kvmconfig - Enable additional options for kvm guest > kernel support' > @echo ' tinyconfig - Configure the tiniest possible kernel' > > # lxdialog stuff > -- > 2.1.1 > -- 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
[PATCH v2 1/2] x86, platform, xen, kconfig: clarify kvmconfig is for kvm
From: "Luis R. Rodriguez" We'll be adding options for xen as well. Cc: Josh Triplett Cc: Borislav Petkov Cc: Pekka Enberg Cc: David Rientjes Cc: Michal Marek Cc: Randy Dunlap Cc: penb...@kernel.org Cc: levinsasha...@gmail.com Cc: mtosa...@redhat.com Cc: fengguang...@intel.com Cc: David Vrabel Cc: Ian Campbell Cc: Konrad Rzeszutek Wilk Cc: xen-de...@lists.xenproject.org Acked-by: David Rientjes Acked-by: Borislav Petkov Signed-off-by: Luis R. Rodriguez --- scripts/kconfig/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile index 9645c07..ff612b0 100644 --- a/scripts/kconfig/Makefile +++ b/scripts/kconfig/Makefile @@ -141,7 +141,7 @@ help: @echo ' randconfig - New config with random answer to all options' @echo ' listnewconfig - List new options' @echo ' olddefconfig- Same as silentoldconfig but sets new symbols to their default value' - @echo ' kvmconfig - Enable additional options for guest kernel support' + @echo ' kvmconfig - Enable additional options for kvm guest kernel support' @echo ' tinyconfig - Configure the tiniest possible kernel' # lxdialog stuff -- 2.1.1 -- 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
[PATCH v2 2/2] x86, arm, platform, xen, kconfig: add xen defconfig helper
From: "Luis R. Rodriguez" This lets you build a kernel which can support xen dom0 or xen guests by just using: make xenconfig on both x86 and arm64 kernels. This also splits out the options which are available currently to be built with x86 and 'make ARCH=arm64' under a shared config. Technically xen supports a dom0 kernel and also a guest kernel configuration but upon review with the xen team since we don't have many dom0 options its best to just combine these two into one. Cc: Josh Triplett Cc: Borislav Petkov Cc: Pekka Enberg Cc: David Rientjes Cc: Michal Marek Cc: Randy Dunlap Cc: penb...@kernel.org Cc: levinsasha...@gmail.com Cc: mtosa...@redhat.com Cc: fengguang...@intel.com Cc: David Vrabel Cc: Ian Campbell Cc: Konrad Rzeszutek Wilk Cc: xen-de...@lists.xenproject.org Reviewed-by: Josh Triplett Signed-off-by: Luis R. Rodriguez --- arch/x86/configs/xen.config | 7 +++ kernel/configs/xen.config | 30 ++ scripts/kconfig/Makefile| 5 + 3 files changed, 42 insertions(+) create mode 100644 arch/x86/configs/xen.config create mode 100644 kernel/configs/xen.config diff --git a/arch/x86/configs/xen.config b/arch/x86/configs/xen.config new file mode 100644 index 000..92b8587f --- /dev/null +++ b/arch/x86/configs/xen.config @@ -0,0 +1,7 @@ +# x86 xen specific config options +CONFIG_XEN_PVHVM=y +CONFIG_XEN_MAX_DOMAIN_MEMORY=500 +CONFIG_XEN_SAVE_RESTORE=y +# CONFIG_XEN_DEBUG_FS is not set +CONFIG_XEN_PVH=y +CONFIG_XEN_MCE_LOG=y diff --git a/kernel/configs/xen.config b/kernel/configs/xen.config new file mode 100644 index 000..d2ec010 --- /dev/null +++ b/kernel/configs/xen.config @@ -0,0 +1,30 @@ +# generic config +CONFIG_XEN=y +CONFIG_XEN_DOM0=y +CONFIG_PCI_XEN=y +CONFIG_XEN_PCIDEV_FRONTEND=m +CONFIG_XEN_BLKDEV_FRONTEND=m +CONFIG_XEN_BLKDEV_BACKEND=m +CONFIG_XEN_NETDEV_FRONTEND=m +CONFIG_XEN_NETDEV_BACKEND=m +CONFIG_INPUT_XEN_KBDDEV_FRONTEND=y +CONFIG_HVC_XEN=y +CONFIG_HVC_XEN_FRONTEND=y +CONFIG_TCG_XEN=m +CONFIG_XEN_WDT=m +CONFIG_XEN_FBDEV_FRONTEND=y +CONFIG_XEN_BALLOON=y +CONFIG_XEN_BALLOON_MEMORY_HOTPLUG=y +CONFIG_XEN_SCRUB_PAGES=y +CONFIG_XEN_DEV_EVTCHN=m +CONFIG_XEN_BACKEND=y +CONFIG_XENFS=m +CONFIG_XEN_COMPAT_XENFS=y +CONFIG_XEN_SYS_HYPERVISOR=y +CONFIG_XEN_XENBUS_FRONTEND=y +CONFIG_XEN_GNTDEV=m +CONFIG_XEN_GRANT_DEV_ALLOC=m +CONFIG_SWIOTLB_XEN=y +CONFIG_XEN_PCIDEV_BACKEND=m +CONFIG_XEN_PRIVCMD=m +CONFIG_XEN_ACPI_PROCESSOR=m diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile index ff612b0..f4a8f89 100644 --- a/scripts/kconfig/Makefile +++ b/scripts/kconfig/Makefile @@ -117,6 +117,10 @@ PHONY += kvmconfig kvmconfig: $(call mergeconfig,kvm_guest) +PHONY += xenconfig +xenconfig: + $(call mergeconfig,xen) + PHONY += tinyconfig tinyconfig: allnoconfig $(call mergeconfig,tiny) @@ -142,6 +146,7 @@ help: @echo ' listnewconfig - List new options' @echo ' olddefconfig- Same as silentoldconfig but sets new symbols to their default value' @echo ' kvmconfig - Enable additional options for kvm guest kernel support' + @echo ' xenconfig - Enable additional options for xen dom0 and guest kernel support' @echo ' tinyconfig - Configure the tiniest possible kernel' # lxdialog stuff -- 2.1.1 -- 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
[PATCH v2 0/2] x86/arm64: add xenconfig
From: "Luis R. Rodriguez" This v2 addreses some minor feedback on patch 2, and just mends in the review tags. Luis R. Rodriguez (2): x86, platform, xen, kconfig: clarify kvmconfig is for kvm x86, arm, platform, xen, kconfig: add xen defconfig helper arch/x86/configs/xen.config | 7 +++ kernel/configs/xen.config | 30 ++ scripts/kconfig/Makefile| 7 ++- 3 files changed, 43 insertions(+), 1 deletion(-) create mode 100644 arch/x86/configs/xen.config create mode 100644 kernel/configs/xen.config -- 2.1.1 -- 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: [Xen-devel] [PATCH v3 2/2] x86, arm64, platform, xen, kconfig: add xen defconfig helper
On Tue, Dec 9, 2014 at 12:37 PM, Julien Grall wrote: > On 09/12/14 20:22, Luis R. Rodriguez wrote: >> On Tue, Dec 9, 2014 at 1:06 AM, Julien Grall wrote: >>> Hello Luis, >>> >>> On 08/12/2014 23:05, Luis R. Rodriguez wrote: diff --git a/kernel/configs/xen.config b/kernel/configs/xen.config new file mode 100644 index 000..0d0eb6d --- /dev/null +++ b/kernel/configs/xen.config +CONFIG_XEN_MCE_LOG=y >>> >>> >>> MCE is x86 specific. >> >> That's what I thought too but its available for arm64, so should we >> fix that Kconfig to depend on x86? > > Are you sure? On the Linus's repo I have: > > config XEN_MCE_LOG > bool "Xen platform mcelog" > depends on XEN_DOM0 && X86_64 && X86_MCE > > Anyway, the MCE interface in the hypervisor is implemented in arch/x86 > not in common code. OK I'll move to x86. +CONFIG_XEN_HAVE_PVMMU=y >>> >>> >>> We don't have PVMMU support on ARM. Shouldn't you move this config in >>> architecture specific code? >> >> If you are sure then yes. > > I'm 100% sure. MMU is handled by the hardware on ARM. > > Thinking a bit more about this option. CONFIG_XEN_HAVE_PVMMU can't be > selected by the user. It's automatically added per platform (for > instance see arch/x86/xen/Kconfig). > > So maybe it should not even appear in the one of the fragment configs? And I'll remove this one. Luis -- 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] KVM: x86: nVMX: support for MSR loading/storing
2014-12-10 00:18+0300, Eugene Korenevsky: > +static bool vmx_load_msr_entry_verify(struct kvm_vcpu *vcpu, > + struct vmx_msr_entry *e) [...] > + /* x2APIC MSR accesses are not allowed */ > + if (apic_x2apic_mode(vcpu->arch.apic) && (e->index >> 24) == 0x800) > + return false; GCC doesn't warn that "((u32)e->index >> 24) == 0x800" is always false? I think SDM says '(e->index >> 8) == 0x8'. -- 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
[PATCH] KVM: x86: nVMX: support for MSR loading/storing
Several hypervisors use MSR loading/storing to run guests on VMX.
This patch implements emulation of this feature and allows these
hypervisors to work in L1.
The following is emulated:
- Loading MSRs on VM-entries
- Saving MSRs on VM-exits
- Loading MSRs on VM-exits
Actions taken on loading MSRs:
- MSR load area is verified
- For each MSR entry from load area:
- MSR load entry is read and verified
- MSR value is safely written
Actions taken on storing MSRs:
- MSR store area is verified
- For each MSR entry from store area:
- MSR entry is read and verified
- MSR value is safely read using MSR index from MSR entry
- MSR value is written to MSR entry
The code performs checks required by Intel Software Developer Manual.
Signed-off-by: Eugene Korenevsky
---
arch/x86/include/asm/vmx.h| 6 +
arch/x86/include/uapi/asm/msr-index.h | 3 +
arch/x86/include/uapi/asm/vmx.h | 2 +
arch/x86/kvm/vmx.c| 206 --
virt/kvm/kvm_main.c | 1 +
5 files changed, 211 insertions(+), 7 deletions(-)
diff --git a/arch/x86/include/asm/vmx.h b/arch/x86/include/asm/vmx.h
index 45afaee..8bdb247 100644
--- a/arch/x86/include/asm/vmx.h
+++ b/arch/x86/include/asm/vmx.h
@@ -457,6 +457,12 @@ struct vmx_msr_entry {
#define ENTRY_FAIL_VMCS_LINK_PTR 4
/*
+ * VMX Abort codes
+ */
+#define VMX_ABORT_MSR_STORE_FAILURE1
+#define VMX_ABORT_MSR_LOAD_FAILURE 4
+
+/*
* VM-instruction error numbers
*/
enum vm_instruction_error_number {
diff --git a/arch/x86/include/uapi/asm/msr-index.h
b/arch/x86/include/uapi/asm/msr-index.h
index e21331c..3c9c601 100644
--- a/arch/x86/include/uapi/asm/msr-index.h
+++ b/arch/x86/include/uapi/asm/msr-index.h
@@ -316,6 +316,9 @@
#define MSR_IA32_UCODE_WRITE 0x0079
#define MSR_IA32_UCODE_REV 0x008b
+#define MSR_IA32_SMM_MONITOR_CTL 0x009b
+#define MSR_IA32_SMBASE0x009e
+
#define MSR_IA32_PERF_STATUS 0x0198
#define MSR_IA32_PERF_CTL 0x0199
#define MSR_AMD_PSTATE_DEF_BASE0xc0010064
diff --git a/arch/x86/include/uapi/asm/vmx.h b/arch/x86/include/uapi/asm/vmx.h
index b813bf9..52ad8e2 100644
--- a/arch/x86/include/uapi/asm/vmx.h
+++ b/arch/x86/include/uapi/asm/vmx.h
@@ -56,6 +56,7 @@
#define EXIT_REASON_MSR_READ31
#define EXIT_REASON_MSR_WRITE 32
#define EXIT_REASON_INVALID_STATE 33
+#define EXIT_REASON_MSR_LOAD_FAILURE34
#define EXIT_REASON_MWAIT_INSTRUCTION 36
#define EXIT_REASON_MONITOR_INSTRUCTION 39
#define EXIT_REASON_PAUSE_INSTRUCTION 40
@@ -116,6 +117,7 @@
{ EXIT_REASON_APIC_WRITE,"APIC_WRITE" }, \
{ EXIT_REASON_EOI_INDUCED, "EOI_INDUCED" }, \
{ EXIT_REASON_INVALID_STATE, "INVALID_STATE" }, \
+ { EXIT_REASON_MSR_LOAD_FAILURE, "MSR_LOAD_FAILURE" }, \
{ EXIT_REASON_INVD, "INVD" }, \
{ EXIT_REASON_INVVPID, "INVVPID" }, \
{ EXIT_REASON_INVPCID, "INVPCID" }, \
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 9bcc871..636a4c4 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -8571,6 +8571,173 @@ static void prepare_vmcs02(struct kvm_vcpu *vcpu,
struct vmcs12 *vmcs12)
kvm_register_write(vcpu, VCPU_REGS_RIP, vmcs12->guest_rip);
}
+static bool vmx_msr_switch_area_verify(struct kvm_vcpu *vcpu,
+ unsigned long count_field,
+ unsigned long addr_field,
+ int maxphyaddr)
+{
+ u64 count, addr;
+
+ if (vmcs12_read_any(vcpu, count_field, &count) ||
+ vmcs12_read_any(vcpu, addr_field, &addr)) {
+ WARN_ON(1);
+ return false;
+ }
+ if (!IS_ALIGNED(addr, 16))
+ goto fail;
+ if (addr >> maxphyaddr)
+ goto fail;
+ if ((addr + count * sizeof(struct vmx_msr_entry) - 1) >> maxphyaddr)
+ goto fail;
+ return true;
+fail:
+ pr_warn_ratelimited(
+ "nVMX: invalid MSR switch (0x%lx, 0x%lx, %d, %llu, 0x%08llx)",
+ count_field, addr_field, maxphyaddr, count, addr);
+ return false;
+}
+
+static bool nested_vmx_msr_switch_verify(struct kvm_vcpu *vcpu,
+struct vmcs12 *vmcs12)
+{
+ int maxphyaddr;
+
+ if (vmcs12->vm_exit_msr_load_count == 0 &&
+ vmcs12->vm_exit_msr_store_count == 0 &&
+ vmcs12->vm_entry_msr_load_count == 0)
+ return true; /* Fast path */
+ maxphyaddr = cpuid_maxphyaddr(vcpu);
+ return vmx_msr_switch_area_verify(vcpu, VM_EXIT_MSR_LOAD_COUNT,
+ VM_EXIT_MSR_LOAD_ADDR, maxphyaddr) &&
+ vmx_msr_switch_area_verify(vcpu, VM_EXIT_MSR_STORE_COUNT,
+
Re: [PATCH] KVM: x86: nVMX: support for MSR loading/storing
> I have added Jan and Wincy to the CC list since they reviewed your earlier > proposal. > I think it would be better to split this up as I mentioned earlier, however, > if the other reviewers and the maintainer don't have objections, I am ok :) OK, the final patch is following. -- Eugene -- 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 v3 7/8] KVM: kvm-vfio: generic forwarding control
On Tue, 2014-12-09 at 17:19 +0100, Eric Auger wrote:
> On 11/24/2014 09:56 PM, Alex Williamson wrote:
> > On Sun, 2014-11-23 at 19:35 +0100, Eric Auger wrote:
> >> This patch introduces a new KVM_DEV_VFIO_DEVICE group.
> >>
> >> This is a new control channel which enables KVM to cooperate with
> >> viable VFIO devices.
> >>
> >> Functions are introduced to check the validity of a VFIO device
> >> file descriptor, increment/decrement the ref counter of the VFIO
> >> device.
> >>
> >> The patch introduces 2 attributes for this new device group:
> >> KVM_DEV_VFIO_DEVICE_FORWARD_IRQ, KVM_DEV_VFIO_DEVICE_UNFORWARD_IRQ.
> >> Their purpose is to turn a VFIO device IRQ into a forwarded IRQ and
> >> unset respectively unset the feature.
> >>
> >> The VFIO device stores a list of registered forwarded IRQs. The reference
> >> counter of the device is incremented each time a new IRQ is forwarded.
> >> Reference counter is decremented when the IRQ forwarding is unset.
> >>
> >> The forwarding programmming is architecture specific, implemented in
> >> kvm_arch_set_fwd_state function. Architecture specific implementation is
> >> enabled when __KVM_HAVE_ARCH_KVM_VFIO_FORWARD is set. When not set those
> >> functions are void.
> >>
> >> Signed-off-by: Eric Auger
> >>
> >> ---
> >>
> >> v2 -> v3:
> >> - add API comments in kvm_host.h
> >> - improve the commit message
> >> - create a private kvm_vfio_fwd_irq struct
> >> - fwd_irq_action replaced by a bool and removal of VFIO_IRQ_CLEANUP. This
> >> latter action will be handled in vgic.
> >> - add a vfio_device handle argument to kvm_arch_set_fwd_state. The goal is
> >> to move platform specific stuff in architecture specific code.
> >> - kvm_arch_set_fwd_state renamed into kvm_arch_vfio_set_forward
> >> - increment the ref counter each time we do an IRQ forwarding and decrement
> >> this latter each time one IRQ forward is unset. Simplifies the whole
> >> ref counting.
> >> - simplification of list handling: create, search, removal
> >>
> >> v1 -> v2:
> >> - __KVM_HAVE_ARCH_KVM_VFIO renamed into __KVM_HAVE_ARCH_KVM_VFIO_FORWARD
> >> - original patch file separated into 2 parts: generic part moved in vfio.c
> >> and ARM specific part(kvm_arch_set_fwd_state)
> >> ---
> >> include/linux/kvm_host.h | 28 ++
> >> virt/kvm/vfio.c | 249
> >> ++-
> >> 2 files changed, 274 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> >> index ea53b04..0b9659d 100644
> >> --- a/include/linux/kvm_host.h
> >> +++ b/include/linux/kvm_host.h
> >> @@ -1076,6 +1076,15 @@ struct kvm_device_ops {
> >> unsigned long arg);
> >> };
> >>
> >> +/* internal self-contained structure describing a forwarded IRQ */
> >> +struct kvm_fwd_irq {
> >> + struct kvm *kvm; /* VM to inject the GSI into */
> >> + struct vfio_device *vdev; /* vfio device the IRQ belongs to */
> >> + __u32 index; /* VFIO device IRQ index */
> >> + __u32 subindex; /* VFIO device IRQ subindex */
> >> + __u32 gsi; /* gsi, ie. virtual IRQ number */
> >> +};
> >> +
> >> void kvm_device_get(struct kvm_device *dev);
> >> void kvm_device_put(struct kvm_device *dev);
> >> struct kvm_device *kvm_device_from_filp(struct file *filp);
> >> @@ -1085,6 +1094,25 @@ void kvm_unregister_device_ops(u32 type);
> >> extern struct kvm_device_ops kvm_mpic_ops;
> >> extern struct kvm_device_ops kvm_xics_ops;
> >>
> >> +#ifdef __KVM_HAVE_ARCH_KVM_VFIO_FORWARD
> >> +/**
> >> + * kvm_arch_vfio_set_forward - changes the forwarded state of an IRQ
> >> + *
> >> + * @fwd_irq: handle to the forwarded irq struct
> >> + * @forward: true means forwarded, false means not forwarded
> >> + * returns 0 on success, < 0 on failure
> >> + */
> >> +int kvm_arch_vfio_set_forward(struct kvm_fwd_irq *fwd_irq,
> >> +bool forward);
> >
> > We could add a struct device* to the args list or into struct
> > kvm_fwd_irq so that arch code doesn't need to touch the vdev. arch code
> > has no business dealing with references to the vfio_device.
> >
> >> +
> >> +#else
> >> +static inline int kvm_arch_vfio_set_forward(struct kvm_fwd_irq *fwd_irq,
> >> + bool forward)
> >> +{
> >> + return 0;
> >> +}
> >> +#endif
> >> +
> >> #ifdef CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT
> >>
> >> static inline void kvm_vcpu_set_in_spin_loop(struct kvm_vcpu *vcpu, bool
> >> val)
> >> diff --git a/virt/kvm/vfio.c b/virt/kvm/vfio.c
> >> index 6f0cc34..af178bb 100644
> >> --- a/virt/kvm/vfio.c
> >> +++ b/virt/kvm/vfio.c
> >> @@ -25,8 +25,16 @@ struct kvm_vfio_group {
> >>struct vfio_group *vfio_group;
> >> };
> >>
> >> +/* private linkable kvm_fwd_irq struct */
> >> +struct kvm_vfio_fwd_irq_node {
> >> + struct list_head link;
> >> + struct kvm_fwd_irq fwd_irq;
> >> +};
> >> +
> >> struct kvm_vfio {
> >>struct list_head group_list;
> >> + /* list of registered VFIO forwarded IRQs *
Re: [Xen-devel] [PATCH v3 2/2] x86, arm64, platform, xen, kconfig: add xen defconfig helper
On 09/12/14 20:22, Luis R. Rodriguez wrote: > On Tue, Dec 9, 2014 at 1:06 AM, Julien Grall wrote: >> Hello Luis, >> >> On 08/12/2014 23:05, Luis R. Rodriguez wrote: >>> >>> diff --git a/kernel/configs/xen.config b/kernel/configs/xen.config >>> new file mode 100644 >>> index 000..0d0eb6d >>> --- /dev/null >>> +++ b/kernel/configs/xen.config >>> +CONFIG_XEN_MCE_LOG=y >> >> >> MCE is x86 specific. > > That's what I thought too but its available for arm64, so should we > fix that Kconfig to depend on x86? Are you sure? On the Linus's repo I have: config XEN_MCE_LOG bool "Xen platform mcelog" depends on XEN_DOM0 && X86_64 && X86_MCE Anyway, the MCE interface in the hypervisor is implemented in arch/x86 not in common code. >>> +CONFIG_XEN_HAVE_PVMMU=y >> >> >> We don't have PVMMU support on ARM. Shouldn't you move this config in >> architecture specific code? > > If you are sure then yes. I'm 100% sure. MMU is handled by the hardware on ARM. Thinking a bit more about this option. CONFIG_XEN_HAVE_PVMMU can't be selected by the user. It's automatically added per platform (for instance see arch/x86/xen/Kconfig). So maybe it should not even appear in the one of the fragment configs? Regards, -- Julien Grall -- 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: [Xen-devel] [PATCH v3 2/2] x86, arm64, platform, xen, kconfig: add xen defconfig helper
On Tue, Dec 9, 2014 at 12:22 PM, Luis R. Rodriguez wrote: > If you are sure then yes. Likewise here. Luis -- 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: [Xen-devel] [PATCH v3 2/2] x86, arm64, platform, xen, kconfig: add xen defconfig helper
On Tue, Dec 9, 2014 at 1:06 AM, Julien Grall wrote: > Hello Luis, > > On 08/12/2014 23:05, Luis R. Rodriguez wrote: >> >> diff --git a/kernel/configs/xen.config b/kernel/configs/xen.config >> new file mode 100644 >> index 000..0d0eb6d >> --- /dev/null >> +++ b/kernel/configs/xen.config >> +CONFIG_XEN_MCE_LOG=y > > > MCE is x86 specific. That's what I thought too but its available for arm64, so should we fix that Kconfig to depend on x86? >> +CONFIG_XEN_HAVE_PVMMU=y > > > We don't have PVMMU support on ARM. Shouldn't you move this config in > architecture specific code? If you are sure then yes. Luis -- 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 v14 3/7] KVM: x86: switch to kvm_get_dirty_log_protect
On 09/12/2014 00:12, Mario Smarduch wrote:
> Hi Paolo,
>I took a closer look at Christoffers comment,
> the _log description in x86.c is a repeat of the
> _protect description in kvm_main.c.
>
> I'm wondering if description below would be acceptable, or
> perhaps you had a reason leaving it as is.
Yes, it's okay.
> For the ARM variant I would word same. Please advise.
>
> Thanks.
>
> "
> /**
> * kvm_vm_ioctl_get_dirty_log - get and clear the log of dirty pages in
> a slot
> * @kvm: kvm instance
> * @log: slot id and address to which we copy the log
> *
> * Steps 1-4 below provide general overview of dirty page logging. See
> * kvm_get_dirty_log_protect() function description for additional details.
> *
> * We call kvm_get_dirty_log_protect() to handle steps 1-3, upon return we
> * always flush the TLB (step 4) even if 'protect' failed and dirty bitmap
even if a previous step failed and the dirty bitmap may be corrupt.
> * may be corrupt. Regardless of previous outcome KVM logging API does not
... the KVM logging API ...
> * preclude user space subsequent dirty log read. Flushing TLB insures
s/insures/ensures/
Paolo
> writes
> * will be marked dirty for next log read.
> *
> * 1. Take a snapshot of the bit and clear it if needed.
> * 2. Write protect the corresponding page.
> * 3. Copy the snapshot to the userspace.
> * 4. Flush TLB's if needed.
> */
> "
>
> On 11/22/2014 11:19 AM, Christoffer Dall wrote:
>> On Thu, Nov 13, 2014 at 05:57:44PM -0800, Mario Smarduch wrote:
>>> From: Paolo Bonzini
>>>
>>> We now have a generic function that does most of the work of
>>> kvm_vm_ioctl_get_dirty_log, now use it.
>>>
>>> Signed-off-by: Mario Smarduch
>>> ---
>>> arch/x86/include/asm/kvm_host.h |3 --
>>> arch/x86/kvm/Kconfig|1 +
>>> arch/x86/kvm/mmu.c |4 +--
>>> arch/x86/kvm/x86.c | 64
>>> ++-
>>> 4 files changed, 12 insertions(+), 60 deletions(-)
>>>
>>> diff --git a/arch/x86/include/asm/kvm_host.h
>>> b/arch/x86/include/asm/kvm_host.h
>>> index 7c492ed..934dc24 100644
>>> --- a/arch/x86/include/asm/kvm_host.h
>>> +++ b/arch/x86/include/asm/kvm_host.h
>>> @@ -805,9 +805,6 @@ void kvm_mmu_set_mask_ptes(u64 user_mask, u64
>>> accessed_mask,
>>>
>>> void kvm_mmu_reset_context(struct kvm_vcpu *vcpu);
>>> void kvm_mmu_slot_remove_write_access(struct kvm *kvm, int slot);
>>> -void kvm_mmu_write_protect_pt_masked(struct kvm *kvm,
>>> -struct kvm_memory_slot *slot,
>>> -gfn_t gfn_offset, unsigned long mask);
>>> void kvm_mmu_zap_all(struct kvm *kvm);
>>> void kvm_mmu_invalidate_mmio_sptes(struct kvm *kvm);
>>> unsigned int kvm_mmu_calculate_mmu_pages(struct kvm *kvm);
>>> diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig
>>> index f9d16ff..d073594 100644
>>> --- a/arch/x86/kvm/Kconfig
>>> +++ b/arch/x86/kvm/Kconfig
>>> @@ -39,6 +39,7 @@ config KVM
>>> select PERF_EVENTS
>>> select HAVE_KVM_MSI
>>> select HAVE_KVM_CPU_RELAX_INTERCEPT
>>> + select KVM_GENERIC_DIRTYLOG_READ_PROTECT
>>> select KVM_VFIO
>>> ---help---
>>> Support hosting fully virtualized guest machines using hardware
>>> diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
>>> index 9314678..bf6b82c 100644
>>> --- a/arch/x86/kvm/mmu.c
>>> +++ b/arch/x86/kvm/mmu.c
>>> @@ -1224,7 +1224,7 @@ static bool __rmap_write_protect(struct kvm *kvm,
>>> unsigned long *rmapp,
>>> }
>>>
>>> /**
>>> - * kvm_mmu_write_protect_pt_masked - write protect selected PT level pages
>>> + * kvm_arch_mmu_write_protect_pt_masked - write protect selected PT level
>>> pages
>>> * @kvm: kvm instance
>>> * @slot: slot to protect
>>> * @gfn_offset: start of the BITS_PER_LONG pages we care about
>>> @@ -1233,7 +1233,7 @@ static bool __rmap_write_protect(struct kvm *kvm,
>>> unsigned long *rmapp,
>>> * Used when we do not need to care about huge page mappings: e.g. during
>>> dirty
>>> * logging we do not have any such mappings.
>>> */
>>> -void kvm_mmu_write_protect_pt_masked(struct kvm *kvm,
>>> +void kvm_arch_mmu_write_protect_pt_masked(struct kvm *kvm,
>>> struct kvm_memory_slot *slot,
>>> gfn_t gfn_offset, unsigned long mask)
>>> {
>>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>>> index 8f1e22d..9f8ae9a 100644
>>> --- a/arch/x86/kvm/x86.c
>>> +++ b/arch/x86/kvm/x86.c
>>> @@ -3606,77 +3606,31 @@ static int kvm_vm_ioctl_reinject(struct kvm *kvm,
>>> *
>>> * 1. Take a snapshot of the bit and clear it if needed.
>>> * 2. Write protect the corresponding page.
>>> - * 3. Flush TLB's if needed.
>>> - * 4. Copy the snapshot to the userspace.
>>> + * 3. Copy the snapshot to the userspace.
>>> + * 4. Flush TLB's if needed.
>>> *
>>> - * Between 2 and 3, the guest may write to the page using the remaining TLB
>>> - * entry. This is not a
Re: [GIT PULL 0/9] KVM/ARM Changes for v3.19
On 09/12/2014 12:25, Christoffer Dall wrote: > Hi Paolo, > > The following changes since commit f62c95fd4041d669159dd76ac0bb2a7f86b5b05d: > > Merge tag 'kvm-s390-next-20141028' of > git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux into HEAD > (2014-10-29 13:31:32 +0100) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git > kvm-arm-for-3.19 > > for you to fetch changes up to 016ed39c54b8a3db680e5c6a43419f806133caf2: > > arm/arm64: KVM: vgic: kick the specific vcpu instead of iterating through > all (2014-11-26 10:19:37 +) > > Thanks, > -Christoffer > > > Changes for KVM for arm/arm64 for v3.19 including mmio mapping fixups > (already in kvm/next, apologies about duplicate commits), vgic cleanup > and optimizations, and an MMIO path cleanup. > > > > > Andre Przywara (1): > arm/arm64: KVM: avoid unnecessary guest register mangling on MMIO read > > Ard Biesheuvel (4): > arm/arm64: kvm: drop inappropriate use of kvm_is_mmio_pfn() > kvm: fix kvm_is_mmio_pfn() and rename to kvm_is_reserved_pfn() > kvm: add a memslot flag for incoherent memory regions > arm, arm64: KVM: handle potential incoherency of readonly memslots > > Christoffer Dall (1): > arm/arm64: vgic: Remove unreachable irq_clear_pending > > Laszlo Ersek (1): > arm, arm64: KVM: allow forced dcache flush on page faults > > Shannon Zhao (1): > arm/arm64: KVM: vgic: kick the specific vcpu instead of iterating > through all > > wanghaibin (1): > KVM: ARM: VGIC: Optimize the vGIC vgic_update_irq_pending function. > > arch/arm/include/asm/kvm_mmu.h | 5 +++-- > arch/arm/kvm/mmio.c | 15 +-- > arch/arm/kvm/mmu.c | 34 +++--- > arch/arm64/include/asm/kvm_mmu.h | 5 +++-- > arch/ia64/kvm/kvm-ia64.c | 2 +- > arch/x86/kvm/mmu.c | 6 +++--- > include/linux/kvm_host.h | 3 ++- > virt/kvm/arm/vgic.c | 20 +--- > virt/kvm/kvm_main.c | 16 > 9 files changed, 69 insertions(+), 37 deletions(-) > No dirty bitmap yet? You still have one week, I'm okay with a late addition. 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: [PATCH v3 1/2] x86, platform, kconfig: clarify kvmconfig is for kvm
On Mon, Dec 08, 2014 at 03:04:59PM -0800, Luis R. Rodriguez wrote: > From: "Luis R. Rodriguez" > > We'll be adding options for xen as well. > > Cc: Josh Triplett > Cc: Borislav Petkov > Cc: Pekka Enberg > Cc: David Rientjes > Cc: Michal Marek > Cc: Randy Dunlap > Cc: penb...@kernel.org > Cc: levinsasha...@gmail.com > Cc: mtosa...@redhat.com > Cc: fengguang...@intel.com > Cc: David Vrabel > Cc: Ian Campbell > Cc: Konrad Rzeszutek Wilk > Cc: xen-de...@lists.xenproject.org > Acked-by: David Rientjes > Signed-off-by: Luis R. Rodriguez > --- > scripts/kconfig/Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile > index 9645c07..ff612b0 100644 > --- a/scripts/kconfig/Makefile > +++ b/scripts/kconfig/Makefile > @@ -141,7 +141,7 @@ help: > @echo ' randconfig - New config with random answer to all > options' > @echo ' listnewconfig - List new options' > @echo ' olddefconfig- Same as silentoldconfig but sets new > symbols to their default value' > - @echo ' kvmconfig - Enable additional options for guest kernel > support' > + @echo ' kvmconfig - Enable additional options for kvm guest > kernel support' > @echo ' tinyconfig - Configure the tiniest possible kernel' > > # lxdialog stuff Acked-by: Borislav Petkov -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- 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 v5 14/19] s390x/virtio-ccw: enable virtio 1.0
On Tue, 9 Dec 2014 15:46:46 +0200
"Michael S. Tsirkin" wrote:
> On Tue, Dec 02, 2014 at 02:00:22PM +0100, Cornelia Huck wrote:
> > virtio-ccw should now have everything in place to operate virtio 1.0
> > devices, so let's enable revision 1.
> >
> > Signed-off-by: Cornelia Huck
>
> Looks like this will allow revision 1 for all devices,
> we only want this for virtio 1 devices.
>
> The following should fix it I think:
>
> Signed-off-by: Michael S. Tsirkin
>
>
> @@ -104,6 +101,12 @@ struct VirtioCcwDevice {
> uint64_t ind_bit;
> };
>
> +/* The maximum virtio revision we support. */
> +static int virtio_ccw_rev_max(VirtioCcwDevice *dev)
Make this "static inline int" and I'm fine with this :)
> +{
> +return dev->host_features & (1ULL << VIRTIO_F_VERSION_1) ? 1 : 0;
> +}
> +
> /* virtual css bus type */
> typedef struct VirtualCssBus {
> BusState parent_obj;
--
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 v3 7/8] KVM: kvm-vfio: generic forwarding control
On 11/24/2014 09:56 PM, Alex Williamson wrote:
> On Sun, 2014-11-23 at 19:35 +0100, Eric Auger wrote:
>> This patch introduces a new KVM_DEV_VFIO_DEVICE group.
>>
>> This is a new control channel which enables KVM to cooperate with
>> viable VFIO devices.
>>
>> Functions are introduced to check the validity of a VFIO device
>> file descriptor, increment/decrement the ref counter of the VFIO
>> device.
>>
>> The patch introduces 2 attributes for this new device group:
>> KVM_DEV_VFIO_DEVICE_FORWARD_IRQ, KVM_DEV_VFIO_DEVICE_UNFORWARD_IRQ.
>> Their purpose is to turn a VFIO device IRQ into a forwarded IRQ and
>> unset respectively unset the feature.
>>
>> The VFIO device stores a list of registered forwarded IRQs. The reference
>> counter of the device is incremented each time a new IRQ is forwarded.
>> Reference counter is decremented when the IRQ forwarding is unset.
>>
>> The forwarding programmming is architecture specific, implemented in
>> kvm_arch_set_fwd_state function. Architecture specific implementation is
>> enabled when __KVM_HAVE_ARCH_KVM_VFIO_FORWARD is set. When not set those
>> functions are void.
>>
>> Signed-off-by: Eric Auger
>>
>> ---
>>
>> v2 -> v3:
>> - add API comments in kvm_host.h
>> - improve the commit message
>> - create a private kvm_vfio_fwd_irq struct
>> - fwd_irq_action replaced by a bool and removal of VFIO_IRQ_CLEANUP. This
>> latter action will be handled in vgic.
>> - add a vfio_device handle argument to kvm_arch_set_fwd_state. The goal is
>> to move platform specific stuff in architecture specific code.
>> - kvm_arch_set_fwd_state renamed into kvm_arch_vfio_set_forward
>> - increment the ref counter each time we do an IRQ forwarding and decrement
>> this latter each time one IRQ forward is unset. Simplifies the whole
>> ref counting.
>> - simplification of list handling: create, search, removal
>>
>> v1 -> v2:
>> - __KVM_HAVE_ARCH_KVM_VFIO renamed into __KVM_HAVE_ARCH_KVM_VFIO_FORWARD
>> - original patch file separated into 2 parts: generic part moved in vfio.c
>> and ARM specific part(kvm_arch_set_fwd_state)
>> ---
>> include/linux/kvm_host.h | 28 ++
>> virt/kvm/vfio.c | 249
>> ++-
>> 2 files changed, 274 insertions(+), 3 deletions(-)
>>
>> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
>> index ea53b04..0b9659d 100644
>> --- a/include/linux/kvm_host.h
>> +++ b/include/linux/kvm_host.h
>> @@ -1076,6 +1076,15 @@ struct kvm_device_ops {
>>unsigned long arg);
>> };
>>
>> +/* internal self-contained structure describing a forwarded IRQ */
>> +struct kvm_fwd_irq {
>> +struct kvm *kvm; /* VM to inject the GSI into */
>> +struct vfio_device *vdev; /* vfio device the IRQ belongs to */
>> +__u32 index; /* VFIO device IRQ index */
>> +__u32 subindex; /* VFIO device IRQ subindex */
>> +__u32 gsi; /* gsi, ie. virtual IRQ number */
>> +};
>> +
>> void kvm_device_get(struct kvm_device *dev);
>> void kvm_device_put(struct kvm_device *dev);
>> struct kvm_device *kvm_device_from_filp(struct file *filp);
>> @@ -1085,6 +1094,25 @@ void kvm_unregister_device_ops(u32 type);
>> extern struct kvm_device_ops kvm_mpic_ops;
>> extern struct kvm_device_ops kvm_xics_ops;
>>
>> +#ifdef __KVM_HAVE_ARCH_KVM_VFIO_FORWARD
>> +/**
>> + * kvm_arch_vfio_set_forward - changes the forwarded state of an IRQ
>> + *
>> + * @fwd_irq: handle to the forwarded irq struct
>> + * @forward: true means forwarded, false means not forwarded
>> + * returns 0 on success, < 0 on failure
>> + */
>> +int kvm_arch_vfio_set_forward(struct kvm_fwd_irq *fwd_irq,
>> + bool forward);
>
> We could add a struct device* to the args list or into struct
> kvm_fwd_irq so that arch code doesn't need to touch the vdev. arch code
> has no business dealing with references to the vfio_device.
>
>> +
>> +#else
>> +static inline int kvm_arch_vfio_set_forward(struct kvm_fwd_irq *fwd_irq,
>> +bool forward)
>> +{
>> +return 0;
>> +}
>> +#endif
>> +
>> #ifdef CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT
>>
>> static inline void kvm_vcpu_set_in_spin_loop(struct kvm_vcpu *vcpu, bool
>> val)
>> diff --git a/virt/kvm/vfio.c b/virt/kvm/vfio.c
>> index 6f0cc34..af178bb 100644
>> --- a/virt/kvm/vfio.c
>> +++ b/virt/kvm/vfio.c
>> @@ -25,8 +25,16 @@ struct kvm_vfio_group {
>> struct vfio_group *vfio_group;
>> };
>>
>> +/* private linkable kvm_fwd_irq struct */
>> +struct kvm_vfio_fwd_irq_node {
>> +struct list_head link;
>> +struct kvm_fwd_irq fwd_irq;
>> +};
>> +
>> struct kvm_vfio {
>> struct list_head group_list;
>> +/* list of registered VFIO forwarded IRQs */
>> +struct list_head fwd_node_list;
>> struct mutex lock;
>> bool noncoherent;
>> };
>> @@ -247,12 +255,239 @@ static int kvm_vfio_set_group(struct kvm_device *dev,
>> long attr, u64 arg)
>> return -ENXIO;
>> }
>>
>> +/**
>> + * kvm_vfio_get_v
Re: [PATCH] vgic: move reset initialization into vgic_init_maps()
On Thu, Dec 04, 2014 at 03:02:24PM +, Peter Maydell wrote: > VGIC initialization currently happens in three phases: > (1) kvm_vgic_create() (triggered by userspace GIC creation) > (2) vgic_init_maps() (triggered by userspace GIC register read/write > requests, or from kvm_vgic_init() if not already run) > (3) kvm_vgic_init() (triggered by first VM run) > > We were doing initialization of some state to correspond with the > state of a freshly-reset GIC in kvm_vgic_init(); this is too late, > since it will overwrite changes made by userspace using the > register access APIs before the VM is run. Move this initialization > earlier, into the vgic_init_maps() phase. > > This fixes a bug where QEMU could successfully restore a saved > VM state snapshot into a VM that had already been run, but could > not restore it "from cold" using the -loadvm command line option > (the symptoms being that the restored VM would run but interrupts > were ignored). > > Signed-off-by: Peter Maydell > --- > You could make a good argument for renaming vgic_init_maps() and > kvm_vgic_init() (eg vgic_init() and vgic_first_run() ?)... > Yes you could. I've sent out a series today that reworks your patch and adds some other logic to go along with it. -Christoffer -- 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
[PATCH 1/5] arm/arm64: KVM: vgic: move reset initialization into vgic_init_maps()
From: Peter Maydell
VGIC initialization currently happens in three phases:
(1) kvm_vgic_create() (triggered by userspace GIC creation)
(2) vgic_init_maps() (triggered by userspace GIC register read/write
requests, or from kvm_vgic_init() if not already run)
(3) kvm_vgic_init() (triggered by first VM run)
We were doing initialization of some state to correspond with the
state of a freshly-reset GIC in kvm_vgic_init(); this is too late,
since it will overwrite changes made by userspace using the
register access APIs before the VM is run. Move this initialization
earlier, into the vgic_init_maps() phase.
This fixes a bug where QEMU could successfully restore a saved
VM state snapshot into a VM that had already been run, but could
not restore it "from cold" using the -loadvm command line option
(the symptoms being that the restored VM would run but interrupts
were ignored).
Finally rename vgic_init_maps to vgic_init and renamed kvm_vgic_init to
kvm_vgic_map_resources.
[ This patch is originally written by Peter Maydell, but I have
modified it somewhat heavily, renaming various bits and moving code
around. If something is broken, I am to be blamed. - Christoffer ]
Signed-off-by: Peter Maydell
Signed-off-by: Christoffer Dall
---
This patch was originally named "vgic: move reset initialization into
vgic_init_maps()" but I renamed it slightly to match the other vgic
patches in the kernel. I also did the additional changes since the
original patch:
- Renamed kvm_vgic_init to kvm_vgic_map_resources
- Renamed vgic_init_maps to vgic_init
- Moved vgic_enable call into existing vcpu loop in vgic_init
- Moved ITARGETSRn initializtion above vcpu loop in vgic_init (the idea
is to init global state first, then vcpu state).
- Added comment in kvm_vgic_map_resources
arch/arm/kvm/arm.c | 6 ++--
include/kvm/arm_vgic.h | 4 +--
virt/kvm/arm/vgic.c| 77 +-
3 files changed, 37 insertions(+), 50 deletions(-)
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 9e193c8..a56cbb5 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -427,11 +427,11 @@ static int kvm_vcpu_first_run_init(struct kvm_vcpu *vcpu)
vcpu->arch.has_run_once = true;
/*
-* Initialize the VGIC before running a vcpu the first time on
-* this VM.
+* Map the VGIC hardware resources before running a vcpu the first
+* time on this VM.
*/
if (unlikely(!vgic_initialized(vcpu->kvm))) {
- ret = kvm_vgic_init(vcpu->kvm);
+ ret = kvm_vgic_map_resources(vcpu->kvm);
if (ret)
return ret;
}
diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
index 206dcc3..fe9783b 100644
--- a/include/kvm/arm_vgic.h
+++ b/include/kvm/arm_vgic.h
@@ -274,7 +274,7 @@ struct kvm_exit_mmio;
#ifdef CONFIG_KVM_ARM_VGIC
int kvm_vgic_addr(struct kvm *kvm, unsigned long type, u64 *addr, bool write);
int kvm_vgic_hyp_init(void);
-int kvm_vgic_init(struct kvm *kvm);
+int kvm_vgic_map_resources(struct kvm *kvm);
int kvm_vgic_create(struct kvm *kvm);
void kvm_vgic_destroy(struct kvm *kvm);
void kvm_vgic_vcpu_destroy(struct kvm_vcpu *vcpu);
@@ -321,7 +321,7 @@ static inline int kvm_vgic_addr(struct kvm *kvm, unsigned
long type, u64 *addr,
return -ENXIO;
}
-static inline int kvm_vgic_init(struct kvm *kvm)
+static inline int kvm_vgic_map_resources(struct kvm *kvm)
{
return 0;
}
diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
index aacdb59..91e6bfc 100644
--- a/virt/kvm/arm/vgic.c
+++ b/virt/kvm/arm/vgic.c
@@ -91,6 +91,7 @@
#define ACCESS_WRITE_VALUE (3 << 1)
#define ACCESS_WRITE_MASK(x) ((x) & (3 << 1))
+static int vgic_init(struct kvm *kvm);
static void vgic_retire_disabled_irqs(struct kvm_vcpu *vcpu);
static void vgic_retire_lr(int lr_nr, int irq, struct kvm_vcpu *vcpu);
static void vgic_update_state(struct kvm *kvm);
@@ -1726,39 +1727,14 @@ static int vgic_vcpu_init_maps(struct kvm_vcpu *vcpu,
int nr_irqs)
int sz = (nr_irqs - VGIC_NR_PRIVATE_IRQS) / 8;
vgic_cpu->pending_shared = kzalloc(sz, GFP_KERNEL);
- vgic_cpu->vgic_irq_lr_map = kzalloc(nr_irqs, GFP_KERNEL);
+ vgic_cpu->vgic_irq_lr_map = kmalloc(nr_irqs, GFP_KERNEL);
if (!vgic_cpu->pending_shared || !vgic_cpu->vgic_irq_lr_map) {
kvm_vgic_vcpu_destroy(vcpu);
return -ENOMEM;
}
- return 0;
-}
-
-/**
- * kvm_vgic_vcpu_init - Initialize per-vcpu VGIC state
- * @vcpu: pointer to the vcpu struct
- *
- * Initialize the vgic_cpu struct and vgic_dist struct fields pertaining to
- * this vcpu and enable the VGIC for this VCPU
- */
-static void kvm_vgic_vcpu_init(struct kvm_vcpu *vcpu)
-{
- struct vgic_cpu *vgic_cpu = &vcpu->arch.vgic_cpu;
- struct vgic_dist *dist = &vcpu->kvm->arch.vgic;
- int i;
-
- for (i = 0; i < dist->nr_irqs; i++) {
-
[PATCH 4/5] arm/arm64: KVM: Don't allow creating VCPUs after vgic_initialized
When the vgic initializes its internal state it does so based on the
number of VCPUs available at the time. If we allow KVM to create more
VCPUs after the VGIC has been initialized, we are likely to error out in
unfortunate ways later, perform buffer overflows etc.
Cc: Eric Auger
Signed-off-by: Christoffer Dall
---
This replaces Eric Auger's previous patch
(https://lists.cs.columbia.edu/pipermail/kvmarm/2014-December/012646.html),
because it fits better with testing to include it in this series and I
realized that we need to add a check against irqchip_in_kernel() as
well.
arch/arm/kvm/arm.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index a9d005f..d4da244 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -213,6 +213,11 @@ struct kvm_vcpu *kvm_arch_vcpu_create(struct kvm *kvm,
unsigned int id)
int err;
struct kvm_vcpu *vcpu;
+ if (irqchip_in_kernel(kvm) && vgic_initialized(kvm)) {
+ err = -EBUSY;
+ goto out;
+ }
+
vcpu = kmem_cache_zalloc(kvm_vcpu_cache, GFP_KERNEL);
if (!vcpu) {
err = -ENOMEM;
--
2.1.2.330.g565301e.dirty
--
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
[PATCH 3/5] arm/arm64: KVM: Add (new) vgic_initialized macro
Some code paths will need to check to see if the internal state of the
vgic has been initialized (such as when creating new VCPUs), so
introduce such a macro that checks the nr_cpus field which is set when
the vgic has been initialized.
Also set nr_cpus = 0 in kvm_vgic_destroy, because the error path in
vgic_init() will call this function, and code should never errornously
assume the vgic to be properly initialized after an error.
Signed-off-by: Christoffer Dall
---
include/kvm/arm_vgic.h | 6 ++
virt/kvm/arm/vgic.c| 1 +
2 files changed, 7 insertions(+)
diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
index 3e262b9..ac4888d 100644
--- a/include/kvm/arm_vgic.h
+++ b/include/kvm/arm_vgic.h
@@ -287,6 +287,7 @@ bool vgic_handle_mmio(struct kvm_vcpu *vcpu, struct kvm_run
*run,
struct kvm_exit_mmio *mmio);
#define irqchip_in_kernel(k) (!!((k)->arch.vgic.in_kernel))
+#define vgic_initialized(k)(!!((k)->arch.vgic.nr_cpus))
#define vgic_ready(k) ((k)->arch.vgic.ready)
int vgic_v2_probe(struct device_node *vgic_node,
@@ -369,6 +370,11 @@ static inline int irqchip_in_kernel(struct kvm *kvm)
return 0;
}
+static inline bool vgic_initialized(struct kvm *kvm)
+{
+ return true;
+}
+
static inline bool vgic_ready(struct kvm *kvm)
{
return true;
diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
index 6293349..c98cc6b 100644
--- a/virt/kvm/arm/vgic.c
+++ b/virt/kvm/arm/vgic.c
@@ -1774,6 +1774,7 @@ void kvm_vgic_destroy(struct kvm *kvm)
dist->irq_spi_cpu = NULL;
dist->irq_spi_target = NULL;
dist->irq_pending_on_cpu = NULL;
+ dist->nr_cpus = 0;
}
/*
--
2.1.2.330.g565301e.dirty
--
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
[PATCH 0/5] Fix vgic initialization problems
This series fixes problems with initializing the VGIC. The problem is that we were initializing the state of the VGIC on-demand partially, and doing some final initializtion at the time when we were going to run a VCPU for the first time. This broke migration, because the first-vcpu-run init would overwrite restored state. We also cleanup the naming of the init functions and add checks when creating VCPUs and when injecting IRQs from userspace. This series invalidates patch 3 "KVM: arm/arm64: check vgic_initialized before VCPU creation" in Eric Auger's vgic init ioctl series. Eric's series should be applied after this one, making future ABIs (IRQFD, VFIO, GICv3, ...) require explicit userspace vgic initialization instead of this on-demand approach that we now have to maintain for legacy userspace compatiblity. I've tested this with 32-bit and 64-bit QEMU and kvmtool. Christoffer Dall (4): arm/arm64: KVM: Rename vgic_initialized to vgic_ready arm/arm64: KVM: Add (new) vgic_initialized macro arm/arm64: KVM: Don't allow creating VCPUs after vgic_initialized arm/arm64: KVM: Initialize the vgic on-demand when injecting IRQs Peter Maydell (1): arm/arm64: KVM: vgic: move reset initialization into vgic_init_maps() arch/arm/kvm/arm.c | 13 +--- include/kvm/arm_vgic.h | 12 +-- virt/kvm/arm/vgic.c| 91 +++--- 3 files changed, 60 insertions(+), 56 deletions(-) -- 2.1.2.330.g565301e.dirty -- 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
[PATCH 2/5] arm/arm64: KVM: Rename vgic_initialized to vgic_ready
The vgic_initialized() macro currently returns the state of the
vgic->ready flag, which indicates if the vgic is ready to be used when
running a VM, not specifically if its internal state has been
initialized.
Rename the macro accordingly in preparation for a more nuanced
initialization flow.
Signed-off-by: Christoffer Dall
---
arch/arm/kvm/arm.c | 2 +-
include/kvm/arm_vgic.h | 4 ++--
virt/kvm/arm/vgic.c| 6 +++---
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index a56cbb5..a9d005f 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -430,7 +430,7 @@ static int kvm_vcpu_first_run_init(struct kvm_vcpu *vcpu)
* Map the VGIC hardware resources before running a vcpu the first
* time on this VM.
*/
- if (unlikely(!vgic_initialized(vcpu->kvm))) {
+ if (unlikely(!vgic_ready(vcpu->kvm))) {
ret = kvm_vgic_map_resources(vcpu->kvm);
if (ret)
return ret;
diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
index fe9783b..3e262b9 100644
--- a/include/kvm/arm_vgic.h
+++ b/include/kvm/arm_vgic.h
@@ -287,7 +287,7 @@ bool vgic_handle_mmio(struct kvm_vcpu *vcpu, struct kvm_run
*run,
struct kvm_exit_mmio *mmio);
#define irqchip_in_kernel(k) (!!((k)->arch.vgic.in_kernel))
-#define vgic_initialized(k)((k)->arch.vgic.ready)
+#define vgic_ready(k) ((k)->arch.vgic.ready)
int vgic_v2_probe(struct device_node *vgic_node,
const struct vgic_ops **ops,
@@ -369,7 +369,7 @@ static inline int irqchip_in_kernel(struct kvm *kvm)
return 0;
}
-static inline bool vgic_initialized(struct kvm *kvm)
+static inline bool vgic_ready(struct kvm *kvm)
{
return true;
}
diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
index 91e6bfc..6293349 100644
--- a/virt/kvm/arm/vgic.c
+++ b/virt/kvm/arm/vgic.c
@@ -1693,7 +1693,7 @@ out:
int kvm_vgic_inject_irq(struct kvm *kvm, int cpuid, unsigned int irq_num,
bool level)
{
- if (likely(vgic_initialized(kvm)) &&
+ if (likely(vgic_ready(kvm)) &&
vgic_update_irq_pending(kvm, cpuid, irq_num, level))
vgic_kick_vcpus(kvm);
@@ -1882,7 +1882,7 @@ int kvm_vgic_map_resources(struct kvm *kvm)
mutex_lock(&kvm->lock);
- if (vgic_initialized(kvm))
+ if (vgic_ready(kvm))
goto out;
if (IS_VGIC_ADDR_UNDEF(kvm->arch.vgic.vgic_dist_base) ||
@@ -2276,7 +2276,7 @@ static int vgic_set_attr(struct kvm_device *dev, struct
kvm_device_attr *attr)
mutex_lock(&dev->kvm->lock);
- if (vgic_initialized(dev->kvm) || dev->kvm->arch.vgic.nr_irqs)
+ if (vgic_ready(dev->kvm) || dev->kvm->arch.vgic.nr_irqs)
ret = -EBUSY;
else
dev->kvm->arch.vgic.nr_irqs = val;
--
2.1.2.330.g565301e.dirty
--
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
[PATCH 5/5] arm/arm64: KVM: Initialize the vgic on-demand when injecting IRQs
Userspace assumes that it can wire up IRQ injections after having
created all VCPUs and after having created the VGIC, but potentially
before starting the first VCPU. This can currently lead to lost IRQs
because the state of that IRQ injection is not stored anywhere and we
don't return an error to userspace.
We haven't seen this problem manifest itself yet, presumably because
guests reset the devices on boot, but this could cause issues with
migration and other non-standard startup configurations.
Signed-off-by: Christoffer Dall
---
virt/kvm/arm/vgic.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
index c98cc6b..feef015 100644
--- a/virt/kvm/arm/vgic.c
+++ b/virt/kvm/arm/vgic.c
@@ -1693,8 +1693,13 @@ out:
int kvm_vgic_inject_irq(struct kvm *kvm, int cpuid, unsigned int irq_num,
bool level)
{
- if (likely(vgic_ready(kvm)) &&
- vgic_update_irq_pending(kvm, cpuid, irq_num, level))
+ if (unlikely(!vgic_initialized(kvm))) {
+ mutex_lock(&kvm->lock);
+ vgic_init(kvm);
+ mutex_unlock(&kvm->lock);
+ }
+
+ if (vgic_update_irq_pending(kvm, cpuid, irq_num, level))
vgic_kick_vcpus(kvm);
return 0;
--
2.1.2.330.g565301e.dirty
--
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
[PATCH v10 04/20] vfio: amba: VFIO support for AMBA devices
Add support for discovering AMBA devices with VFIO and handle them
similarly to Linux platform devices.
Signed-off-by: Antonios Motakis
---
drivers/vfio/platform/vfio_amba.c | 115 ++
include/uapi/linux/vfio.h | 1 +
2 files changed, 116 insertions(+)
create mode 100644 drivers/vfio/platform/vfio_amba.c
diff --git a/drivers/vfio/platform/vfio_amba.c
b/drivers/vfio/platform/vfio_amba.c
new file mode 100644
index 000..ff0331f
--- /dev/null
+++ b/drivers/vfio/platform/vfio_amba.c
@@ -0,0 +1,115 @@
+/*
+ * Copyright (C) 2013 - Virtual Open Systems
+ * Author: Antonios Motakis
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2, as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+
+#include "vfio_platform_private.h"
+
+#define DRIVER_VERSION "0.10"
+#define DRIVER_AUTHOR "Antonios Motakis "
+#define DRIVER_DESC "VFIO for AMBA devices - User Level meta-driver"
+
+/* probing devices from the AMBA bus */
+
+static struct resource *get_amba_resource(struct vfio_platform_device *vdev,
+ int i)
+{
+ struct amba_device *adev = (struct amba_device *) vdev->opaque;
+
+ if (i == 0)
+ return &adev->res;
+
+ return NULL;
+}
+
+static int get_amba_irq(struct vfio_platform_device *vdev, int i)
+{
+ struct amba_device *adev = (struct amba_device *) vdev->opaque;
+ int ret = 0;
+
+ if (i < AMBA_NR_IRQS)
+ ret = adev->irq[i];
+
+ /* zero is an unset IRQ for AMBA devices */
+ return ret ? ret : -ENXIO;
+}
+
+static int vfio_amba_probe(struct amba_device *adev, const struct amba_id *id)
+{
+ struct vfio_platform_device *vdev;
+ int ret;
+
+ vdev = kzalloc(sizeof(*vdev), GFP_KERNEL);
+ if (!vdev)
+ return -ENOMEM;
+
+ vdev->name = kasprintf(GFP_KERNEL, "vfio-amba-%08x", adev->periphid);
+ if (!vdev->name) {
+ kfree(vdev);
+ return -ENOMEM;
+ }
+
+ vdev->opaque = (void *) adev;
+ vdev->flags = VFIO_DEVICE_FLAGS_AMBA;
+ vdev->get_resource = get_amba_resource;
+ vdev->get_irq = get_amba_irq;
+
+ ret = vfio_platform_probe_common(vdev, &adev->dev);
+ if (ret) {
+ kfree(vdev->name);
+ kfree(vdev);
+ }
+
+ return ret;
+}
+
+static int vfio_amba_remove(struct amba_device *adev)
+{
+ struct vfio_platform_device *vdev;
+
+ vdev = vfio_platform_remove_common(&adev->dev);
+ if (vdev) {
+ kfree(vdev->name);
+ kfree(vdev);
+ return 0;
+ }
+
+ return -EINVAL;
+}
+
+static struct amba_id pl330_ids[] = {
+ { 0, 0 },
+};
+
+MODULE_DEVICE_TABLE(amba, pl330_ids);
+
+static struct amba_driver vfio_amba_driver = {
+ .probe = vfio_amba_probe,
+ .remove = vfio_amba_remove,
+ .id_table = pl330_ids,
+ .drv = {
+ .name = "vfio-amba",
+ .owner = THIS_MODULE,
+ },
+};
+
+module_amba_driver(vfio_amba_driver);
+
+MODULE_VERSION(DRIVER_VERSION);
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR(DRIVER_AUTHOR);
+MODULE_DESCRIPTION(DRIVER_DESC);
diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
index 4e93a97..544d3d8 100644
--- a/include/uapi/linux/vfio.h
+++ b/include/uapi/linux/vfio.h
@@ -160,6 +160,7 @@ struct vfio_device_info {
#define VFIO_DEVICE_FLAGS_RESET(1 << 0)/* Device supports
reset */
#define VFIO_DEVICE_FLAGS_PCI (1 << 1)/* vfio-pci device */
#define VFIO_DEVICE_FLAGS_PLATFORM (1 << 2)/* vfio-platform device */
+#define VFIO_DEVICE_FLAGS_AMBA (1 << 3) /* vfio-amba device */
__u32 num_regions;/* Max region index + 1 */
__u32 num_irqs; /* Max IRQ index + 1 */
};
--
2.1.3
--
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] KVM: x86: nVMX: support for MSR loading/storing
Eugene Korenevsky writes:
> Several hypervisors use MSR loading/storing to run guests.
> This patch implements emulation of this feature and allows these
> hypervisors to work in L1.
>
> The following is emulated:
> - Loading MSRs on VM-entries
> - Saving MSRs on VM-exits
> - Loading MSRs on VM-exits
>
> Actions taken on loading MSRs:
> - MSR load area is verified
> - For each MSR entry from load area:
> - MSR load entry is read and verified
> - MSR value is safely written
> Actions taken on storing MSRs:
> - MSR store area is verified
> - For each MSR entry from store area:
> - MSR entry is read and verified
> - MSR value is safely read using MSR index from MSR entry
> - MSR value is written to MSR entry
>
> The code performs checks required by Intel Software Developer Manual.
>
Thank you for the commit message.
> This patch is partially based on Wincy Wan's work.
Typo in name -> ^
I have added Jan and Wincy to the CC list since they reviewed your earlier
proposal.
I think it would be better to split this up as I mentioned earlier, however,
if the other reviewers and the maintainer don't have objections, I am ok :)
>
> Signed-off-by: Eugene Korenevsky
> ---
> arch/x86/include/asm/vmx.h| 6 +
> arch/x86/include/uapi/asm/msr-index.h | 3 +
> arch/x86/include/uapi/asm/vmx.h | 2 +
> arch/x86/kvm/vmx.c| 210
> --
> virt/kvm/kvm_main.c | 1 +
> 5 files changed, 215 insertions(+), 7 deletions(-)
>
> diff --git a/arch/x86/include/asm/vmx.h b/arch/x86/include/asm/vmx.h
> index 45afaee..8bdb247 100644
> --- a/arch/x86/include/asm/vmx.h
> +++ b/arch/x86/include/asm/vmx.h
> @@ -457,6 +457,12 @@ struct vmx_msr_entry {
> #define ENTRY_FAIL_VMCS_LINK_PTR 4
>
> /*
> + * VMX Abort codes
> + */
> +#define VMX_ABORT_MSR_STORE_FAILURE 1
> +#define VMX_ABORT_MSR_LOAD_FAILURE 4
> +
> +/*
> * VM-instruction error numbers
> */
> enum vm_instruction_error_number {
> diff --git a/arch/x86/include/uapi/asm/msr-index.h
> b/arch/x86/include/uapi/asm/msr-index.h
> index e21331c..3c9c601 100644
> --- a/arch/x86/include/uapi/asm/msr-index.h
> +++ b/arch/x86/include/uapi/asm/msr-index.h
> @@ -316,6 +316,9 @@
> #define MSR_IA32_UCODE_WRITE 0x0079
> #define MSR_IA32_UCODE_REV 0x008b
>
> +#define MSR_IA32_SMM_MONITOR_CTL 0x009b
> +#define MSR_IA32_SMBASE 0x009e
> +
> #define MSR_IA32_PERF_STATUS 0x0198
> #define MSR_IA32_PERF_CTL0x0199
> #define MSR_AMD_PSTATE_DEF_BASE 0xc0010064
> diff --git a/arch/x86/include/uapi/asm/vmx.h b/arch/x86/include/uapi/asm/vmx.h
> index b813bf9..52ad8e2 100644
> --- a/arch/x86/include/uapi/asm/vmx.h
> +++ b/arch/x86/include/uapi/asm/vmx.h
> @@ -56,6 +56,7 @@
> #define EXIT_REASON_MSR_READ31
> #define EXIT_REASON_MSR_WRITE 32
> #define EXIT_REASON_INVALID_STATE 33
> +#define EXIT_REASON_MSR_LOAD_FAILURE34
> #define EXIT_REASON_MWAIT_INSTRUCTION 36
> #define EXIT_REASON_MONITOR_INSTRUCTION 39
> #define EXIT_REASON_PAUSE_INSTRUCTION 40
> @@ -116,6 +117,7 @@
> { EXIT_REASON_APIC_WRITE,"APIC_WRITE" }, \
> { EXIT_REASON_EOI_INDUCED, "EOI_INDUCED" }, \
> { EXIT_REASON_INVALID_STATE, "INVALID_STATE" }, \
> + { EXIT_REASON_MSR_LOAD_FAILURE, "MSR_LOAD_FAILURE" }, \
> { EXIT_REASON_INVD, "INVD" }, \
> { EXIT_REASON_INVVPID, "INVVPID" }, \
> { EXIT_REASON_INVPCID, "INVPCID" }, \
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index 9bcc871..86dc7db 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -8571,6 +8571,168 @@ static void prepare_vmcs02(struct kvm_vcpu *vcpu,
> struct vmcs12 *vmcs12)
> kvm_register_write(vcpu, VCPU_REGS_RIP, vmcs12->guest_rip);
> }
>
> +static bool vmx_msr_switch_area_verify(struct kvm_vcpu *vcpu,
> +unsigned long count_field,
> +unsigned long addr_field,
> +int maxphyaddr)
> +{
> + u64 count, addr;
> +
> + BUG_ON(vmcs12_read_any(vcpu, count_field, &count));
> + BUG_ON(vmcs12_read_any(vcpu, addr_field, &addr));
BUG_ON() is a bit harsh, please use WARN_ON and bail out.
> + if (!IS_ALIGNED(addr, 16))
> + goto fail;
> + if (addr >> maxphyaddr)
> + goto fail;
> + if ((addr + count * sizeof(struct vmx_msr_entry) - 1) >> maxphyaddr)
> + goto fail;
> + return true;
> +fail:
> + pr_warn_ratelimited(
> + "nVMX: invalid MSR switch (0x%lx, 0x%lx, %d, %llu, 0x%08llx)",
> + count_field, addr_field, maxphyaddr, count, addr);
> + return false;
> +}
> +
> +static bool nested_vmx_msr_switch_verify(struct kvm_vcpu *vcpu,
> +
Re: [PATCH RFC v5 14/19] s390x/virtio-ccw: enable virtio 1.0
On Tue, Dec 02, 2014 at 02:00:22PM +0100, Cornelia Huck wrote:
> virtio-ccw should now have everything in place to operate virtio 1.0
> devices, so let's enable revision 1.
>
> Signed-off-by: Cornelia Huck
Looks like this will allow revision 1 for all devices,
we only want this for virtio 1 devices.
The following should fix it I think:
Signed-off-by: Michael S. Tsirkin
diff --git a/hw/s390x/virtio-ccw.h b/hw/s390x/virtio-ccw.h
index d40e3be..f5a1d3e 100644
--- a/hw/s390x/virtio-ccw.h
+++ b/hw/s390x/virtio-ccw.h
@@ -69,9 +69,6 @@ typedef struct VirtIOCCWDeviceClass {
int (*exit)(VirtioCcwDevice *dev);
} VirtIOCCWDeviceClass;
-/* The maximum virtio revision we support. */
-#define VIRTIO_CCW_REV_MAX 1
-
/* Performance improves when virtqueue kick processing is decoupled from the
* vcpu thread using ioeventfd for some devices. */
#define VIRTIO_CCW_FLAG_USE_IOEVENTFD_BIT 1
@@ -104,6 +101,12 @@ struct VirtioCcwDevice {
uint64_t ind_bit;
};
+/* The maximum virtio revision we support. */
+static int virtio_ccw_rev_max(VirtioCcwDevice *dev)
+{
+return dev->host_features & (1ULL << VIRTIO_F_VERSION_1) ? 1 : 0;
+}
+
/* virtual css bus type */
typedef struct VirtualCssBus {
BusState parent_obj;
diff --git a/hw/s390x/virtio-ccw.c b/hw/s390x/virtio-ccw.c
index 3826074..922b021 100644
--- a/hw/s390x/virtio-ccw.c
+++ b/hw/s390x/virtio-ccw.c
@@ -693,7 +693,7 @@ static int virtio_ccw_cb(SubchDev *sch, CCW1 ccw)
}
cpu_physical_memory_read(ccw.cda, &revinfo, len);
if (dev->revision >= 0 ||
-revinfo.revision > VIRTIO_CCW_REV_MAX) {
+revinfo.revision > virtio_ccw_rev_max(dev)) {
ret = -ENOSYS;
break;
}
--
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 call for 2014-12-09
Hi Just a gentle reminder that Today we have a call to continue talking about multithread. Thanks, Juan. -- 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: KVM call for agenda for 2014-12-08
Alexander Spyridakis wrote: > Hello, > > Is this call still going to happen today? I haven't yet received the > contact details. Just sent it, it would be in 20 mins. Later, Juan. -- 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] KVM call for agenda for 2014-12-08
Hello, Is this call still going to happen today? I haven't yet received the contact details. Thanks and best regards. -- 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: [GIT PULL 2/9] arm/arm64: kvm: drop inappropriate use of kvm_is_mmio_pfn()
On 9 December 2014 at 13:38, Christoffer Dall wrote: > On Tue, Dec 09, 2014 at 01:29:52PM +0100, Ard Biesheuvel wrote: >> On 9 December 2014 at 12:26, Christoffer Dall >> wrote: >> > From: Ard Biesheuvel >> > >> > Instead of using kvm_is_mmio_pfn() to decide whether a host region >> > should be stage 2 mapped with device attributes, add a new static >> > function kvm_is_device_pfn() that disregards RAM pages with the >> > reserved bit set, as those should usually not be mapped as device >> > memory. >> > >> > Signed-off-by: Ard Biesheuvel >> > Signed-off-by: Marc Zyngier >> >> As I mentioned last week, this patch (and the next one) are already in >> 3.18 so unless there is some policy I am unaware of, these do not have >> to be submitted again. >> > They're in kvmarm/next, which is a stable branch (doesn't rebase) so our > only choice would be to revert this commit specifically in kvmarm/next > before sending the pull request. Since that would be more confusing > than help anything, and Paolo said to just include the duplicate commit > in the pull request, here it is. > > As we can see in linux-next, it's not really a problem. > OK, thanks for the explanation. -- Ard. -- 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: [GIT PULL 2/9] arm/arm64: kvm: drop inappropriate use of kvm_is_mmio_pfn()
On Tue, Dec 09, 2014 at 01:29:52PM +0100, Ard Biesheuvel wrote: > On 9 December 2014 at 12:26, Christoffer Dall > wrote: > > From: Ard Biesheuvel > > > > Instead of using kvm_is_mmio_pfn() to decide whether a host region > > should be stage 2 mapped with device attributes, add a new static > > function kvm_is_device_pfn() that disregards RAM pages with the > > reserved bit set, as those should usually not be mapped as device > > memory. > > > > Signed-off-by: Ard Biesheuvel > > Signed-off-by: Marc Zyngier > > As I mentioned last week, this patch (and the next one) are already in > 3.18 so unless there is some policy I am unaware of, these do not have > to be submitted again. > They're in kvmarm/next, which is a stable branch (doesn't rebase) so our only choice would be to revert this commit specifically in kvmarm/next before sending the pull request. Since that would be more confusing than help anything, and Paolo said to just include the duplicate commit in the pull request, here it is. As we can see in linux-next, it's not really a problem. -Christoffer -- 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: [GIT PULL 2/9] arm/arm64: kvm: drop inappropriate use of kvm_is_mmio_pfn()
On 9 December 2014 at 12:26, Christoffer Dall
wrote:
> From: Ard Biesheuvel
>
> Instead of using kvm_is_mmio_pfn() to decide whether a host region
> should be stage 2 mapped with device attributes, add a new static
> function kvm_is_device_pfn() that disregards RAM pages with the
> reserved bit set, as those should usually not be mapped as device
> memory.
>
> Signed-off-by: Ard Biesheuvel
> Signed-off-by: Marc Zyngier
As I mentioned last week, this patch (and the next one) are already in
3.18 so unless there is some policy I am unaware of, these do not have
to be submitted again.
--
Ard.
> ---
> arch/arm/kvm/mmu.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
> index 57a403a..b007438 100644
> --- a/arch/arm/kvm/mmu.c
> +++ b/arch/arm/kvm/mmu.c
> @@ -834,6 +834,11 @@ static bool kvm_is_write_fault(struct kvm_vcpu *vcpu)
> return kvm_vcpu_dabt_iswrite(vcpu);
> }
>
> +static bool kvm_is_device_pfn(unsigned long pfn)
> +{
> + return !pfn_valid(pfn);
> +}
> +
> static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> struct kvm_memory_slot *memslot, unsigned long hva,
> unsigned long fault_status)
> @@ -904,7 +909,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu,
> phys_addr_t fault_ipa,
> if (is_error_pfn(pfn))
> return -EFAULT;
>
> - if (kvm_is_mmio_pfn(pfn))
> + if (kvm_is_device_pfn(pfn))
> mem_type = PAGE_S2_DEVICE;
>
> spin_lock(&kvm->mmu_lock);
> --
> 2.1.2.330.g565301e.dirty
>
--
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: [v2 18/25] KVM: kvm-vfio: implement the VFIO skeleton for VT-d Posted-Interrupts
> -Original Message-
> From: Eric Auger [mailto:eric.au...@linaro.org]
> Sent: Monday, December 08, 2014 6:16 PM
> To: Alex Williamson; Wu, Feng
> Cc: t...@linutronix.de; mi...@redhat.com; h...@zytor.com; x...@kernel.org;
> g...@kernel.org; pbonz...@redhat.com; dw...@infradead.org;
> j...@8bytes.org; jiang@linux.intel.com; linux-ker...@vger.kernel.org;
> io...@lists.linux-foundation.org; kvm@vger.kernel.org
> Subject: Re: [v2 18/25] KVM: kvm-vfio: implement the VFIO skeleton for VT-d
> Posted-Interrupts
>
> On 12/08/2014 06:12 AM, Alex Williamson wrote:
> > On Mon, 2014-12-08 at 04:58 +, Wu, Feng wrote:
> >>
> >>> -Original Message-
> >>> From: Eric Auger [mailto:eric.au...@linaro.org]
> >>> Sent: Thursday, December 04, 2014 11:36 PM
> >>> To: Wu, Feng; t...@linutronix.de; mi...@redhat.com; h...@zytor.com;
> >>> x...@kernel.org; g...@kernel.org; pbonz...@redhat.com;
> >>> dw...@infradead.org; j...@8bytes.org; alex.william...@redhat.com;
> >>> jiang@linux.intel.com
> >>> Cc: linux-ker...@vger.kernel.org; io...@lists.linux-foundation.org;
> >>> kvm@vger.kernel.org
> >>> Subject: Re: [v2 18/25] KVM: kvm-vfio: implement the VFIO skeleton for
> VT-d
> >>> Posted-Interrupts
> >>>
> >>> Hi Feng,
> >>>
> >>> On 12/03/2014 08:39 AM, Feng Wu wrote:
> This patch adds the kvm-vfio interface for VT-d Posted-Interrrupts.
> When guests updates MSI/MSI-x information for an assigned-device,
> >>> update
> QEMU will use KVM_DEV_VFIO_DEVICE_POSTING_IRQ attribute to setup
> IRTE for VT-d PI. This patch implement this IRQ attribute.
> >>> s/implement/implements
>
> Signed-off-by: Feng Wu
> ---
> include/linux/kvm_host.h | 19
> virt/kvm/vfio.c | 103
> >>> ++
> 2 files changed, 122 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index 5cd4420..8d06678 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -1134,6 +1134,25 @@ static inline int
> >>> kvm_arch_vfio_set_forward(struct kvm_fwd_irq *fwd_irq,
> }
> #endif
>
> +#ifdef __KVM_HAVE_ARCH_KVM_VFIO_POSTING
> +/*
> + * kvm_arch_vfio_update_pi_irte - set IRTE for Posted-Interrupts
> + *
> + * @kvm: kvm
> + * @host_irq: host irq of the interrupt
> + * @guest_irq: gsi of the interrupt
> + * returns 0 on success, < 0 on failure
> + */
> +int kvm_arch_vfio_update_pi_irte(struct kvm *kvm, unsigned int
> host_irq,
> + uint32_t guest_irq);
> +#else
> +static int kvm_arch_vfio_update_pi_irte(struct kvm *kvm, unsigned int
> >>> host_irq,
> +uint32_t guest_irq)
> +{
> +return 0;
> +}
> +#endif
> +
> #ifdef CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT
>
> static inline void kvm_vcpu_set_in_spin_loop(struct kvm_vcpu *vcpu,
> bool
> >>> val)
> diff --git a/virt/kvm/vfio.c b/virt/kvm/vfio.c
> index 6bc7001..5e5515f 100644
> --- a/virt/kvm/vfio.c
> +++ b/virt/kvm/vfio.c
> @@ -446,6 +446,99 @@ out:
> return ret;
> }
>
> +static int kvm_vfio_pci_get_irq_count(struct pci_dev *pdev, int
> irq_type)
> +{
> +if (irq_type == VFIO_PCI_INTX_IRQ_INDEX) {
> +u8 pin;
> +
> +pci_read_config_byte(pdev, PCI_INTERRUPT_PIN, &pin);
> +if (pin)
> +return 1;
> +} else if (irq_type == VFIO_PCI_MSI_IRQ_INDEX)
> +return pci_msi_vec_count(pdev);
> +else if (irq_type == VFIO_PCI_MSIX_IRQ_INDEX)
> +return pci_msix_vec_count(pdev);
> +
> +return 0;
> +}
> >>> for platform case I was asked to move the retrieval of absolute irq
> >>> number to the architecture specific part. I don't know if it should
> >>> apply to PCI stuff as well? This explains why I need to pass the VFIO
> >>> device (or struct device handle) to the arch specific part. Actually we
> >>> do the same job, we provide a phys/virt IRQ mapping to KVM, right? So to
> >>> me our architecture specific API should look quite similar?
> >>
> >> In my patch, QEMU passes IRQ type(MSI/MSIx in my case), VFIO device
> index,
> >> and sub-index via "struct kvm_vfio_dev_irq" to KVM, then KVM will find the
> >> real host irq from the VFIO device index and the IRQ type. Is this
> >> something
> >> similar with your patch?
> >>
> >>>
> +
> +static int kvm_vfio_set_pi(struct kvm_device *kdev, int32_t __user
> *argp)
> +{
> +struct kvm_vfio_dev_irq pi_info;
> +uint32_t *gsi;
> +unsigned long minsz;
> +struct vfio_device *vdev;
> +struct msi_desc *entry;
> +struct device *d
RE: [v2 17/25] KVM: kvm-vfio: User API for VT-d Posted-Interrupts
> -Original Message-
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Monday, December 08, 2014 1:21 PM
> To: Wu, Feng
> Cc: Eric Auger; t...@linutronix.de; mi...@redhat.com; h...@zytor.com;
> x...@kernel.org; g...@kernel.org; pbonz...@redhat.com;
> dw...@infradead.org; j...@8bytes.org; jiang@linux.intel.com;
> linux-ker...@vger.kernel.org; io...@lists.linux-foundation.org;
> kvm@vger.kernel.org
> Subject: Re: [v2 17/25] KVM: kvm-vfio: User API for VT-d Posted-Interrupts
>
> On Mon, 2014-12-08 at 04:58 +, Wu, Feng wrote:
> >
> > > -Original Message-
> > > From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org]
> On
> > > Behalf Of Eric Auger
> > > Sent: Thursday, December 04, 2014 10:05 PM
> > > To: Wu, Feng; t...@linutronix.de; mi...@redhat.com; h...@zytor.com;
> > > x...@kernel.org; g...@kernel.org; pbonz...@redhat.com;
> > > dw...@infradead.org; j...@8bytes.org; alex.william...@redhat.com;
> > > jiang@linux.intel.com
> > > Cc: linux-ker...@vger.kernel.org; io...@lists.linux-foundation.org;
> > > kvm@vger.kernel.org
> > > Subject: Re: [v2 17/25] KVM: kvm-vfio: User API for VT-d Posted-Interrupts
> > >
> > > Hi Feng,
> > > On 12/03/2014 08:39 AM, Feng Wu wrote:
> > > > This patch adds and documents a new attribute
> > > > KVM_DEV_VFIO_DEVICE_POSTING_IRQ in KVM_DEV_VFIO_DEVICE
> group.
> > > > This new attribute is used for VT-d Posted-Interrupts.
> > > >
> > > > When guest OS changes the interrupt configuration for an
> > > > assigned device, such as, MSI/MSIx data/address fields,
> > > > QEMU will use this IRQ attribute to tell KVM to update the
> > > > related IRTE according the VT-d Posted-Interrrupts Specification,
> > > > such as, the guest vector should be updated in the related IRTE.
> > > >
> > > > Signed-off-by: Feng Wu
> > > > ---
> > > > Documentation/virtual/kvm/devices/vfio.txt |9 +
> > > > include/uapi/linux/kvm.h | 10 ++
> > > > 2 files changed, 19 insertions(+), 0 deletions(-)
> > > >
> > > > diff --git a/Documentation/virtual/kvm/devices/vfio.txt
> > > b/Documentation/virtual/kvm/devices/vfio.txt
> > > > index f7aff29..41e12b7 100644
> > > > --- a/Documentation/virtual/kvm/devices/vfio.txt
> > > > +++ b/Documentation/virtual/kvm/devices/vfio.txt
> > > > @@ -42,3 +42,12 @@ activated before VFIO_DEVICE_SET_IRQS has been
> > > called to trigger the IRQ
> > > > or associate an eventfd to it. Unforwarding can only be called while
> > > > the
> > > > signaling has been disabled with VFIO_DEVICE_SET_IRQS. If this
> condition
> > > is
> > > > not satisfied, the command returns an -EBUSY.
> > > > +
> > > > + KVM_DEV_VFIO_DEVICE_POSTING_IRQ: Use posted interrtups
> > > mechanism to post
> > > typo
> > > > + the IRQ to guests.
> > > > +For this attribute, kvm_device_attr.addr points to a kvm_vfio_dev_irq
> > > struct.
> > > > +
> > > > +When guest OS changes the interrupt configuration for an assigned
> device,
> > > > +such as, MSI/MSIx data/address fields, QEMU will use this IRQ attribute
> > > > +to tell KVM to update the related IRTE according the VT-d
> > > Posted-Interrrupts
> > > > +Specification, such as, the guest vector should be updated in the
> > > > related
> > > IRTE.
> > > For my curiosity are there any restrictions about the instant at which
> > > the change can be done?
> > > I do not get here how you deactivate the posting?
> >
> > The current method is if the hardware supports interrupts posting, we will
> > use it instead of interrupts remapping, since it has good performance. Why
> > do I need deactivate interrupts posting?
> >
> > Here is the reply to Alex for the same question:
> > "In fact, I don't think we need to stop the posted-interrupts. For setting
> > posted interrupts, we update the related IRTE according to the new
> > format. If the guest reboots, or unload the drivers, or some other
> > operations, the msi/msix will be disabled first, in this path, the irq
> > will be disabled the related IRTE is not used anymore."
>
> Right, and I'm still not sure I agree with that reasoning. We need to
> build the kernel interface to be generic, not tailored for a specific
> userspace. I don't really feel comfortable having something that can't
> be disabled via a similar path to it being enabled. For instance, what
> about a dynamic debug interface where we want to enable tracing and see
> each interrupt injected into the guest. At that point we'd want to
> disabled posted interrupts and direct KVM injection and route via QEMU.
> Thanks,
>
> Alex
Okay, I will think about this.
Thanks,
Feng
>
> > > > diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> > > > index a269a42..7d98650 100644
> > > > --- a/include/uapi/linux/kvm.h
> > > > +++ b/include/uapi/linux/kvm.h
> > > > @@ -949,6 +949,7 @@ struct kvm_device_attr {
> > > > #define KVM_DEV_VFIO_DEVICE 2
> > > > #define KVM_DEV_VFIO_DEVICE_FOR
[GIT PULL 5/9] arm, arm64: KVM: allow forced dcache flush on page faults
From: Laszlo Ersek
To allow handling of incoherent memslots in a subsequent patch, this
patch adds a paramater 'ipa_uncached' to cache_coherent_guest_page()
so that we can instruct it to flush the page's contents to DRAM even
if the guest has caching globally enabled.
Signed-off-by: Laszlo Ersek
Signed-off-by: Ard Biesheuvel
Signed-off-by: Marc Zyngier
---
arch/arm/include/asm/kvm_mmu.h | 5 +++--
arch/arm/kvm/mmu.c | 9 +++--
arch/arm64/include/asm/kvm_mmu.h | 5 +++--
3 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
index acb0d57..f867060 100644
--- a/arch/arm/include/asm/kvm_mmu.h
+++ b/arch/arm/include/asm/kvm_mmu.h
@@ -161,9 +161,10 @@ static inline bool vcpu_has_cache_enabled(struct kvm_vcpu
*vcpu)
}
static inline void coherent_cache_guest_page(struct kvm_vcpu *vcpu, hva_t hva,
-unsigned long size)
+unsigned long size,
+bool ipa_uncached)
{
- if (!vcpu_has_cache_enabled(vcpu))
+ if (!vcpu_has_cache_enabled(vcpu) || ipa_uncached)
kvm_flush_dcache_to_poc((void *)hva, size);
/*
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index b007438..cb924c6 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -852,6 +852,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu,
phys_addr_t fault_ipa,
struct vm_area_struct *vma;
pfn_t pfn;
pgprot_t mem_type = PAGE_S2;
+ bool fault_ipa_uncached;
write_fault = kvm_is_write_fault(vcpu);
if (fault_status == FSC_PERM && !write_fault) {
@@ -918,6 +919,8 @@ static int user_mem_abort(struct kvm_vcpu *vcpu,
phys_addr_t fault_ipa,
if (!hugetlb && !force_pte)
hugetlb = transparent_hugepage_adjust(&pfn, &fault_ipa);
+ fault_ipa_uncached = false;
+
if (hugetlb) {
pmd_t new_pmd = pfn_pmd(pfn, mem_type);
new_pmd = pmd_mkhuge(new_pmd);
@@ -925,7 +928,8 @@ static int user_mem_abort(struct kvm_vcpu *vcpu,
phys_addr_t fault_ipa,
kvm_set_s2pmd_writable(&new_pmd);
kvm_set_pfn_dirty(pfn);
}
- coherent_cache_guest_page(vcpu, hva & PMD_MASK, PMD_SIZE);
+ coherent_cache_guest_page(vcpu, hva & PMD_MASK, PMD_SIZE,
+ fault_ipa_uncached);
ret = stage2_set_pmd_huge(kvm, memcache, fault_ipa, &new_pmd);
} else {
pte_t new_pte = pfn_pte(pfn, mem_type);
@@ -933,7 +937,8 @@ static int user_mem_abort(struct kvm_vcpu *vcpu,
phys_addr_t fault_ipa,
kvm_set_s2pte_writable(&new_pte);
kvm_set_pfn_dirty(pfn);
}
- coherent_cache_guest_page(vcpu, hva, PAGE_SIZE);
+ coherent_cache_guest_page(vcpu, hva, PAGE_SIZE,
+ fault_ipa_uncached);
ret = stage2_set_pte(kvm, memcache, fault_ipa, &new_pte,
pgprot_val(mem_type) == pgprot_val(PAGE_S2_DEVICE));
}
diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
index 0caf7a5..123b521 100644
--- a/arch/arm64/include/asm/kvm_mmu.h
+++ b/arch/arm64/include/asm/kvm_mmu.h
@@ -243,9 +243,10 @@ static inline bool vcpu_has_cache_enabled(struct kvm_vcpu
*vcpu)
}
static inline void coherent_cache_guest_page(struct kvm_vcpu *vcpu, hva_t hva,
-unsigned long size)
+unsigned long size,
+bool ipa_uncached)
{
- if (!vcpu_has_cache_enabled(vcpu))
+ if (!vcpu_has_cache_enabled(vcpu) || ipa_uncached)
kvm_flush_dcache_to_poc((void *)hva, size);
if (!icache_is_aliasing()) {/* PIPT */
--
2.1.2.330.g565301e.dirty
--
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
[GIT PULL 9/9] arm/arm64: KVM: vgic: kick the specific vcpu instead of iterating through all
From: Shannon Zhao
When call kvm_vgic_inject_irq to inject interrupt, we can known which
vcpu the interrupt for by the irq_num and the cpuid. So we should just
kick this vcpu to avoid iterating through all.
Reviewed-by: Christoffer Dall
Signed-off-by: Shannon Zhao
Signed-off-by: Marc Zyngier
---
virt/kvm/arm/vgic.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
index 631a472..21e035c 100644
--- a/virt/kvm/arm/vgic.c
+++ b/virt/kvm/arm/vgic.c
@@ -1607,7 +1607,7 @@ static int vgic_validate_injection(struct kvm_vcpu *vcpu,
int irq, int level)
}
}
-static bool vgic_update_irq_pending(struct kvm *kvm, int cpuid,
+static int vgic_update_irq_pending(struct kvm *kvm, int cpuid,
unsigned int irq_num, bool level)
{
struct vgic_dist *dist = &kvm->arch.vgic;
@@ -1673,7 +1673,7 @@ static bool vgic_update_irq_pending(struct kvm *kvm, int
cpuid,
out:
spin_unlock(&dist->lock);
- return ret;
+ return ret ? cpuid : -EINVAL;
}
/**
@@ -1693,9 +1693,14 @@ out:
int kvm_vgic_inject_irq(struct kvm *kvm, int cpuid, unsigned int irq_num,
bool level)
{
- if (likely(vgic_initialized(kvm)) &&
- vgic_update_irq_pending(kvm, cpuid, irq_num, level))
- vgic_kick_vcpus(kvm);
+ int vcpu_id;
+
+ if (likely(vgic_initialized(kvm))) {
+ vcpu_id = vgic_update_irq_pending(kvm, cpuid, irq_num, level);
+ if (vcpu_id >= 0)
+ /* kick the specified vcpu */
+ kvm_vcpu_kick(kvm_get_vcpu(kvm, vcpu_id));
+ }
return 0;
}
--
2.1.2.330.g565301e.dirty
--
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
[GIT PULL 3/9] kvm: fix kvm_is_mmio_pfn() and rename to kvm_is_reserved_pfn()
From: Ard Biesheuvel
This reverts commit 85c8555ff0 ("KVM: check for !is_zero_pfn() in
kvm_is_mmio_pfn()") and renames the function to kvm_is_reserved_pfn.
The problem being addressed by the patch above was that some ARM code
based the memory mapping attributes of a pfn on the return value of
kvm_is_mmio_pfn(), whose name indeed suggests that such pfns should
be mapped as device memory.
However, kvm_is_mmio_pfn() doesn't do quite what it says on the tin,
and the existing non-ARM users were already using it in a way which
suggests that its name should probably have been 'kvm_is_reserved_pfn'
from the beginning, e.g., whether or not to call get_page/put_page on
it etc. This means that returning false for the zero page is a mistake
and the patch above should be reverted.
Signed-off-by: Ard Biesheuvel
Signed-off-by: Marc Zyngier
---
arch/ia64/kvm/kvm-ia64.c | 2 +-
arch/x86/kvm/mmu.c | 6 +++---
include/linux/kvm_host.h | 2 +-
virt/kvm/kvm_main.c | 16
4 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/arch/ia64/kvm/kvm-ia64.c b/arch/ia64/kvm/kvm-ia64.c
index ec6b9ac..dbe46f4 100644
--- a/arch/ia64/kvm/kvm-ia64.c
+++ b/arch/ia64/kvm/kvm-ia64.c
@@ -1563,7 +1563,7 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
for (i = 0; i < npages; i++) {
pfn = gfn_to_pfn(kvm, base_gfn + i);
- if (!kvm_is_mmio_pfn(pfn)) {
+ if (!kvm_is_reserved_pfn(pfn)) {
kvm_set_pmt_entry(kvm, base_gfn + i,
pfn << PAGE_SHIFT,
_PAGE_AR_RWX | _PAGE_MA_WB);
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index ac1c4de..978f402 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -630,7 +630,7 @@ static int mmu_spte_clear_track_bits(u64 *sptep)
* kvm mmu, before reclaiming the page, we should
* unmap it from mmu first.
*/
- WARN_ON(!kvm_is_mmio_pfn(pfn) && !page_count(pfn_to_page(pfn)));
+ WARN_ON(!kvm_is_reserved_pfn(pfn) && !page_count(pfn_to_page(pfn)));
if (!shadow_accessed_mask || old_spte & shadow_accessed_mask)
kvm_set_pfn_accessed(pfn);
@@ -2461,7 +2461,7 @@ static int set_spte(struct kvm_vcpu *vcpu, u64 *sptep,
spte |= PT_PAGE_SIZE_MASK;
if (tdp_enabled)
spte |= kvm_x86_ops->get_mt_mask(vcpu, gfn,
- kvm_is_mmio_pfn(pfn));
+ kvm_is_reserved_pfn(pfn));
if (host_writable)
spte |= SPTE_HOST_WRITEABLE;
@@ -2737,7 +2737,7 @@ static void transparent_hugepage_adjust(struct kvm_vcpu
*vcpu,
* PT_PAGE_TABLE_LEVEL and there would be no adjustment done
* here.
*/
- if (!is_error_noslot_pfn(pfn) && !kvm_is_mmio_pfn(pfn) &&
+ if (!is_error_noslot_pfn(pfn) && !kvm_is_reserved_pfn(pfn) &&
level == PT_PAGE_TABLE_LEVEL &&
PageTransCompound(pfn_to_page(pfn)) &&
!has_wrprotected_page(vcpu->kvm, gfn, PT_DIRECTORY_LEVEL)) {
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index ea53b04..a6059bd 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -703,7 +703,7 @@ void kvm_arch_sync_events(struct kvm *kvm);
int kvm_cpu_has_pending_timer(struct kvm_vcpu *vcpu);
void kvm_vcpu_kick(struct kvm_vcpu *vcpu);
-bool kvm_is_mmio_pfn(pfn_t pfn);
+bool kvm_is_reserved_pfn(pfn_t pfn);
struct kvm_irq_ack_notifier {
struct hlist_node link;
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 25ffac9..3cee7b1 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -107,10 +107,10 @@ EXPORT_SYMBOL_GPL(kvm_rebooting);
static bool largepages_enabled = true;
-bool kvm_is_mmio_pfn(pfn_t pfn)
+bool kvm_is_reserved_pfn(pfn_t pfn)
{
if (pfn_valid(pfn))
- return !is_zero_pfn(pfn) && PageReserved(pfn_to_page(pfn));
+ return PageReserved(pfn_to_page(pfn));
return true;
}
@@ -1321,7 +1321,7 @@ static pfn_t hva_to_pfn(unsigned long addr, bool atomic,
bool *async,
else if ((vma->vm_flags & VM_PFNMAP)) {
pfn = ((addr - vma->vm_start) >> PAGE_SHIFT) +
vma->vm_pgoff;
- BUG_ON(!kvm_is_mmio_pfn(pfn));
+ BUG_ON(!kvm_is_reserved_pfn(pfn));
} else {
if (async && vma_is_valid(vma, write_fault))
*async = true;
@@ -1427,7 +1427,7 @@ static struct page *kvm_pfn_to_page(pfn_t pfn)
if (is_error_noslot_pfn(pfn))
return KVM_ERR_PTR_BAD_PAGE;
- if (kvm_is_mmio_pfn(pfn)) {
+ if (kvm_is_reserved_pfn(pfn)) {
WARN_ON(1);
return KVM_ERR_PTR_BAD_PAGE;
}
@@ -1456,7 +1456,7 @@ EXPORT_SYMBOL_GPL(kvm_release_page_clean);
void kvm_release_pfn_clean(pfn_t pfn)
{
- if (!is_error_noslot_pfn(pfn) && !kvm_is_mmio_pfn(pfn))
+
[GIT PULL 0/9] KVM/ARM Changes for v3.19
Hi Paolo, The following changes since commit f62c95fd4041d669159dd76ac0bb2a7f86b5b05d: Merge tag 'kvm-s390-next-20141028' of git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux into HEAD (2014-10-29 13:31:32 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git kvm-arm-for-3.19 for you to fetch changes up to 016ed39c54b8a3db680e5c6a43419f806133caf2: arm/arm64: KVM: vgic: kick the specific vcpu instead of iterating through all (2014-11-26 10:19:37 +) Thanks, -Christoffer Changes for KVM for arm/arm64 for v3.19 including mmio mapping fixups (already in kvm/next, apologies about duplicate commits), vgic cleanup and optimizations, and an MMIO path cleanup. Andre Przywara (1): arm/arm64: KVM: avoid unnecessary guest register mangling on MMIO read Ard Biesheuvel (4): arm/arm64: kvm: drop inappropriate use of kvm_is_mmio_pfn() kvm: fix kvm_is_mmio_pfn() and rename to kvm_is_reserved_pfn() kvm: add a memslot flag for incoherent memory regions arm, arm64: KVM: handle potential incoherency of readonly memslots Christoffer Dall (1): arm/arm64: vgic: Remove unreachable irq_clear_pending Laszlo Ersek (1): arm, arm64: KVM: allow forced dcache flush on page faults Shannon Zhao (1): arm/arm64: KVM: vgic: kick the specific vcpu instead of iterating through all wanghaibin (1): KVM: ARM: VGIC: Optimize the vGIC vgic_update_irq_pending function. arch/arm/include/asm/kvm_mmu.h | 5 +++-- arch/arm/kvm/mmio.c | 15 +-- arch/arm/kvm/mmu.c | 34 +++--- arch/arm64/include/asm/kvm_mmu.h | 5 +++-- arch/ia64/kvm/kvm-ia64.c | 2 +- arch/x86/kvm/mmu.c | 6 +++--- include/linux/kvm_host.h | 3 ++- virt/kvm/arm/vgic.c | 20 +--- virt/kvm/kvm_main.c | 16 9 files changed, 69 insertions(+), 37 deletions(-) -- 2.1.2.330.g565301e.dirty -- 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
[GIT PULL 4/9] kvm: add a memslot flag for incoherent memory regions
From: Ard Biesheuvel Memory regions may be incoherent with the caches, typically when the guest has mapped a host system RAM backed memory region as uncached. Add a flag KVM_MEMSLOT_INCOHERENT so that we can tag these memslots and handle them appropriately when mapping them. Signed-off-by: Ard Biesheuvel Signed-off-by: Marc Zyngier --- include/linux/kvm_host.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h index a6059bd..e4d8f70 100644 --- a/include/linux/kvm_host.h +++ b/include/linux/kvm_host.h @@ -43,6 +43,7 @@ * include/linux/kvm_h. */ #define KVM_MEMSLOT_INVALID(1UL << 16) +#define KVM_MEMSLOT_INCOHERENT (1UL << 17) /* Two fragments for cross MMIO pages. */ #define KVM_MAX_MMIO_FRAGMENTS 2 -- 2.1.2.330.g565301e.dirty -- 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
[GIT PULL 8/9] arm/arm64: vgic: Remove unreachable irq_clear_pending
When 'injecting' an edge-triggered interrupt with a falling edge we
shouldn't clear the pending state on the distributor. In fact, we
don't, because the check in vgic_validate_injection would prevent us
from ever reaching this bit of code.
Remove the unreachable snippet.
Signed-off-by: Christoffer Dall
Signed-off-by: Marc Zyngier
---
virt/kvm/arm/vgic.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
index 5acf2c9..631a472 100644
--- a/virt/kvm/arm/vgic.c
+++ b/virt/kvm/arm/vgic.c
@@ -1643,8 +1643,6 @@ static bool vgic_update_irq_pending(struct kvm *kvm, int
cpuid,
vgic_dist_irq_clear_level(vcpu, irq_num);
if (!vgic_dist_irq_soft_pend(vcpu, irq_num))
vgic_dist_irq_clear_pending(vcpu, irq_num);
- } else {
- vgic_dist_irq_clear_pending(vcpu, irq_num);
}
ret = false;
--
2.1.2.330.g565301e.dirty
--
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
[GIT PULL 2/9] arm/arm64: kvm: drop inappropriate use of kvm_is_mmio_pfn()
From: Ard Biesheuvel
Instead of using kvm_is_mmio_pfn() to decide whether a host region
should be stage 2 mapped with device attributes, add a new static
function kvm_is_device_pfn() that disregards RAM pages with the
reserved bit set, as those should usually not be mapped as device
memory.
Signed-off-by: Ard Biesheuvel
Signed-off-by: Marc Zyngier
---
arch/arm/kvm/mmu.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index 57a403a..b007438 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -834,6 +834,11 @@ static bool kvm_is_write_fault(struct kvm_vcpu *vcpu)
return kvm_vcpu_dabt_iswrite(vcpu);
}
+static bool kvm_is_device_pfn(unsigned long pfn)
+{
+ return !pfn_valid(pfn);
+}
+
static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
struct kvm_memory_slot *memslot, unsigned long hva,
unsigned long fault_status)
@@ -904,7 +909,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu,
phys_addr_t fault_ipa,
if (is_error_pfn(pfn))
return -EFAULT;
- if (kvm_is_mmio_pfn(pfn))
+ if (kvm_is_device_pfn(pfn))
mem_type = PAGE_S2_DEVICE;
spin_lock(&kvm->mmu_lock);
--
2.1.2.330.g565301e.dirty
--
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
[GIT PULL 1/9] KVM: ARM: VGIC: Optimize the vGIC vgic_update_irq_pending function.
From: wanghaibin
When vgic_update_irq_pending with level-sensitive false, it is need to
deactivates an interrupt, and, it can go to out directly.
Here return a false value, because it will be not need to kick.
Signed-off-by: wanghaibin
Signed-off-by: Marc Zyngier
---
virt/kvm/arm/vgic.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
index 3aaca49..5acf2c9 100644
--- a/virt/kvm/arm/vgic.c
+++ b/virt/kvm/arm/vgic.c
@@ -1646,6 +1646,9 @@ static bool vgic_update_irq_pending(struct kvm *kvm, int
cpuid,
} else {
vgic_dist_irq_clear_pending(vcpu, irq_num);
}
+
+ ret = false;
+ goto out;
}
enabled = vgic_irq_is_enabled(vcpu, irq_num);
--
2.1.2.330.g565301e.dirty
--
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
[GIT PULL 6/9] arm, arm64: KVM: handle potential incoherency of readonly memslots
From: Ard Biesheuvel
Readonly memslots are often used to implement emulation of ROMs and
NOR flashes, in which case the guest may legally map these regions as
uncached.
To deal with the incoherency associated with uncached guest mappings,
treat all readonly memslots as incoherent, and ensure that pages that
belong to regions tagged as such are flushed to DRAM before being passed
to the guest.
Signed-off-by: Ard Biesheuvel
Signed-off-by: Marc Zyngier
---
arch/arm/kvm/mmu.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index cb924c6..f2a9874 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -919,7 +919,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu,
phys_addr_t fault_ipa,
if (!hugetlb && !force_pte)
hugetlb = transparent_hugepage_adjust(&pfn, &fault_ipa);
- fault_ipa_uncached = false;
+ fault_ipa_uncached = memslot->flags & KVM_MEMSLOT_INCOHERENT;
if (hugetlb) {
pmd_t new_pmd = pfn_pmd(pfn, mem_type);
@@ -1298,11 +1298,12 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
hva = vm_end;
} while (hva < reg_end);
- if (ret) {
- spin_lock(&kvm->mmu_lock);
+ spin_lock(&kvm->mmu_lock);
+ if (ret)
unmap_stage2_range(kvm, mem->guest_phys_addr, mem->memory_size);
- spin_unlock(&kvm->mmu_lock);
- }
+ else
+ stage2_flush_memslot(kvm, memslot);
+ spin_unlock(&kvm->mmu_lock);
return ret;
}
@@ -1314,6 +1315,15 @@ void kvm_arch_free_memslot(struct kvm *kvm, struct
kvm_memory_slot *free,
int kvm_arch_create_memslot(struct kvm *kvm, struct kvm_memory_slot *slot,
unsigned long npages)
{
+ /*
+* Readonly memslots are not incoherent with the caches by definition,
+* but in practice, they are used mostly to emulate ROMs or NOR flashes
+* that the guest may consider devices and hence map as uncached.
+* To prevent incoherency issues in these cases, tag all readonly
+* regions as incoherent.
+*/
+ if (slot->flags & KVM_MEM_READONLY)
+ slot->flags |= KVM_MEMSLOT_INCOHERENT;
return 0;
}
--
2.1.2.330.g565301e.dirty
--
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
[GIT PULL 7/9] arm/arm64: KVM: avoid unnecessary guest register mangling on MMIO read
From: Andre Przywara
Currently we mangle the endianness of the guest's register even on an
MMIO _read_, where it is completely useless, because we will not use
the value of that register.
Rework the io_mem_abort() function to clearly separate between reads
and writes and only do the endianness mangling on MMIO writes.
Signed-off-by: Andre Przywara
Signed-off-by: Marc Zyngier
---
arch/arm/kvm/mmio.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/arch/arm/kvm/mmio.c b/arch/arm/kvm/mmio.c
index 4cb5a93..5d3bfc0 100644
--- a/arch/arm/kvm/mmio.c
+++ b/arch/arm/kvm/mmio.c
@@ -187,15 +187,18 @@ int io_mem_abort(struct kvm_vcpu *vcpu, struct kvm_run
*run,
}
rt = vcpu->arch.mmio_decode.rt;
- data = vcpu_data_guest_to_host(vcpu, *vcpu_reg(vcpu, rt), mmio.len);
- trace_kvm_mmio((mmio.is_write) ? KVM_TRACE_MMIO_WRITE :
-KVM_TRACE_MMIO_READ_UNSATISFIED,
- mmio.len, fault_ipa,
- (mmio.is_write) ? data : 0);
+ if (mmio.is_write) {
+ data = vcpu_data_guest_to_host(vcpu, *vcpu_reg(vcpu, rt),
+ mmio.len);
- if (mmio.is_write)
+ trace_kvm_mmio(KVM_TRACE_MMIO_WRITE, mmio.len,
+ fault_ipa, data);
mmio_write_buf(mmio.data, mmio.len, data);
+ } else {
+ trace_kvm_mmio(KVM_TRACE_MMIO_READ_UNSATISFIED, mmio.len,
+ fault_ipa, 0);
+ }
if (vgic_handle_mmio(vcpu, run, &mmio))
return 1;
--
2.1.2.330.g565301e.dirty
--
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: bridge mode without network rework
Yes macvtap should be a solution, but somehow libvirt can't turn on VM itself afterwards. Any idea? Sent from my BlackBerry 10 smartphone. Thomas Lau Director of Infrastructure Tetrion Capital Limited Direct: +852-3976-8903 Mobile: +852-9323-9670 Address: 20/F, IFC 1, Central district, Hong Kong Original Message From: Stefan Hajnoczi Sent: Tuesday, 9 December, 2014 6:55 PM To: Thomas Lau Cc: kvm Subject: Re: bridge mode without network rework On Mon, Dec 08, 2014 at 10:36:12AM +0800, Thomas Lau wrote: > I just wondering is it possible not to rework our host machine network > structure to get KVM guest working on bridge mode? Current > implementation is using brctl to control it, which is destructive > especially you have a host which is using that network card to connect > internet. Are you deploying KVM and worried about the one-time downtime that might be introduced by setting up a bridged setup on the host? Once you have the bridge working you can add/remove tap interfaces from it without affecting the host's physical interface. I'm not sure I understand the problem. Perhaps macvtap is what you want: http://virt.kernelnewbies.org/MacVTap http://wiki.math.cmu.edu/iki/wiki/tips/20140303-kvm-macvtap.html Stefan -- 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: bridge mode without network rework
On Mon, Dec 08, 2014 at 10:36:12AM +0800, Thomas Lau wrote: > I just wondering is it possible not to rework our host machine network > structure to get KVM guest working on bridge mode? Current > implementation is using brctl to control it, which is destructive > especially you have a host which is using that network card to connect > internet. Are you deploying KVM and worried about the one-time downtime that might be introduced by setting up a bridged setup on the host? Once you have the bridge working you can add/remove tap interfaces from it without affecting the host's physical interface. I'm not sure I understand the problem. Perhaps macvtap is what you want: http://virt.kernelnewbies.org/MacVTap http://wiki.math.cmu.edu/iki/wiki/tips/20140303-kvm-macvtap.html Stefan pgpltKCyjGwMk.pgp Description: PGP signature
Re: [qemu] virtio drivers implementation details
On Tue, Dec 02, 2014 at 01:26:10PM +0200, Vasile Catalin-B50542 wrote: > I'm trying to make a custom virtio driver that mostly interacts with memory. > I've came upon a presentation which shows which files need to be edited on > qemu > and kvm in order to add a new virtio driver. > One of the files in qemu is include/hw/pci/pci.h, > but that was an example specific to virtio pci. > virtio-mmio is better mapped on my situation, but I can't seem to find a > similar header for it. > In fact I can't find anything related to virtio mmio through out the header > files If you are adding a new device type (e.g. printer device) then the code should not depend on the transport (PCI, MMIO, CCW, etc). Can you explain what type of device you are trying to implement? Stefan pgpz34LFx1vjb.pgp Description: PGP signature
Re: [ANNOUNCE][RFC] KVMGT - the implementation of Intel GVT-g(full GPU virtualization) for KVM
On 2014-12-04 03:24, Jike Song wrote: > Hi all, > > We are pleased to announce the first release of KVMGT project. KVMGT is > the implementation of Intel GVT-g technology, a full GPU virtualization > solution. Under Intel GVT-g, a virtual GPU instance is maintained for > each VM, with part of performance critical resources directly assigned. > The capability of running native graphics driver inside a VM, without > hypervisor intervention in performance critical paths, achieves a good > balance of performance, feature, and sharing capability. > > > KVMGT is still in the early stage: > > - Basic functions of full GPU virtualization works, guest can see a > full-featured vGPU. > We ran several 3D workloads such as lightsmark, nexuiz, urbanterror > and warsow. > > - Only Linux guest supported so far, and PPGTT must be disabled in > guest through a > kernel parameter(see README.kvmgt in QEMU). > > - This drop also includes some Xen specific changes, which will be > cleaned up later. > > - Our end goal is to upstream both XenGT and KVMGT, which shares ~90% > logic for vGPU > device model (will be part of i915 driver), with only difference in > hypervisor > specific services > > - insufficient test coverage, so please bear with stability issues :) > > > > There are things need to be improved, esp. the KVM interfacing part: > > 1a domid was added to each KVMGT guest > > An ID is needed for foreground OS switching, e.g. > > # echo >/sys/kernel/vgt/control/foreground_vm > > domid 0 is reserved for host OS. > > > 2SRCU workarounds. > > Some KVM functions, such as: > > kvm_io_bus_register_dev > install_new_memslots > > must be called *without* &kvm->srcu read-locked. Otherwise it > hangs. > > In KVMGT, we need to register an iodev only *after* BAR > registers are > written by guest. That means, we already have &kvm->srcu hold - > trapping/emulating PIO(BAR registers) makes us in such a condition. > That will make kvm_io_bus_register_dev hangs. > > Currently we have to disable rcu_assign_pointer() in such > functions. > > These were dirty workarounds, your suggestions are high welcome! > > > 3syscalls were called to access "/dev/mem" from kernel > > An in-kernel memslot was added for aperture, but using syscalls > like > open and mmap to open and access the character device "/dev/mem", > for pass-through. > > > > > The source codes(kernel, qemu as well as seabios) are available at github: > > git://github.com/01org/KVMGT-kernel > git://github.com/01org/KVMGT-qemu > git://github.com/01org/KVMGT-seabios > > In the KVMGT-qemu repository, there is a "README.kvmgt" to be referred. > > > > More information about Intel GVT-g and KVMGT can be found at: > > > https://www.usenix.org/conference/atc14/technical-sessions/presentation/tian > > > http://events.linuxfoundation.org/sites/events/files/slides/KVMGT-a%20Full%20GPU%20Virtualization%20Solution_1.pdf > > > > Appreciate your comments, BUG reports, and contributions! > There is an even increasing interest to keep KVM's in-kernel guest interface as small as possible, specifically for security reasons. I'm sure there are some good performance reasons to create a new in-kernel device model, but I suppose those will need good evidences why things are done in the way they finally should be - and not via a user-space device model. This is likely not a binary decision (all userspace vs. no userspace), it is more about the size and robustness of the in-kernel model vs. its performance. One aspect could also be important: Are there hardware improvements in sight that will eventually help to reduce the in-kernel device model and make the overall design even more robust? How will those changes fit best into a proposed user/kernel split? Jan -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux -- 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: [Xen-devel] [PATCH v3 2/2] x86, arm64, platform, xen, kconfig: add xen defconfig helper
Hello Luis, On 08/12/2014 23:05, Luis R. Rodriguez wrote: diff --git a/kernel/configs/xen.config b/kernel/configs/xen.config new file mode 100644 index 000..0d0eb6d --- /dev/null +++ b/kernel/configs/xen.config +CONFIG_XEN_MCE_LOG=y MCE is x86 specific. +CONFIG_XEN_HAVE_PVMMU=y We don't have PVMMU support on ARM. Shouldn't you move this config in architecture specific code? Regards -- Julien Grall -- 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: Windows 7 VM BSOD
Hi Vadim, Now turning on is OK somehow, shutdown still stuck. On Tue, Dec 9, 2014 at 4:03 PM, Vadim Rozenfeld wrote: > On Tue, 2014-12-09 at 15:54 +0800, Thomas Lau wrote: >> I changed CPU type to Westmere, it boot up with 0x05C BSOD > > It should be four parameters printed on the screen, right below > the error code string. Could you please post them? > > Vadim. > >> >> On Tue, Dec 9, 2014 at 3:10 PM, Vadim Rozenfeld wrote: >> > On Tue, 2014-12-09 at 11:54 +0800, Thomas Lau wrote: >> >> Hi Vadim, >> >> >> >> I want to quote back to your original post back in early 2014: >> >> https://www.mail-archive.com/kvm@vger.kernel.org/msg99782.html >> >> >> >> >> >> According to >> >> http://msdn.microsoft.com/en-us/library/windows/hardware/ff559069(v=vs.85).aspx >> >> the 0x5C means HAL_INITIALIZATION_FAILED >> >> >> >> Problem matched exactly, which I am using CPU IvyBridge-EP and I got >> >> same BSOD as well. >> > >> > Some CPU flags (feature bits) should be missing. >> > Can you try changing cpu type? >> > >> > Best regards, >> > Vadim. >> > >> >> >> >> Are we missing some hyperv feature? >> >> >> >> On Wed, Dec 3, 2014 at 7:29 PM, Vadim Rozenfeld >> >> wrote: >> >> > If you run WS2008(R2) or Win7 - always turn on relaxed timing. Otherwise >> >> > it's just a matter of time when you hit 101 BOSD. >> >> > Bugcheck 78 is quite rare one. What is your setup, and how easy it's >> >> > reproducible? >> >> > >> >> > Best regards, >> >> > Vadim. >> >> > >> >> > On Wed, 2014-12-03 at 19:13 +0800, Thomas Lau wrote: >> >> >> "it works on your side" meaning that you had such issue but afterwards >> >> >> it's all fixed by apply hv_relaxed ? >> >> >> >> >> >> On Wed, Dec 3, 2014 at 7:08 PM, Zhang Haoyu >> >> >> wrote: >> >> >> >> https://bugzilla.redhat.com/show_bug.cgi?id=893857 >> >> >> >> >> >> >> >> In fact I am doing testing now, but are we fixing one problem and >> >> >> >> introduce other problem?! >> >> >> >> >> >> >> > I'm not sure about this, but it works on my side, >> >> >> > I think BSOD(error:0x0078) has been fixed, >> >> >> > please show your environment. >> >> >> > >> >> >> > Thanks, >> >> >> > Zhang Haoyu >> >> >> >> On Wed, Dec 3, 2014 at 6:36 PM, Thomas Lau >> >> >> >> wrote: >> >> >> >> > Hi, >> >> >> >> > >> >> >> >> > How do I know if my qemu-kvm version support this? >> >> >> >> > >> >> >> >> > On Wed, Dec 3, 2014 at 6:25 PM, Zhang Haoyu >> >> >> >> > wrote: >> >> >> >> >>> Hi All, >> >> >> >> >>> >> >> >> >> >>> I am running 3.13.0-24-generic kernel on Ubuntu 14, Windows 7 VM >> >> >> >> >>> installation was fine, but it does random reboot by itself, the >> >> >> >> >>> error >> >> >> >> >>> code is 0x0101, does anyone know how to fix this? >> >> >> >> >> Could you try hv_relaxed, like "-cpu kvm64,hv_relaxed". >> >> >> >> >> >> >> >> >> >> Thanks, >> >> >> >> >> Zhang Haoyu >> >> >> > >> >> >> -- >> >> >> 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 >> >> > >> >> > >> >> >> >> >> >> >> > >> > >> >> >> > > -- Thomas Lau Director of Infrastructure Tetrion Capital Limited Direct: +852-3976-8903 Mobile: +852-9323-9670 Address: 20/F, IFC 1, Central district, Hong Kong -- 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: Windows 7 VM BSOD
On Tue, 2014-12-09 at 15:54 +0800, Thomas Lau wrote: > I changed CPU type to Westmere, it boot up with 0x05C BSOD It should be four parameters printed on the screen, right below the error code string. Could you please post them? Vadim. > > On Tue, Dec 9, 2014 at 3:10 PM, Vadim Rozenfeld wrote: > > On Tue, 2014-12-09 at 11:54 +0800, Thomas Lau wrote: > >> Hi Vadim, > >> > >> I want to quote back to your original post back in early 2014: > >> https://www.mail-archive.com/kvm@vger.kernel.org/msg99782.html > >> > >> > >> According to > >> http://msdn.microsoft.com/en-us/library/windows/hardware/ff559069(v=vs.85).aspx > >> the 0x5C means HAL_INITIALIZATION_FAILED > >> > >> Problem matched exactly, which I am using CPU IvyBridge-EP and I got > >> same BSOD as well. > > > > Some CPU flags (feature bits) should be missing. > > Can you try changing cpu type? > > > > Best regards, > > Vadim. > > > >> > >> Are we missing some hyperv feature? > >> > >> On Wed, Dec 3, 2014 at 7:29 PM, Vadim Rozenfeld > >> wrote: > >> > If you run WS2008(R2) or Win7 - always turn on relaxed timing. Otherwise > >> > it's just a matter of time when you hit 101 BOSD. > >> > Bugcheck 78 is quite rare one. What is your setup, and how easy it's > >> > reproducible? > >> > > >> > Best regards, > >> > Vadim. > >> > > >> > On Wed, 2014-12-03 at 19:13 +0800, Thomas Lau wrote: > >> >> "it works on your side" meaning that you had such issue but afterwards > >> >> it's all fixed by apply hv_relaxed ? > >> >> > >> >> On Wed, Dec 3, 2014 at 7:08 PM, Zhang Haoyu wrote: > >> >> >> https://bugzilla.redhat.com/show_bug.cgi?id=893857 > >> >> >> > >> >> >> In fact I am doing testing now, but are we fixing one problem and > >> >> >> introduce other problem?! > >> >> >> > >> >> > I'm not sure about this, but it works on my side, > >> >> > I think BSOD(error:0x0078) has been fixed, > >> >> > please show your environment. > >> >> > > >> >> > Thanks, > >> >> > Zhang Haoyu > >> >> >> On Wed, Dec 3, 2014 at 6:36 PM, Thomas Lau > >> >> >> wrote: > >> >> >> > Hi, > >> >> >> > > >> >> >> > How do I know if my qemu-kvm version support this? > >> >> >> > > >> >> >> > On Wed, Dec 3, 2014 at 6:25 PM, Zhang Haoyu > >> >> >> > wrote: > >> >> >> >>> Hi All, > >> >> >> >>> > >> >> >> >>> I am running 3.13.0-24-generic kernel on Ubuntu 14, Windows 7 VM > >> >> >> >>> installation was fine, but it does random reboot by itself, the > >> >> >> >>> error > >> >> >> >>> code is 0x0101, does anyone know how to fix this? > >> >> >> >> Could you try hv_relaxed, like "-cpu kvm64,hv_relaxed". > >> >> >> >> > >> >> >> >> Thanks, > >> >> >> >> Zhang Haoyu > >> >> > > >> >> -- > >> >> 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 > >> > > >> > > >> > >> > >> > > > > > > > -- 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
