* Jan Kiszka (jan.kis...@web.de) wrote:
> This redundancy breaks subtly when building against recent OpenSUSE
> kernels.
What breaks?
--
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.o
* Gregory Haskins (ghask...@novell.com) wrote:
> It would appear that we are invoking kfree() on the wrong pointer in the
> destructor for the coalesced_mmio device. This would result in a potential
> leak during shutdown.
Happens to work and not leak:
struct kvm_coalesced_mmio_dev {
st
* Gregory Haskins (gregory.hask...@gmail.com) wrote:
> Chris Wright wrote:
> > * Gregory Haskins (ghask...@novell.com) wrote:
> >> It would appear that we are invoking kfree() on the wrong pointer in the
> >> destructor for the coalesced_mmio device. This would resu
* Gregory Haskins (ghask...@novell.com) wrote:
> We modernize the io_device code so that we use container_of() instead of
> dev->private, and move the vtable to a separate ops structure
> (theoretically allows better caching for multiple instances of the same
> ops structure)
Looks like a nice cle
ement of the private structure, but this could change in
> the future, so lets clean this up.
>
> Signed-off-by: Gregory Haskins
Acked-by: Chris Wright
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.o
;
> Signed-off-by: Gregory Haskins
Acked-by: Chris Wright
--
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
ed-off-by: Gregory Haskins
Acked-by: Chris Wright
--
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
* Michael S. Tsirkin (m...@redhat.com) wrote:
> +struct generic_dev {
I know I commented on this one on an earlier, private version, and naming
is not my strength... maybe "struct uio_generic_pci_dev" or "struct
uio_generic_pci"?
> + struct uio_info info;
> + struct pci_dev *pdev;
> +
* Anthony Liguori (anth...@codemonkey.ws) wrote:
> I didn't know this was possible... so we could also use this driver for
> vm-channel.
With MSI things are much nicer (which we could define for vm-channel).
This is for shared legacy INTx.
>> +
>> +err = pci_request_regions(pdev, "uio_pci_
* Michael S. Tsirkin (m...@redhat.com) wrote:
> - remove irqcontrol: user can enable interrupts by
> writing command register directly
Sorry if I gave you the impression that removing was needed.
I actually think the irqcontrol was useful since it's atomic.
> + gdev->info.name = "uio_pci_ge
* Michael S. Tsirkin (m...@redhat.com) wrote:
> On Tue, Jul 14, 2009 at 11:03:38AM -0700, Chris Wright wrote:
> > * Michael S. Tsirkin (m...@redhat.com) wrote:
> > > - remove irqcontrol: user can enable interrupts by
> > > writing command register directly
>
t;
Looks good.
Acked-by: Chris Wright
--
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
concerns about backwards compat
- https://bugzilla.redhat.com/show_bug.cgi?id=689672
- f13 host can no longer run f14 guest after qemu update
- this particular bug is older f13 which includes patched qemu...
- could be useful to fingerprint the guest (lspci, etc)
- sounds simple enough, need so
* Nai Xia (nai@gmail.com) wrote:
> Introduced kvm_mmu_notifier_test_and_clear_dirty(),
> kvm_mmu_notifier_dirty_update()
> and their mmu_notifier interfaces to support KSM dirty bit tracking, which
> brings
> significant performance gain in volatile pages scanning in KSM.
> Currently, kvm_mmu
* Izik Eidus (izik.ei...@ravellosystems.com) wrote:
> On 6/22/2011 3:21 AM, Chris Wright wrote:
> >* Nai Xia (nai@gmail.com) wrote:
> >>+ if (!shadow_dirty_mask) {
> >>+ WARN(1, "KVM: do NOT try to test dirty bit in EPT\n");
> >>+
* David Woodhouse (dw...@infradead.org) wrote:
> I'd much rather KVM just gave us a list of the pages to map, in a single
> call.
This makes most sense to me.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info
* Donald Dutile (ddut...@redhat.com) wrote:
> diff --git a/hw/device-assignment.c b/hw/device-assignment.c
> index 36ad6b0..34db52e 100644
> --- a/hw/device-assignment.c
> +++ b/hw/device-assignment.c
> @@ -1419,16 +1419,18 @@ static int assigned_device_pci_cap_init(PCIDevice
> *pci_dev)
> }
* Alex Williamson (alex.william...@redhat.com) wrote:
> On Fri, 2011-07-22 at 14:24 -0700, Chris Wright wrote:
> > * Donald Dutile (ddut...@redhat.com) wrote:
> > > diff --git a/hw/device-assignment.c b/hw/device-assignment.c
> > > index 36ad6b0..34db52e 100644
> &g
* Don Dutile (ddut...@redhat.com) wrote:
> On 07/24/2011 06:58 AM, Michael S. Tsirkin wrote:
> >On Sun, Jul 24, 2011 at 11:41:10AM +0300, Michael S. Tsirkin wrote:
> >>On Sun, Jul 24, 2011 at 11:12:44AM +0300, Michael S. Tsirkin wrote:
> >>>On Fri, Jul 22, 2011 at
* André Weidemann (andre.weidem...@web.de) wrote:
> >git clone git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git
> >./configure --audio-drv-list=alsa --target-list=x86_64-softmmu
> >--enable-kvm-device-assignment
> >
> >ERROR: unknown option --enable-kvm-device-assignment
> How come so many rev
* Aaron Fabbri (aafab...@cisco.com) wrote:
> On 8/26/11 7:07 AM, "Alexander Graf" wrote:
> > Forget the KVM case for a moment and think of a user space device driver. I
> > as
> > a user am not root. But I as a user when having access to /dev/vfioX want to
> > be able to access the device and man
* Aaron Fabbri (aafab...@cisco.com) wrote:
> On 8/26/11 12:35 PM, "Chris Wright" wrote:
> > * Aaron Fabbri (aafab...@cisco.com) wrote:
> >> Each process will open vfio devices on the fly, and they need to be able to
> >> share IOMMU resources.
> >
>
* Avi Kivity (a...@redhat.com) wrote:
> I would like to carry out an online code review of the memory API so that
> more people are familiar with the internals, and perhaps even to catch some
> bugs or deficiency. I'd like to use the next kvm conference call slot for
> this (Tuesday 1400 UTC) sinc
* Sagar Borikar (sagar.bori...@gmail.com) wrote:
> Sorry if I am not keeping up on the subject but wanted to know whether
> there is any effort going on for inter VM communication / PF-VF
> communication (in case of SR-IOV)
> I see that most of SR-IOV capable NIC supports mailboxes for that
> purpo
* Patrick Ringl (patri...@freenet.de) wrote:
> Hi,
>
> I just wanted to introduce a problem I currently face including some
> questions regarding my temporary fix.
> Anyway, I have a PCI-device that I want to passthrough to a hvm
> guest. Now there are several problems that add up:
>
> a) the PCI
t; PCIe Cap struct version is 0, which now fails device assignment
> due to the else fallout, where before, it would blissfully work.
>
> Add a quirk if version=0, & intel-82599, set size to version 2 struct.
>
> Signed-off-by: Donald_Dutile
(not pretty, but neither i
* Reeted (ree...@shiftmail.org) wrote:
> On 09/28/11 11:28, Daniel P. Berrange wrote:
> >On Wed, Sep 28, 2011 at 11:19:43AM +0200, Reeted wrote:
> >>On 09/28/11 09:51, Daniel P. Berrange wrote:
> >>>You could have equivalently used
> >>>
> >>> -netdev tap,ifname=tap0,script=no,downscript=no,id=hos
* Ren, Yongjie (yongjie@intel.com) wrote:
> I'm using kvm and qemu upstream on https://github.com/avikivity
> The following command line was right for me about three weeks ago, but now I
> meet some error.
> # qemu-system-x86_64 -m 1024 -smp 2 -device pci-assign,host=0e:00.0 -hda
> /root/rhel
* Ren, Yongjie (yongjie@intel.com) wrote:
> Chris,
> Thanks very much for you kind help.
> I can't find hw/device-assignment.c in the qemu.git tree.
> Avi,
> I clone qemu from git://github.com/avikivity/qemu.git
> So device assignment is not available. But qemu-kvm.git has device-assignment
* Chris Wright (chr...@sous-sol.org) wrote:
> * Ren, Yongjie (yongjie@intel.com) wrote:
> > Chris,
> > Thanks very much for you kind help.
> > I can't find hw/device-assignment.c in the qemu.git tree.
> > Avi,
> > I clone qemu from git://github.com/avikiv
* Reeted (ree...@shiftmail.org) wrote:
> On 09/29/11 02:39, Chris Wright wrote:
> >Can you help narrow down what is happening during the additional 12
> >seconds in the guest? For example, does a quick simple boot to single
> >user mode happen at the same boot speed w
This feature hasn't been in use for some years now. The host side bits
are deprecated for almost a year. The guest side would only get used
on old hosts, and it's slower than shadow or hw assisted paging.
Time to remove it.
Documentation/feature-removal-schedule.txt |9 --
arch/x86/include
This has not been used for some years now. It's time to remove it.
Will also make some pv patching improvements easier.
Signed-off-by: Chris Wright
---
arch/x86/kernel/kvm.c | 181 -
1 files changed, 0 insertions(+), 181 deletions(-)
diff
The host side pv mmu support has been marked for feature removal in
January 2011. It's not in use, is slower than shadow or hardware
assisted paging, and a maintenance burden. It's October 2011, time to
remove it.
Signed-off-by: Chris Wright
---
Documentation/feature-removal-sc
This feature hasn't been in use for some years now. The host side bits
are deprecated for almost a year. The guest side would only get used
on old hosts, and it's slower than shadow or hw assisted paging.
Time to remove it.
Chris Wright (2):
KVM Guest: remove KVM guest pv m
This has not been used for some years now. It's time to remove it.
Signed-off-by: Chris Wright
---
- v2 rebase to b796a09c
arch/x86/kernel/kvm.c | 181 -
1 files changed, 0 insertions(+), 181 deletions(-)
diff --git a/arch/x86/kernel/kv
The host side pv mmu support has been marked for feature removal in
January 2011. It's not in use, is slower than shadow or hardware
assisted paging, and a maintenance burden. It's November 2011, time to
remove it.
Signed-off-by: Chris Wright
---
- v2 rebase to b796a09c
Doc
* Alexander Graf (ag...@suse.de) wrote:
> On 29.10.2011, at 20:45, Bharata B Rao wrote:
> > As guests become NUMA aware, it becomes important for the guests to
> > have correct NUMA policies when they run on NUMA aware hosts.
> > Currently limited support for NUMA binding is available via libvirt
>
* Avi Kivity (a...@redhat.com) wrote:
> On 11/20/2011 04:58 PM, Sasha Levin wrote:
> > Hi all,
> >
> > I've been working on adding device assignment to KVM tools, and started
> > with the basics of just getting a device assigned using the
> > KVM_ASSIGN_PCI_DEVICE ioctl.
> >
> > What I've figured i
* Peter Zijlstra (a.p.zijls...@chello.nl) wrote:
> On Mon, 2011-11-21 at 21:30 +0530, Bharata B Rao wrote:
> >
> > In the original post of this mail thread, I proposed a way to export
> > guest RAM ranges (Guest Physical Address-GPA) and their corresponding host
> > host virtual mappings (Host Vir
Please send in any agenda items you are interested in covering.
thanks,
-chris
--
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
* Chris Wright (chr...@redhat.com) wrote:
> Please send in any agenda items you are interested in covering.
No agenda, this week's call is cancelled.
thanks,
-chris
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vg
Please send in any agenda items you are interested in covering.
thanks,
-chris
--
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 upstream merge: status, plans, coordination
- Jan has a git tree, consolidating
- qemu-kvm io threading is still an issue
- Anthony wants to just merge
- concerns with non-x86 arch and merge
- concerns with big-bang patch merge and following stability
- post 0.14 conversion to glib mainloop
Please send in any agenda items you are interested in covering.
thanks,
-chris
--
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
Automated builds and testing
- found broken 32-bit
- luiz suggested running against maintainer trees
- daniel gollub offered to take on maintenance
- integration with kvm-autotest?
- lucas, daniel, stefan...
- testing each git commit is probably overkill and too expensive
- current autotest r
Please send in any agenda items you are interested in covering.
thanks,
-chris
--
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
QAPI and QMP
- Anthony adding a new wiki page to describe all of this
- specified in formal schema using JSON
- includes documenation in javadoc-like syntax
- can generate api (possibly protocol) docs
- documenting each command and expected errors
- creates marshalling functions and C interfa
nt issue opened on latest KVM.
> > >
> > > New issue:
> > > 1. [VT-d] VT-d device passthrough fail to guest
> > > https://bugzilla.kernel.org/show_bug.cgi?id=29232
> > >
>
> Extremely reproducible. Looks like it's a result of this kernel change
* Alex Williamson (alex.william...@redhat.com) wrote:
> I don't know why you're getting -EBUSY for this device, but maybe we can
> start from a clean slate and see if it helps. Here's what I would
> suggest:
I bet this is an AMD IOMMU box. Can we get full dmesg?
--
To unsubscribe from this list:
* James Neave (robo...@gmail.com) wrote:
> Finally, here is the very latest dmesg:
> http://pastebin.com/9HE61K62
OK, this is an AMD IOMMU box.
[0.00] ACPI: IVRS cfcf9830 000E0 (v01 AMD RD890S 00202031
AMD )
It's discovered and enalbed properly:
[0.698992] AMD
0.14 recap
- keeping schedule on wiki was helpful
- changelog was helpful
- testing (could even more emphasis could be improved)
- -rc cycles
- -rc2 and final release just hours
0.15
- tentative date July 1st
- qapi
- qed features
- virtagent?
- depends on whether to terminate in qemu vs exter
* James Neave (robo...@gmail.com) wrote:
> On Tue, Feb 22, 2011 at 1:51 AM, Chris Wright wrote:
> > * James Neave (robo...@gmail.com) wrote:
> >> Does anybody know the debug kernel switches for iommu?
> >
> > Two helpful kernel commandline options are:
> >
* Chigurupati, Chaks (ch...@wichorus.com) wrote:
> If my hardware is VT-d capable and the host is latest linux+kvm with all
> the needed VT-d support but the guest is an older linux (say 2.6.27), will
> I be able to use PCI pass-through to hot-plug a PCI device from one guest
> to another guest? An
* James Neave (robo...@gmail.com) wrote:
> libvirtError: this function is not supported by the connection driver:
> Unable to reset PCI device :00:14.4: no FLR, PM reset or bus reset
> available
Right, libvirt is more restrictive than qemu-kvm (forgot you were using
libvirt here).
> There is
* James Neave (robo...@gmail.com) wrote:
> OK, here's my latest dmesg with amd_iommu_dump and debug with no quiet
> http://pastebin.com/JxEwvqRA
Yeah, that's what I expected:
[0.724403] AMD-Vi: DEV_ALIAS_RANGE devid: 08:00.0 flags:
00 devid_to: 00:14.4
[0.724439] AMD-Vi
* James Neave (robo...@gmail.com) wrote:
> Just out of interest, what kind of mileage would I expect out of
> buying a shiny new PCIe tuner?
Hard to say. One advantage would be if it's using MSI or MSI-X
interrupts.
> Can I pass through PCIe?
Often, yes (still some caveats w.r.t. extended confi
* James Neave (robo...@gmail.com) wrote:
> On Fri, Feb 25, 2011 at 12:06 AM, Chris Wright wrote:
> > * James Neave (robo...@gmail.com) wrote:
> >> OK, here's my latest dmesg with amd_iommu_dump and debug with no quiet
> >> http://pastebin.com/JxEwvqRA
>
* James Neave (robo...@gmail.com) wrote:
> On Fri, Feb 25, 2011 at 11:02 PM, James Neave wrote:
> > On Fri, Feb 25, 2011 at 10:47 PM, James Neave wrote:
> >> On Fri, Feb 25, 2011 at 12:06 AM, Chris Wright wrote:
> >>> * James Neave (robo...@gmail.com) wrote:
>
* James Neave (robo...@gmail.com) wrote:
> HOLY CRAP IT WORKS 8@
Hey, great! ;)
> ...almost...
>
> OK, "clear_emulator_capabilities=0" solved the IRQ problem (which was,
> as it turns out, the rawio problem)
> My VM came up, both the tuners were there and after the firmware
> install I was
* lidong chen (chen.lidong.ker...@gmail.com) wrote:
> guest os could not access the vf assigned ,and print this error message .
> PCI: device :00:06.0 has unknown header type 7f, ignoring.
> PCI: device :00:07.0 has unknown header type 7f, ignoring.
> PCI: device :00:08.0 has unknown he
QAPI merge plans
- should be 100% back compat
- qmp moved over
- hmp moved over
- 1st pass, core infrastructure (includes test framework)
- 2nd pass, command conversion
- 3rd pass, more controversial bits
- adds dependencies: glib and python
- some testing based on kvm-unit-test micro-os instance (
QAPI -- http://wiki.qemu.org/Features/QAPI
- please review!
- Anthony would like to see feedback and plans to commit in a week
(assuming agreement and no major issues in review)
- some concern about the maintainability of code generation
- but still nothing concrete on the list, need to review
* Anthony Liguori (anth...@codemonkey.ws) wrote:
> On 03/15/2011 09:53 AM, Chris Wright wrote:
> > QAPI
> >- c library implementation is critical to have unit tests and test
> > driven development
> > - thread safe?
> > - no shared state, no statics.
&
* Alex Williamson (alex.william...@redhat.com) wrote:
> static void reset_assigned_device(DeviceState *dev)
> {
> -PCIDevice *d = DO_UPCAST(PCIDevice, qdev, dev);
> +PCIDevice *pci_dev = DO_UPCAST(PCIDevice, qdev, dev);
> +AssignedDevice *adev = DO_UPCAST(AssignedDevice, dev, pci_dev)
shoot itself by issuing a function
> reset via sysfs on each system reset.
>
> Signed-off-by: Alex Williamson
Looks good.
Acked-by: Chris Wright
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.o
* Alex Williamson (alex.william...@redhat.com) wrote:
> On Thu, 2011-03-17 at 14:12 -0700, Chris Wright wrote:
> > * Alex Williamson (alex.william...@redhat.com) wrote:
> > > +fd = open(reset_file, O_WRONLY);
> > > +if (fd != -1) {
> > > +
KVM Forum
- save the date is out, cfp will follow later this week
- abstracts due in 6wks, 2wk review period, notifications by end of May
Improving process to scale project
- Trivial patch bot
- Sub-maintainership
Trivial patch monkeys^Wteam
- small/simple patches posted can fall through the crac
* Peter Zijlstra (a.p.zijls...@chello.nl) wrote:
> On Wed, 2011-11-30 at 21:52 +0530, Dipankar Sarma wrote:
> >
> > Also, if at all topology changes due to migration or host kernel decisions,
> > we can make use of something like VPHN (virtual processor home node)
> > capability on Power systems t
* Ben Hutchings (bhutchi...@solarflare.com) wrote:
> On Wed, 2011-11-30 at 09:34 -0800, Greg Rose wrote:
> > On 11/29/2011 9:19 AM, Ben Hutchings wrote:
> > > On Tue, 2011-11-29 at 16:35 +, Ben Hutchings wrote:
> > >>
> > >> Maybe I missed something!
> [...]
> > >> If not, please explain what t
* Ben Hutchings (bhutchi...@solarflare.com) wrote:
> On Wed, 2011-11-30 at 13:04 -0800, Chris Wright wrote:
> > I agree that it's confusing. Couldn't you simplify your ascii art
> > (hopefully removing hw assumptions about receive processing, and
> > completely ig
* Sridhar Samudrala (s...@us.ibm.com) wrote:
> On 11/30/2011 3:00 PM, Chris Wright wrote:
> >physical port
> > |
> >+++
> >| +-+
* Hao, Xudong (xudong@intel.com) wrote:
> @@ -2282,6 +2276,14 @@ static int domain_add_dev_info(struct dmar_domain
> *domain,
> pdev->dev.archdata.iommu = info;
> spin_unlock_irqrestore(&device_domain_lock, flags);
>
> + ret = domain_context_mapping(domain, pdev, translation)
apping()
The patch itself is whitespace damaged and does not apply. Please fix
and feel free to add my:
Acked-by: Chris Wright
--
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.kern
* Chris Wright (chr...@sous-sol.org) wrote:
> * Hao, Xudong (xudong@intel.com) wrote:
> > Yes, Chris, thanks your comments.
> > How about this one?
>
> Yes, it gets the locking right.
Sorry, I missed one other problem on the error path. You need to also
update pdev-&
* Anthony Liguori (anth...@codemonkey.ws) wrote:
> On 02/07/2012 07:18 AM, Avi Kivity wrote:
> >On 02/07/2012 02:51 PM, Anthony Liguori wrote:
> >>On 02/07/2012 06:40 AM, Avi Kivity wrote:
> >>>On 02/07/2012 02:28 PM, Anthony Liguori wrote:
>
> >It's a potential source of exploits
> >(
* Natalia Portillo (clau...@claunia.com) wrote:
> QEMU hosted on Haiku would be interesting.
The fun of Haiku
especially when it is
hosting QEMU
--
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://vg
linux plumbers
- qemu talks, including xen folks efforts to get patches upstream
- considering virtio
- considering seabios
- even some xenner interest
- seabios presentation
- uefi
- still needs CSM support (lot of work) to be the only BIOS
- otherwise need legacy BIOS and UEFI and users
* Hidetoshi Seto (seto.hideto...@jp.fujitsu.com) wrote:
> +/*
> + * Fallback: use utimes() instead of utimensat().
> + * See commit 74bc02b2d2272dc88fb98d43e631eb154717f517 for known problem.
> + */
> +struct timeval tv[2];
> +int i;
> +
> +for (i = 0; i < 2; i++) {
> +
tils.c
> V2:
> - Introduce qemu_utimensat()
>
> Signed-off-by: Hidetoshi Seto
Looks good to me (no strong opinion on the cutils vs oslib-posix that
Jes mentioned).
Acked-by: Chris Wright
--
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
Please send in any agenda items you are interested in covering.
thanks,
-chris
--
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
* Juan Quintela (quint...@redhat.com) wrote:
> Please send in any agenda items you are interested in covering.
usb-ccid
--
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-i
* Anthony Liguori (aligu...@us.ibm.com) wrote:
> qemu-kvm vcpu threads don't response to SIGSTOP/SIGCONT. Instead of teaching
> them to respond to these signals, introduce monitor commands that stop and
> start
> individual vcpus.
In the past SIGSTOP has introduced time skew. Have you verified
* Anthony Liguori (aligu...@linux.vnet.ibm.com) wrote:
> On 11/22/2010 05:04 PM, Chris Wright wrote:
> >* Anthony Liguori (aligu...@us.ibm.com) wrote:
> >>qemu-kvm vcpu threads don't response to SIGSTOP/SIGCONT. Instead of
> >>teaching
> >>them to re
qcow2 performance roadmap
- What can be done to achieve near-raw image format performance?
- some discussion points from Kevin on list
http://lists.nongnu.org/archive/html/qemu-devel/2010-11/msg02126.html
- please follow up on the list
- some perf numbers (latest upstream qcow2 compared wit
2011 KVM Conference
- together with LF event like LinuxCon Vancouver BC (Aug), KS Prague (Nov)
- wider audience
- include qemu (tcg)
- include libvirt
- include xen
0.14.0 release plan
- could push things out, mainly want to keep on track for
infrastructure changes (irc channel migration, g
* Peter Zijlstra (a.p.zijls...@chello.nl) wrote:
> On Wed, 2010-12-01 at 21:42 +0530, Srivatsa Vaddagiri wrote:
>
> > Not if yield() remembers what timeslice was given up and adds that back when
> > thread is finally ready to run. Figure below illustrates this idea:
> >
> >
> > A0/4C0/
* Peter Zijlstra (a.p.zijls...@chello.nl) wrote:
> On Wed, 2010-12-01 at 09:17 -0800, Chris Wright wrote:
> > Directed yield and fairness don't mix well either. You can end up
> > feeding the other tasks more time than you'll ever get back.
>
> If the directed yie
* Anthony Liguori (aligu...@us.ibm.com) wrote:
> In certain use-cases, we want to allocate guests fixed time slices where idle
> guest cycles leave the machine idling. There are many approaches to achieve
> this but the most direct is to simply avoid trapping the HLT instruction which
> lets the g
* Anthony Liguori (anth...@codemonkey.ws) wrote:
> On 12/02/2010 01:14 PM, Chris Wright wrote:
> >* Anthony Liguori (aligu...@us.ibm.com) wrote:
> >>In certain use-cases, we want to allocate guests fixed time slices where
> >>idle
> >>guest cycles leave
* Marcelo Tosatti (mtosa...@redhat.com) wrote:
> On Thu, Dec 02, 2010 at 11:14:16AM -0800, Chris Wright wrote:
> > * Anthony Liguori (aligu...@us.ibm.com) wrote:
> > > In certain use-cases, we want to allocate guests fixed time slices where
> > > idle
> > > g
* Rik van Riel (r...@redhat.com) wrote:
> When running SMP virtual machines, it is possible for one VCPU to be
> spinning on a spinlock, while the VCPU that holds the spinlock is not
> currently running, because the host scheduler preempted it to run
> something else.
>
> Both Intel and AMD CPUs h
* Rik van Riel (r...@redhat.com) wrote:
> Add a yield_to function to the scheduler code, allowing us to
> give the remainder of our timeslice to another thread.
>
> We may want to use this to provide a sys_yield_to system call
> one day.
>
> Signed-off-by: Rik van Riel
> Signed-off-by: Marcelo T
* Rik van Riel (r...@redhat.com) wrote:
> Keep track of which task is running a KVM vcpu. This helps us
> figure out later what task to wake up if we want to boost a
> vcpu that got preempted.
>
> Unfortunately there are no guarantees that the same task
> always keeps the same vcpu, so we can onl
* Rik van Riel (r...@redhat.com) wrote:
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -1880,18 +1880,53 @@ void kvm_resched(struct kvm_vcpu *vcpu)
> }
> EXPORT_SYMBOL_GPL(kvm_resched);
>
> -void kvm_vcpu_on_spin(struct kvm_vcpu *vcpu)
> +void kvm_vcpu_on_spin(struct kvm_vcpu *me)
* Anthony Liguori (anth...@codemonkey.ws) wrote:
> On 12/02/2010 03:07 PM, Chris Wright wrote:
> >Like non-trapping hlt, that too will guarantee that the guest is preempted
> >by timeslice exhaustion (and is simpler than non-trapping hlt). So it
> >may well be the simplest
* Anthony Liguori (anth...@codemonkey.ws) wrote:
> On 12/02/2010 08:42 PM, Chris Wright wrote:
> >OK, let's say a single PCPU == 12 Compute Units.
> >
> >If the guest is the first to migrate to a newly added unused host, and
> >we are using either non-trappi
* Rik van Riel (r...@redhat.com) wrote:
> On 12/02/2010 08:18 PM, Chris Wright wrote:
> >* Rik van Riel (r...@redhat.com) wrote:
> >>Keep track of which task is running a KVM vcpu. This helps us
> >>figure out later what task to wake up if we want to boost a
* Srivatsa Vaddagiri (va...@linux.vnet.ibm.com) wrote:
> On Thu, Dec 02, 2010 at 11:14:16AM -0800, Chris Wright wrote:
> > Perhaps it should be a VM level option. And then invert the notion.
> > Create one idle domain w/out hlt trap. Give that VM a vcpu per pcpu
> > (pin in
* Srivatsa Vaddagiri (va...@linux.vnet.ibm.com) wrote:
> On Fri, Dec 03, 2010 at 05:27:52PM +0530, Srivatsa Vaddagiri wrote:
> > On Thu, Dec 02, 2010 at 11:14:16AM -0800, Chris Wright wrote:
> > > Perhaps it should be a VM level option. And then invert the notion.
> > &g
1 - 100 of 421 matches
Mail list logo