Signed-off-by: Alex Williamson <alex.williamson@redhat.com> --- hw/pci.h | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/hw/pci.h b/hw/pci.h index 34955d8..7c52637 100644 --- a/hw/pci.h +++ b/hw/pci.h @@ -124,8 +124,8 @@ enum { #define PCI_CAPABILITY_CONFIG_MAX_LENGTH 0x60 #define PCI_CAPABILITY_CONFIG_DEFAULT_START_ADDR 0x40 -#define PCI_CAPABILITY_CONFIG_MSI_LENGTH 0x10 -#define PCI_CAPABILITY_CONFIG_MSIX_LENGTH 0x10 +#define ...

Signed-off-by: Alex Williamson <alex.williamson@redhat.com> --- hw/device-assignment.c | 14 +++++++++----- 1 files changed, 9 insertions(+), 5 deletions(-) diff --git a/hw/device-assignment.c b/hw/device-assignment.c index 6d6e657..838bf89 100644 --- a/hw/device-assignment.c +++ b/hw/device-assignment.c @@ -1288,7 +1288,7 @@ static int assigned_device_pci_cap_init(PCIDevice *pci_dev) { AssignedDevice *dev = container_of(pci_dev, AssignedDevice, dev); PCIRegion *pci_region = ...

Include the first byte at 40h or else access might go to the hardware instead of the emulated config space, resulting in capability loops, since the ordering is different. Signed-off-by: Alex Williamson <alex.williamson@redhat.com> --- hw/device-assignment.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/hw/device-assignment.c b/hw/device-assignment.c index 832c236..6d6e657 100644 --- a/hw/device-assignment.c +++ b/hw/device-assignment.c @@ -410,7 +410,7 @@ ...

Catch new exception from kvm_suprocess to avoid killing of tests. --- client/tests/kvm/tests/virtio_console.py | 10 +++++++--- 1 files changed, 7 insertions(+), 3 deletions(-) diff --git a/client/tests/kvm/tests/virtio_console.py b/client/tests/kvm/tests/virtio_console.py index d8d2143..d083783 100644 --- a/client/tests/kvm/tests/virtio_console.py +++ b/client/tests/kvm/tests/virtio_console.py @@ -468,9 +468,13 @@ def run_virtio_console(test, params, env): ...

Usually nobody usually thinks about that scenario (me included and specially), but kvmclock can be actually disabled in the host. It happens in two scenarios: 1. host too old. 2. we passed -kvmclock to our -cpu parameter. In both cases, we should not register kvmclock savevm section. This patch achives that by registering this section only if kvmclock is actually currently enabled in cpuid. The only caveat is that we have to register the savevm section a little bit later, since we won't ...

With the new Async PF code, some of our initiation code was moved to kvm.c. With that, code that was being issued conditional to kvmclock successful registration (primary cpu registering), started being issued unconditionally. This patch proposes that we protect all registrations inside kvm_register_clock, re-using the kvmclock-enabled parameter for that. This fixes this specific bug, and should protect us from similar changes in the future. Signed-off-by: Glauber Costa ...

Caused by qemu tightening up -kernel. Easily fixed by using objcopy, I'll post a patch soon. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. --

Heh, was just about to say the same thing ;) --

What's the difference between this and the Linux idle threads? -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. --

If we have 3 VMs and want to give them 25% each of a CPU, then having just idle thread would end up giving them 33%. One way of achieving 25% rate limit is to create a "dummy" or "filler" VM, and let it compete for resource, thus rate-limiting everyone to 25% in this case. Essentially we are tackling rate-limit problem by creating additional "filler" VMs/threads that will compete for resource, thus keeping in check how much cpu resource is consumed by "real" VMs. Admittedly not as neat as having ...

and at idle/non-idle time as well, which makes the mgmt entity's job rather harder? Anyway, if we are willing to take a patch to burn cycles upon halt (as per Marcello's patch), that's be the best (short-term) solution ..otherwise, something like a filler-thread per-vcpu is more easier than dynamic change of priorities .. - vatsa --

Well, no. Better to consume hlt time but yield if need_resched or in case of any event which breaks out of kvm_vcpu_block. --

There's one complication though even with that. How do we compute the real utilization of VM (given that it will appear to be burning 100% cycles)? We need to have scheduler discount the cycles burnt post halt-exit, so more stuff is needed than those simple 3-4 lines! - vatsa --

Are we willing to add that to KVM sources? I was working under the constraints of not modifying the kernel (especially avoid adding short term hacks that become unnecessary in longer run, in this case when kernel-based hard limits goes in). - vatsa --

Some monitoring tool will need to catch that event and spawn a "dummy" VM to consume 25% cpu, bringing back everyone's use to 25% as before. That's admittedly not neat, but that's what we are thinking of atm in absence of a better solution to the problem (ex: kernel scheduler supporting hard-limits). - vatsa --

My first reaction is that it's not terribly important to account the non-idle time in the guest because of the use-case for this model. Eventually, it might be nice to have idle time accounting but I don't see it as a critical feature here. Non-idle time simply isn't as meaningful here as it normally would be. If you have 10 VMs in a normal environment and saw that you had only 50% CPU utilization, you might be inclined to add more VMs. But if you're offering deterministic execution, ...

Depends on the chargeback model. This would put guest vcpu runtime vs host running guest vcpu time really out of skew. ('course w/out steal and that time it's already out of skew). But I think most models are Who is "you"? cloud user, or cloud service provider's scheduler? On the user side, 50% cpu utilization wouldn't trigger me to add new VMs. On the host side, 50% cpu utilization would have to be measure Sorry, didn't follow here? thanks, -chris --

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-trapping hlt or Marcelo's non-yielding trapping hlt, then that guest is going to get more CPU than it expected unless there is some throttling mechanism. Specifically, it will get 12CU instead of 1-3CU. Do you agree with that? thanks, -chris --

Async PF completion do not kick vcpu out of a guest mode. It wakes vcpu only if it is waiting on waitqueue. It was done to not generate -- Gleb. --

Probably yes. The point is, you get the same effect as with the non-trapping hlt but without the complications on low-level VMX/SVM code. Even better if you can do it with fill thread idea. --

I think we can calculate or prepare an internal last_avail_idx, and update the external when inuse is decremented. I'll try Although we try flushing requests one by one making inuse 0, there are cases when it failovers to the secondary when inuse isn't 0. We handle these in flight request on the primary by In case of Kemari, no. We sit between devices and net/block, and queue the requests. After completing each transaction, we flush the requests one by one. So there won't be completion ...

I already posted here code that maps PCI rom to PCI device path. Why do If you propose that then you probably misunderstand the problem I am trying to tackle. Qemu should be able to specify boot order for newly created machine with arbitrary HW configuration without making user to look at F12 menu. Actually at this point there is not human user at all. All the process from machine creation till OS installation is completely unattended. Looking at the BBS spec in several places they say that if NV ...

Is there any reason why this patch is not yet in the stable kernel? virtio_net is still crashing under heavy load in current vanilla kernel. --