Re: [patch -next] tcm_vhost: another strlen() off by one
On Fri, 2012-07-13 at 13:45 +0300, Dan Carpenter wrote:
> strlen() doesn't count the NUL terminator. I missed this one in the
> patches I sent yesterday.
>
> Signed-off-by: Dan Carpenter
>
> diff --git a/drivers/vhost/tcm_vhost.c b/drivers/vhost/tcm_vhost.c
> index 29850cb..ea72198 100644
> --- a/drivers/vhost/tcm_vhost.c
> +++ b/drivers/vhost/tcm_vhost.c
> @@ -1424,7 +1424,7 @@ static struct se_wwn *tcm_vhost_make_tport(
> return ERR_PTR(-EINVAL);
>
> check_len:
> - if (strlen(name) > TCM_VHOST_NAMELEN) {
> + if (strlen(name) >= TCM_VHOST_NAMELEN) {
> pr_err("Emulated %s Address: %s, exceeds"
> " max: %d\n", name, tcm_vhost_dump_proto_id(tport),
> TCM_VHOST_NAMELEN);
Applied + squashed into the initial merge commit in for-next-merge.
Thanks DanC!
--nab
--
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] x86, amd: rename vmmu support capability
On Sat, Jul 14, 2012 at 04:28:51PM +0200, Davidlohr Bueso wrote: > On Sat, 2012-07-14 at 15:38 +0200, H. Peter Anvin wrote: > > Yep, NAK on this one. > > Ok, we could at least add a comment when defining X86_FEATURE_NPT. And the valid, sane, technical reason for having a comment where any internet search could do, is... ? -- Regards/Gruss, Boris. -- 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] x86, amd: rename vmmu support capability
On Sat, 2012-07-14 at 15:38 +0200, H. Peter Anvin wrote: > Yep, NAK on this one. Ok, we could at least add a comment when defining X86_FEATURE_NPT. Thanks, Davidlohr > > Borislav Petkov wrote: > > >On Fri, Jul 13, 2012 at 08:02:55PM +0200, Davidlohr Bueso wrote: > >> From: Davidlohr Bueso > >> > >> AMD has renamed nested page table technology to rapid virtualization > >indexing, > >> reflect this change in the kernel. > >> > >> Signed-off-by: Davidlohr Bueso > > > >You know that /proc/cpuinfo is a userspace ABI, right? > > > >And are you sure nothing is using that string - > >"npt" - since it got added almost three years ago by > >414bb144efa2d2fe16d104d836d0d6b6e9265788? > > > >-- > >Regards/Gruss, > >Boris. > -- 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] x86, amd: rename vmmu support capability
Yep, NAK on this one. Borislav Petkov wrote: >On Fri, Jul 13, 2012 at 08:02:55PM +0200, Davidlohr Bueso wrote: >> From: Davidlohr Bueso >> >> AMD has renamed nested page table technology to rapid virtualization >indexing, >> reflect this change in the kernel. >> >> Signed-off-by: Davidlohr Bueso > >You know that /proc/cpuinfo is a userspace ABI, right? > >And are you sure nothing is using that string - >"npt" - since it got added almost three years ago by >414bb144efa2d2fe16d104d836d0d6b6e9265788? > >-- >Regards/Gruss, >Boris. -- Sent from my mobile phone. Please excuse brevity and lack of formatting. -- 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] x86, amd: rename vmmu support capability
On Sat, 2012-07-14 at 12:19 +0200, Borislav Petkov wrote: > On Fri, Jul 13, 2012 at 08:02:55PM +0200, Davidlohr Bueso wrote: > > From: Davidlohr Bueso > > > > AMD has renamed nested page table technology to rapid virtualization > > indexing, > > reflect this change in the kernel. > > > > Signed-off-by: Davidlohr Bueso > > You know that /proc/cpuinfo is a userspace ABI, right? Yes. > > And are you sure nothing is using that string - > "npt" - since it got added almost three years ago by > 414bb144efa2d2fe16d104d836d0d6b6e9265788? AFAIK no, it's not being used - that doesn't mean, of course, that there are no users. Thanks, Davidlohr -- 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] KVM fixes for 3.5-rc6
On 2012-07-14 14:33, Thomas Gleixner wrote: > On Sat, 14 Jul 2012, Jan Kiszka wrote: >> On 2012-07-14 13:16, Thomas Gleixner wrote: >>> On Sat, 14 Jul 2012, Jan Kiszka wrote: On 2012-07-14 04:25, Thomas Gleixner wrote: This patch here is a workaround to unbreak devices assignment in 3.5 after the IRQ layer changes without regressing noticeable /wrt overhead. >>> >>> Yeah, workaround and regression are the proper marketing buzzwords to >>> excuse mindless hackery. >>> >>> It took me a minute to figure out that there is no reason at all to >>> use a threaded interrupt handler for MSI and MSIX. >> >> Thomas, we also explained to you in the cited thread that your simple >> approach for this doesn't work as is. We will have a proper solution >> soon, but it takes a bit more than a minute - at least us. > > And I explained to you in that very thread that the proper solution to > avoid the "overhead" of finalize_oneshot is exaclty the patch I sent > to Linus yesterday: > >> The only way we can avoid that, is that we get a hint from the >> underlying irq chip/ handler setup with an extra flag to tell the >> core, that it's safe to avoid the ONESHOT/finalize magic. > > So now it took a full month of ignorance to come up with the > mindboggling solution of working around the core change with a private > hack instead of sitting down and doing what was said to be the correct > solution. We sat down and tried to avoid the core problem of our use case: IRQ threading. That we now have to fall back to something else is unfortunate and was surely not planned. However, if you push your patch for 3.5, I'm sure Avi will happily drop the disliked workaround and replace it with ordinary IRQF_ONESHOT tagging. Jan signature.asc Description: OpenPGP digital signature
Re: [GIT PULL] KVM fixes for 3.5-rc6
On Sat, 14 Jul 2012, Jan Kiszka wrote: > On 2012-07-14 13:16, Thomas Gleixner wrote: > > On Sat, 14 Jul 2012, Jan Kiszka wrote: > >> On 2012-07-14 04:25, Thomas Gleixner wrote: > >> This patch here is a workaround to unbreak devices assignment in 3.5 > >> after the IRQ layer changes without regressing noticeable /wrt overhead. > > > > Yeah, workaround and regression are the proper marketing buzzwords to > > excuse mindless hackery. > > > > It took me a minute to figure out that there is no reason at all to > > use a threaded interrupt handler for MSI and MSIX. > > Thomas, we also explained to you in the cited thread that your simple > approach for this doesn't work as is. We will have a proper solution > soon, but it takes a bit more than a minute - at least us. And I explained to you in that very thread that the proper solution to avoid the "overhead" of finalize_oneshot is exaclty the patch I sent to Linus yesterday: > The only way we can avoid that, is that we get a hint from the > underlying irq chip/ handler setup with an extra flag to tell the > core, that it's safe to avoid the ONESHOT/finalize magic. So now it took a full month of ignorance to come up with the mindboggling solution of working around the core change with a private hack instead of sitting down and doing what was said to be the correct solution. And that's what seriously annoys me. Instead of doing it yourself or at least politely poking me to get it done, stuff just gets hacked into submission and sold as the "performance regression" saviour. Of course you are free to ignore my advice, but that does not mean that I take bullshit from you. Thanks, tglx -- 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] KVM fixes for 3.5-rc6
On 2012-07-14 13:16, Thomas Gleixner wrote: > On Sat, 14 Jul 2012, Jan Kiszka wrote: >> On 2012-07-14 04:25, Thomas Gleixner wrote: >> This patch here is a workaround to unbreak devices assignment in 3.5 >> after the IRQ layer changes without regressing noticeable /wrt overhead. > > Yeah, workaround and regression are the proper marketing buzzwords to > excuse mindless hackery. > > It took me a minute to figure out that there is no reason at all to > use a threaded interrupt handler for MSI and MSIX. Thomas, we also explained to you in the cited thread that your simple approach for this doesn't work as is. We will have a proper solution soon, but it takes a bit more than a minute - at least us. Jan signature.asc Description: OpenPGP digital signature
Re: [GIT PULL] KVM fixes for 3.5-rc6
On Sat, 14 Jul 2012, Jan Kiszka wrote:
> On 2012-07-14 04:25, Thomas Gleixner wrote:
> This patch here is a workaround to unbreak devices assignment in 3.5
> after the IRQ layer changes without regressing noticeable /wrt overhead.
Yeah, workaround and regression are the proper marketing buzzwords to
excuse mindless hackery.
It took me a minute to figure out that there is no reason at all to
use a threaded interrupt handler for MSI and MSIX.
If you folks are so concerned about performance and overhead then
someone familiar with that code should have done the obvious change
long before the oneshot modifications took place.
I can't be bothered to do a performance test myself, but I bet it's
making an order of magnitude more of a difference than the "oh so
noticeable" few cycles in irq_finalize_oneshot().
Thanks,
tglx
Index: linux-2.6/virt/kvm/assigned-dev.c
===
--- linux-2.6.orig/virt/kvm/assigned-dev.c
+++ linux-2.6/virt/kvm/assigned-dev.c
@@ -105,7 +105,7 @@ static irqreturn_t kvm_assigned_dev_thre
}
#ifdef __KVM_HAVE_MSI
-static irqreturn_t kvm_assigned_dev_thread_msi(int irq, void *dev_id)
+static irqreturn_t kvm_assigned_dev_msi_handler(int irq, void *dev_id)
{
struct kvm_assigned_dev_kernel *assigned_dev = dev_id;
@@ -117,7 +117,7 @@ static irqreturn_t kvm_assigned_dev_thre
#endif
#ifdef __KVM_HAVE_MSIX
-static irqreturn_t kvm_assigned_dev_thread_msix(int irq, void *dev_id)
+static irqreturn_t kvm_assigned_dev_msix_handler(int irq, void *dev_id)
{
struct kvm_assigned_dev_kernel *assigned_dev = dev_id;
int index = find_index_from_host_irq(assigned_dev, irq);
@@ -334,11 +334,6 @@ static int assigned_device_enable_host_i
}
#ifdef __KVM_HAVE_MSI
-static irqreturn_t kvm_assigned_dev_msi(int irq, void *dev_id)
-{
- return IRQ_WAKE_THREAD;
-}
-
static int assigned_device_enable_host_msi(struct kvm *kvm,
struct kvm_assigned_dev_kernel *dev)
{
@@ -351,9 +346,8 @@ static int assigned_device_enable_host_m
}
dev->host_irq = dev->dev->irq;
- if (request_threaded_irq(dev->host_irq, kvm_assigned_dev_msi,
-kvm_assigned_dev_thread_msi, 0,
-dev->irq_name, dev)) {
+ if (request_irq(dev->host_irq, kvm_assigned_dev_msi_handler, 0,
+ dev->irq_name, dev)) {
pci_disable_msi(dev->dev);
return -EIO;
}
@@ -363,11 +357,6 @@ static int assigned_device_enable_host_m
#endif
#ifdef __KVM_HAVE_MSIX
-static irqreturn_t kvm_assigned_dev_msix(int irq, void *dev_id)
-{
- return IRQ_WAKE_THREAD;
-}
-
static int assigned_device_enable_host_msix(struct kvm *kvm,
struct kvm_assigned_dev_kernel *dev)
{
@@ -383,10 +372,9 @@ static int assigned_device_enable_host_m
return r;
for (i = 0; i < dev->entries_nr; i++) {
- r = request_threaded_irq(dev->host_msix_entries[i].vector,
-kvm_assigned_dev_msix,
-kvm_assigned_dev_thread_msix,
-0, dev->irq_name, dev);
+ r = request_irq(dev->host_msix_entries[i].vector,
+ kvm_assigned_dev_msix_handler,
+ 0, dev->irq_name, dev);
if (r)
goto err;
}
--
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
Single-stepping real-mode does not work
(please CC, since I'm not subscribed) Hi, trying to debug some BIOS code, but single-stepping through real-mode doesn't work. It always continues, instead of breaking after the next instruction. So I wanted to know, if there are known issues, or if this is supposed to work. CPU: AMD FX QEMU: latest from git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git Linux: latest from git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git I start QEMU with `qemu-system-x86_64 -S -s', connect gdb and use the `stepi' command. But instead of executing one instruction and breaking, it just continues the programme. If I start QEMU with `-no-kvm', it works. So the problem seems to be in the kvm module. Cheers, harry -- 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] x86, amd: rename vmmu support capability
On Fri, Jul 13, 2012 at 08:02:55PM +0200, Davidlohr Bueso wrote: > From: Davidlohr Bueso > > AMD has renamed nested page table technology to rapid virtualization indexing, > reflect this change in the kernel. > > Signed-off-by: Davidlohr Bueso You know that /proc/cpuinfo is a userspace ABI, right? And are you sure nothing is using that string - "npt" - since it got added almost three years ago by 414bb144efa2d2fe16d104d836d0d6b6e9265788? -- Regards/Gruss, Boris. -- 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] [RFC PATCH v2 00/21] ACPI memory hotplug
On Fri, Jul 13, 2012 at 5:49 PM, Vasilis Liaskovitis wrote: > On Thu, Jul 12, 2012 at 08:04:56PM +, Blue Swirl wrote: >> On Wed, Jul 11, 2012 at 10:31 AM, Vasilis Liaskovitis >> wrote: >> > This is v2 of the ACPI memory hotplug prototype for x86_64 target. >> >> I think the concept of DIMMs (what about SIMMs? SODIMMs? I liked >> memslot) would be useful for most targets, but hotplugging may be >> limited to x86 only. It would be nice to keep these two separate or as >> loosely coupled as possible. > > agreed. > what specific usecases besides hotplugging are you thinking about? Most real boards have some kind of RAM module slots. Now this is implemented with -m option, but a generic memory slot model would be more accurate. Also the memory layout needs to be communicated to BIOS somehow unless we want to spend cycles for BIOS memory probes. The NUMA fw_cfg memory description should be usable for most cases even for embedded UP machines. > Also are there non-acpi hotplug platforms? Some enterprise-class Sparc and PPC machines support memory hotplug. > > I am trying to keep generic dimm manipulation functions (e.g. population / > depopulation and searching) in hw/dimm[.ch]. Currently the x86-acpi_piix4 > "backend" > registers a callback for hot-add / hot-remove. In theory other hotplug > backends > can hook in. > > btw I don't mind using "-memslot" (I think someone during v1 mentioned > -dimm), we just > need some consensus on the naming. > >> >> > >> > Changes v1->v2 >> > >> > - memory map is automatically calculated for hotplug dimms. Dimms are >> > added from >> > top-of-memory skipping the pci hole at [PCI_HOLE_START, 4G). >> > - Renamed from "-memslot" to "-dimm". Commands changed to "dimm_add", >> > "dimm_del". >> > - Seabios ejection array reduced to a byte. Use extraction macros for dimm >> > ssdt. >> > - additional SRAT paravirt info does not break previous SRAT fw_cfg layout. >> > - Documentation of new acpi_piix4 registers and paravirt data. >> > - add ACPI _OST support for _OST enabled guests. This allows qemu to >> > receive >> > notification for success / failure of memory hot-add and hot-remove >> > operations. >> > Guest needs to support _OST (https://lkml.org/lkml/2012/6/25/321) >> > - add monitor info command to report total guest memory (initial + >> > hot-added) >> > - add command line options and monitor commands for batch dimm >> > creation/population >> > >> > Overview: >> > >> > Dimm devices are modeled with a new qemu command line >> > >> > "-dimm id=name,size=sz,node=pxm,populated=on|off" >> > >> > As already mentioned, the starting physical address for all dimms is >> > calculated >> > automatically from top of memory, skipping the pci hole at >> > [PCI_HOLE_START, 4G). >> > Node is defining numa proximity for this dimm. When not defined it defaults >> > to zero. >> > "-dimm id=dimm0,size=512M,node=0,populated=off" >> > will define a 512M memory slot belonging to numa node 0. >> > >> > Dimms are added or removed with a new hmp command "dimm_add/dimm_del": >> > Hot-add syntax: "dimm_add id" >> > Hot-remove syntax: "dimm_del id" >> > >> > Issues: >> > >> > - Live migration works as long as populated field is changed to "on" for >> > hotplugged dimms at the destination qemu command line (patch 12/21 lifts >> > this requirement). The DimmState structure does not yet define a >> > VMStateDescription, but i assume this is the preferred way to pass state >> > for migration. >> > >> > - Dimms are abstracted as qdevices attached to the main system bus. >> > However, >> > memory hotplugging has its own side channel ignoring main_system_bus's >> > hotplug >> > incapability. A cleaner integration is still needed, probably attaching >> > memory >> > devices as children-links of an acpi-capable device (in the pc case >> > acpi_piix4) >> > instead of the system bus (TBD). Then device_add/device_del instead of new >> > commands can hopefully be used. >> > >> > Comments/review welcome. >> > >> > series is based on uq/master for qemu-kvm, and master for seabios. Can be >> > found >> > also at: >> > http://github.com/vliaskov/qemu-kvm/commits/memhp-v2 >> > http://github.com/vliaskov/seabios/commits/memhp-v2 >> > >> > Vasilis Liaskovitis (14): >> > dimm: Implement memory device abstraction >> > acpi_piix4: Implement memory device hotplug registers >> > pc: calculate dimm physical addresses and adjust memory map >> > pc: Add dimm paravirt SRAT info >> > Implement "-dimm" command line option >> > Implement dimm_add and dimm_del commands for hmp and qmp >> > fix live-migration when "populated=on" is missing >> > Implement memory hotplug notification lists >> > acpi_piix4: _OST dimm support >> > acpi_piix4: Update dimm state on VM reboot >> > acpi_piix4: Update dimm bitmap state on hot-remove fail >> > Implement "info memtotal" and "query-memtotal" >> > Implement -dimms, -dimmspop command line options >> > Implement mem_increase, mem_decrease hmp/qmp c
Re: [PATCH RESEND 0/5] Add vhost-blk support
Please send a version that does direct block I/O similar to xen-blkback for now. If we get proper in-kernel aio support one day you can add back file backend support. -- 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] KVM fixes for 3.5-rc6
On 2012-07-14 04:25, Thomas Gleixner wrote:
> On Fri, 13 Jul 2012, Thomas Gleixner wrote:
>> On Fri, 13 Jul 2012, Linus Torvalds wrote:
>>> On Fri, Jul 13, 2012 at 8:45 AM, Linus Torvalds
>>> wrote:
>>> At the same time, I do wonder if maybe MSI + IRQF_ONESHOT couldn't be
>>> improved. The fact that the KVM people think that the extra overhead
>>> of IRQF_ONESHOT is a bad thing for MSI interrupts makes me wonder if
>>> maybe this wouldn't be an area the irq layer couldn't be improved on.
>>> Maybe the MSI+IRQF_ONESHOT case could be improved. Because MSI is kind
>>> of fundamentally one-shot, since it's a message-based irq scheme. So
>>> maybe the extra overhead is unnecessary in general, not just in this
>>> particular KVM case. Hmm?
>>>
>>> Thomas, see the commentary of a76beb14123a ("KVM: Fix device
>>> assignment threaded irq handler").
>>
>> Groan.
>>
>> We already discussed to let the irq chip (in this case MSI) tell the
>> core that it does not need the extra oneshot handling. That way the
>> code which requests an threaded irq with the NULL primary handler
>> works on both MSI and normal interrupts.
>
> That's the kind of stuff which makes me go berserk, and just for the
> record: the most complaints I get for going berserk are coming from
> the virt folks.
>
> I really can't understand why the virt folks think they are
> special and do not have to talk to core maintainers.
>
> Back then when I was doing the big irq cleanup, virt crap stood out by
> far with the most idiotic^Wcreative "workarounds". Of course nobody
> complained about me being moronic enough to come up with generic
> solutions for their problems.
>
> Though especially that commit including its changelog proves once
> again the ignorance and desinterest of the virt crowd in solving
> problems which are not only relevant to themself.
>
> I whish you'd just refused to pull that nonsense and instead made them
> talk to those folks who had a proper solution in mind already.
>
> In fact we could have solved that proper weeks ago, if only people
> would have raised the issue.
June 1: http://thread.gmane.org/gmane.linux.kernel/1306742
The proper solution for us will be conditional direct IRQ delivery
anyway [1], but those patches were not considered ready for 3.5.
This patch here is a workaround to unbreak devices assignment in 3.5
after the IRQ layer changes without regressing noticeable /wrt overhead.
Jan
[1] http://thread.gmane.org/gmane.comp.emulators.kvm.devel/92249
signature.asc
Description: OpenPGP digital signature
