[kvm-devel] [PATCH] QEMU support for virtio balloon driver
This patch adds support to QEMU for Rusty's recently introduce virtio balloon
driver. The user-facing portions of this are the introduction of a "balloon"
and "info balloon" command in the monitor.
Right now madvise() is commented out since it causes host panics. Ballooning
is still functional though--the host just doesn't reclaim the memory
immediately.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/qemu/Makefile.target b/qemu/Makefile.target
index d0cde54..c0205d7 100644
--- a/qemu/Makefile.target
+++ b/qemu/Makefile.target
@@ -574,7 +574,7 @@ OBJS += e1000.o
OBJS+= hypercall.o
# virtio devices
-OBJS += virtio.o virtio-net.o virtio-blk.o
+OBJS += virtio.o virtio-net.o virtio-blk.o virtio-balloon.o
ifeq ($(TARGET_BASE_ARCH), i386)
# Hardware support
diff --git a/qemu/hw/pc.c b/qemu/hw/pc.c
index ef180ec..9cba6fc 100644
--- a/qemu/hw/pc.c
+++ b/qemu/hw/pc.c
@@ -1113,6 +1113,9 @@ static void pc_init1(ram_addr_t ram_size, int
vga_ram_size,
}
}
+if (pci_enabled)
+ virtio_balloon_init(pci_bus, 0x1AF4, 0x1002);
+
if (extboot_drive != -1) {
DriveInfo *info = &drives_table[extboot_drive];
int cyls, heads, secs;
diff --git a/qemu/hw/pc.h b/qemu/hw/pc.h
index d109569..706881b 100644
--- a/qemu/hw/pc.h
+++ b/qemu/hw/pc.h
@@ -152,6 +152,9 @@ void virtio_net_poll(void);
void *virtio_blk_init(PCIBus *bus, uint16_t vendor, uint16_t device,
BlockDriverState *bs);
+/* virtio-balloon.h */
+void *virtio_balloon_init(PCIBus *bus, uint16_t vendor, uint16_t device);
+
/* extboot.c */
void extboot_init(BlockDriverState *bs, int cmd);
diff --git a/qemu/hw/virtio-balloon.c b/qemu/hw/virtio-balloon.c
new file mode 100644
index 000..d7b61d0
--- /dev/null
+++ b/qemu/hw/virtio-balloon.c
@@ -0,0 +1,145 @@
+/*
+ * Virtio Block Device
+ *
+ * Copyright IBM, Corp. 2008
+ *
+ * Authors:
+ * Anthony Liguori <[EMAIL PROTECTED]>
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2. See
+ * the COPYING file in the top-level directory.
+ *
+ */
+
+#include "virtio.h"
+#include "block.h"
+#include "pc.h"
+#include "balloon.h"
+#include "sysemu.h"
+
+#include
+
+/* from Linux's linux/virtio_blk.h */
+
+/* The ID for virtio_balloon */
+#define VIRTIO_ID_BALLOON 5
+
+/* The feature bitmap for virtio balloon */
+#define VIRTIO_BALLOON_F_MUST_TELL_HOST0 /* Tell before reclaiming
pages */
+
+struct virtio_balloon_config
+{
+/* Number of pages host wants Guest to give up. */
+uint32_t num_pages;
+/* Number of pages we've actually got in balloon. */
+uint32_t actual;
+};
+
+typedef struct VirtIOBalloon
+{
+VirtIODevice vdev;
+VirtQueue *ivq, *dvq;
+uint32_t num_pages;
+uint32_t actual;
+} VirtIOBalloon;
+
+static VirtIOBalloon *to_virtio_balloon(VirtIODevice *vdev)
+{
+return (VirtIOBalloon *)vdev;
+}
+
+static void virtio_balloon_handle_output(VirtIODevice *vdev, VirtQueue *vq)
+{
+VirtIOBalloon *s = to_virtio_balloon(vdev);
+VirtQueueElement elem;
+unsigned int count;
+
+while ((count = virtqueue_pop(vq, &elem)) != 0) {
+ int i;
+ unsigned int wlen = 0;
+
+ for (i = 0; i < elem.out_num; i++) {
+ int flags;
+ uint32_t *pfns = elem.out_sg[i].iov_base;
+ unsigned int n_pfns = elem.out_sg[i].iov_len / 4;
+ int j;
+
+ for (j = 0; j < n_pfns; j++) {
+ if (vq == s->dvq) /* deflate */
+ flags = MADV_WILLNEED;
+ else /* inflate */
+ flags = MADV_DONTNEED;
+
+#if 0
+ /* can't use this until we have mmu notifier support */
+ madvise(phys_ram_base + (pfns[j] << TARGET_PAGE_BITS),
+ TARGET_PAGE_SIZE, flags);
+#endif
+ }
+
+ wlen += elem.out_sg[i].iov_len;
+ }
+
+ virtqueue_push(vq, &elem, wlen);
+ virtio_notify(vdev, vq);
+}
+}
+
+static void virtio_balloon_get_config(VirtIODevice *vdev, uint8_t *config_data)
+{
+VirtIOBalloon *dev = to_virtio_balloon(vdev);
+struct virtio_balloon_config config;
+
+config.num_pages = dev->num_pages;
+config.actual = dev->actual;
+
+memcpy(config_data, &config, 8);
+}
+
+static void virtio_balloon_set_config(VirtIODevice *vdev,
+ const uint8_t *config_data)
+{
+VirtIOBalloon *dev = to_virtio_balloon(vdev);
+struct virtio_balloon_config config;
+memcpy(&config, config_data, 8);
+dev->actual = config.actual;
+}
+
+static uint32_t virtio_balloon_get_features(VirtIODevice *vdev)
+{
+return 0;
+}
+
+static ram_addr_t virtio_balloon_to_target(void *opaque, ram_addr_t target)
+{
+VirtIOBalloon *dev = opaque;
+
+if (target) {
+ dev->num_pages = (ram_size - target) >> TARGET_PAGE_BITS;
+ virtio_notify_config(&dev->vdev);
+}
+
+return ram_size - (dev->actual << TARGET_PAGE_BITS);
+}
+
+void *virtio_balloon_init(PCIBus *bus
Re: [kvm-devel] [PATCH] convert init_rmode_tss to slots_lock
Marcelo Tosatti wrote: > init_rmode_tss was forgotten during the conversion from mmap_sem to > slots_lock. > yup, good catch. > There are several sites reading the slots data without taking > slots_lock, including tdp_page_fault. I'll be sending a patch > to move acquision to vcpu_run as suggested by Avi later today. > > INFO: task qemu-system-x86:3748 blocked for more than 120 seconds. > Call Trace: > [] __down_read+0x86/0x9e > [] do_page_fault+0x346/0x78e > [] trace_hardirqs_on_thunk+0x35/0x3a > [] error_exit+0x0/0xa9 > [] copy_user_generic_string+0x17/0x40 > [] :kvm:kvm_write_guest_page+0x3e/0x5f > [] :kvm_intel:init_rmode_tss+0xa7/0xf9 > [] :kvm_intel:vmx_vcpu_reset+0x10/0x38a > [] :kvm:kvm_arch_vcpu_setup+0x20/0x53 > [] :kvm:kvm_vm_ioctl+0xad/0x1cf > [] __lock_acquire+0x4f7/0xc28 > [] vfs_ioctl+0x21/0x6b > [] do_vfs_ioctl+0x252/0x26b > [] sys_ioctl+0x3c/0x5e > [] system_call_after_swapgs+0x7b/0x80 > > Signed-off-by: Marcelo Tosatti <[EMAIL PROTECTED]> > > Index: kvm/arch/x86/kvm/vmx.c > === > --- kvm.orig/arch/x86/kvm/vmx.c > +++ kvm/arch/x86/kvm/vmx.c > @@ -1480,7 +1480,7 @@ static int init_rmode_tss(struct kvm *kv > int ret = 0; > int r; > > - down_read(¤t->mm->mmap_sem); > + down_read(&kvm->slots_lock); > r = kvm_clear_guest_page(kvm, fn, 0, PAGE_SIZE); > if (r < 0) > goto out; > @@ -1503,7 +1503,7 @@ static int init_rmode_tss(struct kvm *kv > > ret = 1; > out: > - up_read(¤t->mm->mmap_sem); > + up_read(&kvm->slots_lock); > return ret; > } > > > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] Порядок определения доходов и расходов при упрощенке
Упpощeнная систeма налoгooблoжeния Oднoднeвный сeминаp пpoйдёт 21 маpта 2008г. (Мoсква) В пpoгpамма: 1. Сущнoсть УСН, oсвoбoждeниe oт уплаты pяда налoгoв. Пopядoк и услoвия начала и пpeкpащeния пpимeнeния упpoщeннoй систeмы налoгooблoжeния с учeтoм нoвшeств 2008 г. Тpeбoвания к pазмepу дoхoдoв, стoимoсти oснoвных сpeдств, числeннoсти pабoтникoв, сoставу учpeдитeлeй, видам дeятeльнoсти и стpуктуpe opганизации: чтo скpытo за фopмулиpoвками НК pФ. pиски для "упpoщeнцeв": в чeм налoгoвыe opганы усматpивают "налoгoвыe схeмы". 2. oбъeкты налoгooблoжeния: чeм pукoвoдствoваться пpи выбope. Смeна oбъeкта - pазличныe пoдхoды. oсoбыe oгpаничeния в выбope oбъeкта для oтдeльных видoв дeятeльнoсти 3. opганизация бухгалтepскoгo и налoгoвoгo учeта пpи УСН. Книга дoхoдoв и pасхoдoв - oсoбeннoсти вeдeния и пpeдставлeния налoгoвoму opгану. Пpoблeма выставлeния счeтoв-фактуp 4. Пopядoк oпpeдeлeния дoхoдoв и pасхoдoв (с учeтoм нoвшeств 2008 г.): 5. Исчислeниe и уплата налoга. Минимальный налoг. Налoгoвая дeклаpация 6. oсoбeннoсти исчислeния налoгoвoй базы пpи пepeхoдe на упpoщeнную систeму налoгooблoжeния и пpи пepeхoдe с упpoщeннoй систeмы налoгooблoжeния на иныe peжимы налoгooблoжeния с учeтoм нoвшeств 2008 г. Пpoдoлжитeльнoсть oбучeния: с 10 дo 17 часoв (с пepepывoм на oбeд и кoфe-паузу). Мeстo oбучeния: г. Мoсква, 5 мин. пeшкoм oт м. Акадeмичeская. Стoимoсть oбучeния: 4900 pуб. (с НДС). (В стoимoсть вхoдит: pаздатoчный матepиал, кoфe-пауза, oбeд в peстopанe). Пpи oтсутствии вoзмoжнoсти пoсeтить сeминаp, мы пpeдлагаeм пpиoбpeсти eгo видeoвepсию на DVD/CD дисках или видeoкассeтах (пpилагаeтся автopский pаздатoчный матepиал). Цeна видeoкуpса - 3500 pублeй, с учeтoм НДС. Пoлучить дoпoлнитeльную инфopмацию и заpeгистpиpoваться мoжнo: пo т/ф: ( 4 9 5 ) 5 4 3 - 8 8 - 4 6 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] tools to dump guest memory and generate core file
That's what I was looking for. thanks, david Uri Lublin wrote: > Avi Kivity wrote: >> david ahern wrote: >> >>> Attaching gdb to qemu you work with addresses as seen by the qemu >>> process; the >>> idea is to work with addresses as seen inside the guest. >>> >>> >>> Now, if you attach gdb to the qemu process, >>> >>> gdb /usr/local/bin/qemu-system-x86_64 2346 >>> >> I meant connecting to the gdb stub in qemu that represents the guest: >> >> (gdb) target remote localhost:1234 >> >> Of course, it means starting qemu with the gdb stub enabled. We might >> add a monitor command to start it after the fact. >> > gdbserver is the monitor command you're looking for: > (qemu) help gdbserver > gdbserver [port] -- start gdbserver session (default port=1234) > > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] windows acpi time drift
Dor Laor wrote: > 2. The other option is to have an accurate userspace timer (userspace > hrtimer exist >= 2.6.24) and to add interface to pic/apic to queue > pending irqs by the pit/rtc. > The pending queue can be a simple atomic counter per irq. > So this may explain why I see no appreciable benefit from using the in-kernel PIT verses using the userspace PIT and -tdf. I'm using a 2.6.24 host kernel and QEMU by default will use the "unix" time source which will use setitimer. IIUC, itimer will use hrtimers. So if there isn't an appreciate CPU utilization improvement and there isn't an increased accuracy, there won't be an improvement. Do ya'll see an improvement playing multimedia on a 2.6.24 host with the in-kernel PIT? Regards, Anthony Liguori > Note that we also need support for older host kernels. > > Before implementing yet another in-kernel device I like to hear > opinions. > Regards, > Dor. > > > - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > ___ > kvm-devel mailing list > kvm-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/kvm-devel > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] windows acpi time drift
Dor Laor wrote: > On Wed, 2008-03-19 at 01:09 +0200, Dor Laor wrote: > >> After some research of time drift while using window windows acpi hal I >> discovered it uses the ... rtc timer as a source clock. >> Not the apic, acpi nor the pit. The acpi timer is not used by the time >> keeping clock, the apic & pit timer irqs are masked. >> >> In order to fix the time drift we need to fix the rtc emulation. >> The problem is that like the pit and the apic timers in userspace, the >> rtc also has inaccurate timer, thus leading to irq coalescing before >> getting acknowledged by the guest interrupt controller. >> >> We have two options: >> 1. Bring another device to the kernel >> - It's a simple device >> - It will make the rtc clock more accurate (hrtimer) >> - Easy time drift fix like apic/pic >> - It has very minor performance improvment of canceling the >> need to go to userspace after vmexit, thus not syncing vmcs. >> But it's only 15msec * 2 rate. >> > > Hmm, when doing multimedia, windows increases the frequency of rtc from > 64HZ to 1024HZ, thus in-kernel device will save 2048 user-space exits. > This might be a real improvement - small but measurable. > Well, let's calculate it. I measure a lightweight exit at 3590 cycles and a heavyweight exit at 8548. If we look at the cost of dropping to userspace an extra 2048 times, since I have a 2.2 GHz chip, we're looking at an additional .0046 seconds to transition to userspace. This is on top of the base .0033 seconds that it takes to take these exits in the first place. This are dummy exits though so when you add in the cost of processing this (which I think is roughly equal whether in kernelspace or userspace) I think those values will quickly be overwhelmed. So, at the end of the day, you're not getting even a 1% performance boost and you're adding a lot of complexity to the kernel. This strongly suggests to me that we should be doing this in userspace. Regards, Anthony Liguori - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] windows acpi time drift
Dor Laor wrote: > After some research of time drift while using window windows acpi hal I > discovered it uses the ... rtc timer as a source clock. > Not the apic, acpi nor the pit. The acpi timer is not used by the time > keeping clock, the apic & pit timer irqs are masked. > > In order to fix the time drift we need to fix the rtc emulation. > The problem is that like the pit and the apic timers in userspace, the > rtc also has inaccurate timer, thus leading to irq coalescing before > getting acknowledged by the guest interrupt controller. > > We have two options: > 1. Bring another device to the kernel > - It's a simple device > - It will make the rtc clock more accurate (hrtimer) > - Easy time drift fix like apic/pic > - It has very minor performance improvment of canceling the > need to go to userspace after vmexit, thus not syncing vmcs. > But it's only 15msec * 2 rate. > but > - both the pit & rtc are somehow code duplications from > userspace. Both need more accurate timer + interface to > detect irq acks by the pic/apic. > 2. The other option is to have an accurate userspace timer (userspace > hrtimer exist >= 2.6.24) and to add interface to pic/apic to queue > pending irqs by the pit/rtc. > The pending queue can be a simple atomic counter per irq. > Note that we also need support for older host kernels. > Why don't we just introduce a vm-ioctl interface for a one-shot programmable timer? It could be programmed in userspace, and when it fires, we can drop down to userspace with a special exit code. We could then introduce an interrupt queuing mechanism in the kernel specifically for timer interrupts as you mention. That lets us remove the in-kernel PIT, and makes all of our timer mechanisms more accurate. If userspace has a better time mechanism, like hrtimer, then it can just use that. If hrtimer is good enough in userspace, then we can contain these new ioctls to the compat-code only. Regards, Anthony Liguori > Before implementing yet another in-kernel device I like to hear > opinions. > Regards, > Dor. > > > - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > ___ > kvm-devel mailing list > kvm-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/kvm-devel > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] windows acpi time drift
On Wed, 2008-03-19 at 01:09 +0200, Dor Laor wrote: > After some research of time drift while using window windows acpi hal I > discovered it uses the ... rtc timer as a source clock. > Not the apic, acpi nor the pit. The acpi timer is not used by the time > keeping clock, the apic & pit timer irqs are masked. > > In order to fix the time drift we need to fix the rtc emulation. > The problem is that like the pit and the apic timers in userspace, the > rtc also has inaccurate timer, thus leading to irq coalescing before > getting acknowledged by the guest interrupt controller. > > We have two options: > 1. Bring another device to the kernel > - It's a simple device > - It will make the rtc clock more accurate (hrtimer) > - Easy time drift fix like apic/pic > - It has very minor performance improvment of canceling the > need to go to userspace after vmexit, thus not syncing vmcs. > But it's only 15msec * 2 rate. Hmm, when doing multimedia, windows increases the frequency of rtc from 64HZ to 1024HZ, thus in-kernel device will save 2048 user-space exits. This might be a real improvement - small but measurable. > but > - both the pit & rtc are somehow code duplications from > userspace. Both need more accurate timer + interface to > detect irq acks by the pic/apic. > 2. The other option is to have an accurate userspace timer (userspace > hrtimer exist >= 2.6.24) and to add interface to pic/apic to queue > pending irqs by the pit/rtc. > The pending queue can be a simple atomic counter per irq. > Note that we also need support for older host kernels. > > Before implementing yet another in-kernel device I like to hear > opinions. > Regards, > Dor. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] windows acpi time drift
After some research of time drift while using window windows acpi hal I discovered it uses the ... rtc timer as a source clock. Not the apic, acpi nor the pit. The acpi timer is not used by the time keeping clock, the apic & pit timer irqs are masked. In order to fix the time drift we need to fix the rtc emulation. The problem is that like the pit and the apic timers in userspace, the rtc also has inaccurate timer, thus leading to irq coalescing before getting acknowledged by the guest interrupt controller. We have two options: 1. Bring another device to the kernel - It's a simple device - It will make the rtc clock more accurate (hrtimer) - Easy time drift fix like apic/pic - It has very minor performance improvment of canceling the need to go to userspace after vmexit, thus not syncing vmcs. But it's only 15msec * 2 rate. but - both the pit & rtc are somehow code duplications from userspace. Both need more accurate timer + interface to detect irq acks by the pic/apic. 2. The other option is to have an accurate userspace timer (userspace hrtimer exist >= 2.6.24) and to add interface to pic/apic to queue pending irqs by the pit/rtc. The pending queue can be a simple atomic counter per irq. Note that we also need support for older host kernels. Before implementing yet another in-kernel device I like to hear opinions. Regards, Dor. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [kvm-ppc-devel] [PATCH 3 of 7] Create new load_uimage() & gunzip support to uboot loader in Qemu
On Tue, 2008-03-18 at 16:46 -0500, Jerone Young wrote:
> On Tue, 2008-03-18 at 16:14 -0500, Hollis Blanchard wrote:
> > On Tue, 2008-03-18 at 15:06 -0500, Jerone Young wrote:
> > > +tmp_loaded_image_size = hdr->ih_size;
> > > +
> > > +if (hdr->ih_comp == IH_COMP_GZIP) {
> > > + uncompressed_data = qemu_malloc(MAX_KERNEL_SIZE);
> > > + ret = gunzip(uncompressed_data, MAX_KERNEL_SIZE,
> > > +(unsigned char *) data,
> > > +&tmp_loaded_image_size);
> > > +
> > > + if (ret < 0) {
> > > +fprintf(stderr, "Unable to decompress gziped image!
> > \n");
> > > +goto fail;
> > > +}
> > > +
> > > +qemu_free(data);
> > > +cpu_physical_memory_write_rom(hdr->ih_load,
> > uncompressed_data,
> > > + tmp_loaded_image_size);
> > > +
> > > +}
> > > +else {
> > > +cpu_physical_memory_write_rom(hdr->ih_load, data,
> > > + tmp_loaded_image_size);
> > > +}
> > > +
> > > +if (loaded_image_size != NULL)
> > > +*loaded_image_size = tmp_loaded_image_size;
> > > +
> > > +if ( load_address != NULL)
> > > + *load_address = hdr->ih_load;
> >
> > Your whitespace in here is all over the place. Please fix.
>
> Actually this matches the style of this entire file. I see the one white
> space. I see also I used a tab one place.
You switch from 8-space indentation in gunzip() to 4-space in
load_uimage(), and then things go *really* screwy around "Unable to
decompress gziped image" (which you spelled wrong btw). It looks like
you alternate between 4- and 3-space indentation after that. That does
NOT match the style of the rest of the file.
As for the "if ( " syntax, there are only a handful of people doing it
that way in the whole qemu tree, and more importantly, none of them are
in our code.
--
Hollis Blanchard
IBM Linux Technology Center
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [kvm-ppc-devel] [PATCH 5 of 7] Add dynamic device tree manipulation & change uboot loader for PPC bamboo board model
I can only assume that you will actually make the corrections that you
didn't respond to in this mail.
On Tue, 2008-03-18 at 16:35 -0500, Jerone Young wrote:
> On Tue, 2008-03-18 at 16:25 -0500, Hollis Blanchard wrote:
> >
> > > +#define DT_PROC_INTERFACE_PATH "/proc/device-tree"
> > > +
> > > +/* FUNCTIONS FOR READING FROM DEVICE TREE OF HOST IN /PROC */
> > > +
> > > +/* This function reads device-tree property files that are of
> > > + * a single cell size
> > > + */
> > > +uint32_t read_proc_dt_prop_cell(char *path_in_device_tree)
> > > +{
> > > + char *buf = NULL;
> > > + int i;
> > > + uint32_t num;
> > > + FILE *stream;
> > > +
> > > + i = snprintf(buf, 0, "%s/%s", DT_PROC_INTERFACE_PATH,
> > > + path_in_device_tree);
> > > +
> > > + buf = (char *)malloc(i);
> > > + if (buf == NULL)
> > > + {
> > > + printf("%s: Unable to malloc string buffer buf\n",
> > > + __func__);
> > > + exit(1);
> > > + }
> >
> > Braces.
>
> What is the deal. They are braces. They are done diffrenent through outt
> the qemu code. This
I don't enjoy correcting whitespace, and in fact I hate it when that's
all comments are about. If it weren't so egregious in this patch series,
I probably would have let it slide.
In general I don't really care as long as it's *consistent*. The tabs
you use in this code clashes with the rest of qemu, and that makes it
difficult to use the right editor settings. Despite that, I still didn't
say anything, because at least it's consistent.
In general, don't just make your code work; make it pretty too.
> > > @@ -26,14 +27,22 @@ void bamboo_init(ram_addr_t ram_size, in
> > > const char *initrd_filename,
> > > const char *cpu_model)
> > > {
> > > + char buf[1024];
> >
> > You previously said you had removed 'buf' and replaced it with dynamic
> > allocation, but I don't see that here.
>
> Removing of buf discussed was from hw/device_tree.c not this file.
So you can fix it here too, right?
--
Hollis Blanchard
IBM Linux Technology Center
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [kvm-ppc-devel] [PATCH 2 of 7] Add libfdt support to qemu
Well this can not go upstream. If it were to go into upstream qemu we would need for them to take in libfdt (which they most likely will have big issue with). Also we wouldn't do the probing if they did take it in. But for the forseable future we are not getting stuff into qemu yet. If we do then will cross this road and remove this completely. Or if libfdt ever is packaged separately. For now this is what we have to do for probing On Tue, 2008-03-18 at 16:28 -0500, Hollis Blanchard wrote: > OK, if that's acceptable to the qemu folks, could you put that in the > patch description? > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [kvm-ppc-devel] [PATCH 3 of 7] Create new load_uimage() & gunzip support to uboot loader in Qemu
On Tue, 2008-03-18 at 16:14 -0500, Hollis Blanchard wrote:
> On Tue, 2008-03-18 at 15:06 -0500, Jerone Young wrote:
> > +tmp_loaded_image_size = hdr->ih_size;
> > +
> > +if (hdr->ih_comp == IH_COMP_GZIP) {
> > + uncompressed_data = qemu_malloc(MAX_KERNEL_SIZE);
> > + ret = gunzip(uncompressed_data, MAX_KERNEL_SIZE,
> > +(unsigned char *) data,
> > +&tmp_loaded_image_size);
> > +
> > + if (ret < 0) {
> > +fprintf(stderr, "Unable to decompress gziped image!
> \n");
> > +goto fail;
> > +}
> > +
> > +qemu_free(data);
> > +cpu_physical_memory_write_rom(hdr->ih_load,
> uncompressed_data,
> > + tmp_loaded_image_size);
> > +
> > +}
> > +else {
> > +cpu_physical_memory_write_rom(hdr->ih_load, data,
> > + tmp_loaded_image_size);
> > +}
> > +
> > +if (loaded_image_size != NULL)
> > +*loaded_image_size = tmp_loaded_image_size;
> > +
> > +if ( load_address != NULL)
> > + *load_address = hdr->ih_load;
>
> Your whitespace in here is all over the place. Please fix.
Actually this matches the style of this entire file. I see the one white
space. I see also I used a tab one place.
The problem is there is no set style in qemu. So I followed the style of
the already created file.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [kvm-ppc-devel] [PATCH 5 of 7] Add dynamic device tree manipulation & change uboot loader for PPC bamboo board model
On Tue, 2008-03-18 at 16:25 -0500, Hollis Blanchard wrote:
> On Tue, 2008-03-18 at 15:06 -0500, Jerone Young wrote:
> > # HG changeset patch
> > # User Jerone Young <[EMAIL PROTECTED]>
> > # Date 1205870472 18000
> > # Branch merge
> > # Node ID 3e87db599895937824b9bf3369eb67ea7f5a7595
> > # Parent ba2876c3e8916ba9c19b75c4464cbb8dc6858fbd
> > Add dynamic device tree manipulation & change uboot loader for PPC bamboo
> > board model
> >
> > This patch adds code to dynamically manipulate the device tree when
> > loaded into memory. This allows us to finally have the ability to
> > manipulate the kernel command line & initrd from the qemu command
> > line. This will also let us setup different settings for the board.
> >
> > This patch also now uses new uboot loader load_image() to load kernel
> > image.
>
> Again, the load_uimage part (which you've misspelled here) should be a
> separate patch?
>
> > Signed-off-by: Jerone Young <[EMAIL PROTECTED]>
> >
> > diff --git a/qemu/Makefile.target b/qemu/Makefile.target
> > --- a/qemu/Makefile.target
> > +++ b/qemu/Makefile.target
> > @@ -617,7 +617,7 @@ OBJS+= unin_pci.o ppc_chrp.o
> > OBJS+= unin_pci.o ppc_chrp.o
> > # PowerPC 4xx boards
> > OBJS+= pflash_cfi02.o ppc4xx_devs.o ppc405_uc.o ppc405_boards.o
> > -OBJS+= ppc440.o ppc440_bamboo.o
> > +OBJS+= ppc440.o ppc440_bamboo.o device_tree.o
> > endif
> > ifeq ($(TARGET_BASE_ARCH), mips)
> > OBJS+= mips_r4k.o mips_malta.o mips_pica61.o mips_mipssim.o
> > diff --git a/qemu/hw/device_tree.c b/qemu/hw/device_tree.c
> > new file mode 100644
> > --- /dev/null
> > +++ b/qemu/hw/device_tree.c
> > @@ -0,0 +1,181 @@
> > +/*
> > + * Functions to help device tree manipulation using libfdt.
> > + * It also provides functions to read entries from device tree proc
> > + * interface.
> > + *
> > + * Copyright 2008 IBM Corporation.
> > + * Authors: Jerone Young <[EMAIL PROTECTED]>
> > + *
> > + * This work is licensed under the GNU GPL license version 2 or later.
> > + *
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include "config.h"
> > +#include "ppc440.h"
> > +
> > +#ifdef CONFIG_LIBFDT
> > + #include "libfdt.h"
> > +#endif
>
> Again, don't indent this.
>
> > +#define DT_PROC_INTERFACE_PATH "/proc/device-tree"
> > +
> > +/* FUNCTIONS FOR READING FROM DEVICE TREE OF HOST IN /PROC */
> > +
> > +/* This function reads device-tree property files that are of
> > + * a single cell size
> > + */
> > +uint32_t read_proc_dt_prop_cell(char *path_in_device_tree)
> > +{
> > + char *buf = NULL;
> > + int i;
> > + uint32_t num;
> > + FILE *stream;
> > +
> > + i = snprintf(buf, 0, "%s/%s", DT_PROC_INTERFACE_PATH,
> > + path_in_device_tree);
> > +
> > + buf = (char *)malloc(i);
> > + if (buf == NULL)
> > + {
> > + printf("%s: Unable to malloc string buffer buf\n",
> > + __func__);
> > + exit(1);
> > + }
>
> Braces.
What is the deal. They are braces. They are done diffrenent through outt
the qemu code. This
>
> > + i = snprintf(buf, i+1, "%s/%s", DT_PROC_INTERFACE_PATH,
> > + path_in_device_tree);
> > +
> > + stream = fopen(buf, "rb");
> > +
> > + if (stream == NULL)
> > + {
> > + printf("%s: Unable to open '%s'\n", __func__, buf);
> > + exit(1);
> > + }
>
> Braces.
>
> > + fread(&num, sizeof(num), 1, stream);
> > + fclose(stream);
> > +
> > + return num;
> > +}
> > +
> > +/* FUNCTIONS FOR LOADING & MANIPULATION OF DEVICE TREE IN GUEST */
> > +
> > +#ifdef CONFIG_LIBFDT
> > +/* support functions */
> > +static int get_offset_of_node(void *fdt, char *node_path)
> > +{
> > + int node_offset;
> > + node_offset = fdt_path_offset(fdt, node_path);
> > + if (node_offset < 0) {
> > + printf("Unable to find node in device tree '%s'\n",
> > + node_path);
> > + exit(1);
> > + }
> > + return node_offset;
> > +}
> > +
> > +/* public functions */
> > +void *load_device_tree(char *filename_path, unsigned long load_addr)
> > +{
> > + int dt_file_size;
> > + int dt_file_load_size;
> > + int new_dt_size;int ret;
>
> Does this look right to you?
>
can clean that.
> ...
> > diff --git a/qemu/hw/ppc440_bamboo.c b/qemu/hw/ppc440_bamboo.c
> > --- a/qemu/hw/ppc440_bamboo.c
> > +++ b/qemu/hw/ppc440_bamboo.c
> > @@ -4,15 +4,16 @@
> > * Copyright 2007 IBM Corporation.
> > * Authors: Jerone Young <[EMAIL PROTECTED]>
> > *
> > - * This work is licensed under the GNU GPL licence version 2 or later.
> > + * This work is licensed under the GNU GPL license version 2 or later.
> > *
> > */
> >
> > +#include "config.h"
> > #include "ppc440.h"
> > +#include "qemu-kvm.h"
> > +#include "device_tree.h"
> >
> > -#define KERNEL_LOAD_ADDR 0x40 /* uboot loader puts kernel at 4MB */
> > -
> > -#include "qemu-kvm.h"
> > +#define BINARY_DEVICE_TREE_FILE "bamboo.dtb"
> >
> > /* PPC 440 refrence demo
Re: [kvm-devel] [kvm-ppc-devel] [PATCH 2 of 7] Add libfdt support to qemu
OK, if that's acceptable to the qemu folks, could you put that in the
patch description?
--
Hollis Blanchard
IBM Linux Technology Center
On Tue, 2008-03-18 at 16:22 -0500, Jerone Young wrote:
> So this is the code Anthony asked for for probing libfdt. The problem is
> that if you do ./configure at kvm-userpace top directory for
> the first time or after a clean you do not have libfdt.a. When qemu
> configure is run this probe would allways fail. So to check we just
> check for the header. So we compile a very simple program that include
> libfdt.h as the test.
>
> All the XXX are if we ever do break libfdt out then we can do the proper
> probing for it (and the code for it is ready to be uncommented).
>
>
> On Tue, 2008-03-18 at 16:16 -0500, Hollis Blanchard wrote:
> > On Tue, 2008-03-18 at 15:06 -0500, Jerone Young wrote:
> > > +##
> > > +# libfdt probe
> > > +#
> > > +if test -z "$device_tree_support" -a \
> > > + "$cpu" = "powerpc"; then
> > > + device_tree_support="no"
> > > + cat > $TMPC << EOF
> > > +#include
> > > +/* XXX uncomment later when libfdt is built before this test */
> > > +//int main(void) { void *fdt; return fdt_create(fdt, 1024); }
> > > +int main (void) {return 0;}
> > > +EOF
> > > +# XXX for now do not try to link to libfdt and just check for header */
> > > +# if $cc $ARCH_CFLAGS $CFLAGS $LDFLAGS -o $TMPE $TMPC -lfdt 2> /dev/null
> > > ; then
> > > + if $cc $ARCH_CFLAGS $CFLAGS $LDFLAGS -o $TMPE $TMPC 2> /dev/null; then
> > > + device_tree_support="yes"
> > > + else
> > > +echo
> > > +echo "Error: Could not find libfdt"
> > > +echo "Make sure to have the libfdt libs and headers installed."
> > > +echo
> > > +exit 1
> > > + fi
> > > +fi
> >
> > What is the problem here? Should you describe it in the patch
> > description? Did you mean to fix this before committing?
> >
>
>
> -
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
> ___
> kvm-ppc-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [kvm-ppc-devel] [PATCH 5 of 7] Add dynamic device tree manipulation & change uboot loader for PPC bamboo board model
On Tue, 2008-03-18 at 15:06 -0500, Jerone Young wrote:
> # HG changeset patch
> # User Jerone Young <[EMAIL PROTECTED]>
> # Date 1205870472 18000
> # Branch merge
> # Node ID 3e87db599895937824b9bf3369eb67ea7f5a7595
> # Parent ba2876c3e8916ba9c19b75c4464cbb8dc6858fbd
> Add dynamic device tree manipulation & change uboot loader for PPC bamboo
> board model
>
> This patch adds code to dynamically manipulate the device tree when
> loaded into memory. This allows us to finally have the ability to
> manipulate the kernel command line & initrd from the qemu command
> line. This will also let us setup different settings for the board.
>
> This patch also now uses new uboot loader load_image() to load kernel
> image.
Again, the load_uimage part (which you've misspelled here) should be a
separate patch?
> Signed-off-by: Jerone Young <[EMAIL PROTECTED]>
>
> diff --git a/qemu/Makefile.target b/qemu/Makefile.target
> --- a/qemu/Makefile.target
> +++ b/qemu/Makefile.target
> @@ -617,7 +617,7 @@ OBJS+= unin_pci.o ppc_chrp.o
> OBJS+= unin_pci.o ppc_chrp.o
> # PowerPC 4xx boards
> OBJS+= pflash_cfi02.o ppc4xx_devs.o ppc405_uc.o ppc405_boards.o
> -OBJS+= ppc440.o ppc440_bamboo.o
> +OBJS+= ppc440.o ppc440_bamboo.o device_tree.o
> endif
> ifeq ($(TARGET_BASE_ARCH), mips)
> OBJS+= mips_r4k.o mips_malta.o mips_pica61.o mips_mipssim.o
> diff --git a/qemu/hw/device_tree.c b/qemu/hw/device_tree.c
> new file mode 100644
> --- /dev/null
> +++ b/qemu/hw/device_tree.c
> @@ -0,0 +1,181 @@
> +/*
> + * Functions to help device tree manipulation using libfdt.
> + * It also provides functions to read entries from device tree proc
> + * interface.
> + *
> + * Copyright 2008 IBM Corporation.
> + * Authors: Jerone Young <[EMAIL PROTECTED]>
> + *
> + * This work is licensed under the GNU GPL license version 2 or later.
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "config.h"
> +#include "ppc440.h"
> +
> +#ifdef CONFIG_LIBFDT
> + #include "libfdt.h"
> +#endif
Again, don't indent this.
> +#define DT_PROC_INTERFACE_PATH "/proc/device-tree"
> +
> +/* FUNCTIONS FOR READING FROM DEVICE TREE OF HOST IN /PROC */
> +
> +/* This function reads device-tree property files that are of
> + * a single cell size
> + */
> +uint32_t read_proc_dt_prop_cell(char *path_in_device_tree)
> +{
> + char *buf = NULL;
> + int i;
> + uint32_t num;
> + FILE *stream;
> +
> + i = snprintf(buf, 0, "%s/%s", DT_PROC_INTERFACE_PATH,
> + path_in_device_tree);
> +
> + buf = (char *)malloc(i);
> + if (buf == NULL)
> + {
> + printf("%s: Unable to malloc string buffer buf\n",
> + __func__);
> + exit(1);
> + }
Braces.
> + i = snprintf(buf, i+1, "%s/%s", DT_PROC_INTERFACE_PATH,
> + path_in_device_tree);
> +
> + stream = fopen(buf, "rb");
> +
> + if (stream == NULL)
> + {
> + printf("%s: Unable to open '%s'\n", __func__, buf);
> + exit(1);
> + }
Braces.
> + fread(&num, sizeof(num), 1, stream);
> + fclose(stream);
> +
> + return num;
> +}
> +
> +/* FUNCTIONS FOR LOADING & MANIPULATION OF DEVICE TREE IN GUEST */
> +
> +#ifdef CONFIG_LIBFDT
> +/* support functions */
> +static int get_offset_of_node(void *fdt, char *node_path)
> +{
> + int node_offset;
> + node_offset = fdt_path_offset(fdt, node_path);
> + if (node_offset < 0) {
> + printf("Unable to find node in device tree '%s'\n",
> + node_path);
> + exit(1);
> + }
> + return node_offset;
> +}
> +
> +/* public functions */
> +void *load_device_tree(char *filename_path, unsigned long load_addr)
> +{
> + int dt_file_size;
> + int dt_file_load_size;
> + int new_dt_size;int ret;
Does this look right to you?
...
> diff --git a/qemu/hw/ppc440_bamboo.c b/qemu/hw/ppc440_bamboo.c
> --- a/qemu/hw/ppc440_bamboo.c
> +++ b/qemu/hw/ppc440_bamboo.c
> @@ -4,15 +4,16 @@
> * Copyright 2007 IBM Corporation.
> * Authors: Jerone Young <[EMAIL PROTECTED]>
> *
> - * This work is licensed under the GNU GPL licence version 2 or later.
> + * This work is licensed under the GNU GPL license version 2 or later.
> *
> */
>
> +#include "config.h"
> #include "ppc440.h"
> +#include "qemu-kvm.h"
> +#include "device_tree.h"
>
> -#define KERNEL_LOAD_ADDR 0x40 /* uboot loader puts kernel at 4MB */
> -
> -#include "qemu-kvm.h"
> +#define BINARY_DEVICE_TREE_FILE "bamboo.dtb"
>
> /* PPC 440 refrence demo board
Could you fix this typo while you're at it?
> @@ -26,14 +27,22 @@ void bamboo_init(ram_addr_t ram_size, in
> const char *initrd_filename,
> const char *cpu_model)
> {
> + char buf[1024];
You previously said you had removed 'buf' and replaced it with dynamic
allocation, but I don't see that here.
> target_phys_addr_t ram_bases[2], ram_sizes[2];
> qemu_
Re: [kvm-devel] [kvm-ppc-devel] [PATCH 2 of 7] Add libfdt support to qemu
So this is the code Anthony asked for for probing libfdt. The problem is
that if you do ./configure at kvm-userpace top directory for
the first time or after a clean you do not have libfdt.a. When qemu
configure is run this probe would allways fail. So to check we just
check for the header. So we compile a very simple program that include
libfdt.h as the test.
All the XXX are if we ever do break libfdt out then we can do the proper
probing for it (and the code for it is ready to be uncommented).
On Tue, 2008-03-18 at 16:16 -0500, Hollis Blanchard wrote:
> On Tue, 2008-03-18 at 15:06 -0500, Jerone Young wrote:
> > +##
> > +# libfdt probe
> > +#
> > +if test -z "$device_tree_support" -a \
> > + "$cpu" = "powerpc"; then
> > + device_tree_support="no"
> > + cat > $TMPC << EOF
> > +#include
> > +/* XXX uncomment later when libfdt is built before this test */
> > +//int main(void) { void *fdt; return fdt_create(fdt, 1024); }
> > +int main (void) {return 0;}
> > +EOF
> > +# XXX for now do not try to link to libfdt and just check for header */
> > +# if $cc $ARCH_CFLAGS $CFLAGS $LDFLAGS -o $TMPE $TMPC -lfdt 2> /dev/null ;
> > then
> > + if $cc $ARCH_CFLAGS $CFLAGS $LDFLAGS -o $TMPE $TMPC 2> /dev/null; then
> > + device_tree_support="yes"
> > + else
> > +echo
> > +echo "Error: Could not find libfdt"
> > +echo "Make sure to have the libfdt libs and headers installed."
> > +echo
> > +exit 1
> > + fi
> > +fi
>
> What is the problem here? Should you describe it in the patch
> description? Did you mean to fix this before committing?
>
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [kvm-ppc-devel] [PATCH 7 of 7] Add ability to specify ram on command line for bamboo board model
On Tue, 2008-03-18 at 16:03 -0500, Hollis Blanchard wrote:
> On Tue, 2008-03-18 at 15:06 -0500, Jerone Young wrote:
> > # HG changeset patch
> > # User Jerone Young <[EMAIL PROTECTED]>
> > # Date 1205870472 18000
> > # Branch merge
> > # Node ID 4f90f7d25186f55bfb1503764af5264201df067f
> > # Parent ac0fc9dfd78d2eddd083326e9b635a9286fc3b19
> > Add ability to specify ram on command line for bamboo board model
> >
> > This patch adds the ability to now specify ram sizes on the command line.
> > Due to the nature of the code there are restictions on exactly how
> > much ram and the multiple that the size must match.
> >
> > Signed-off-by: Jerone Young <[EMAIL PROTECTED]>
> >
> > diff --git a/qemu/hw/ppc440_bamboo.c b/qemu/hw/ppc440_bamboo.c
> > --- a/qemu/hw/ppc440_bamboo.c
> > +++ b/qemu/hw/ppc440_bamboo.c
> > @@ -15,6 +15,9 @@
> >
> > #define BINARY_DEVICE_TREE_FILE "bamboo.dtb"
> >
> > +#define bytes_to_mb(a) (a>>20)
> > +#define mb_to_bytes(a) (a<<20)
> > +
> > /* PPC 440 refrence demo board
> > *
> > * 440 PowerPC CPU
> > @@ -28,7 +31,7 @@ void bamboo_init(ram_addr_t ram_size, in
> > const char *cpu_model)
> > {
> > char buf[1024];
> > - target_phys_addr_t ram_bases[2], ram_sizes[2];
> > + target_phys_addr_t ram_bases[2], ram_sizes[2];
> > qemu_irq *pic;
> > CPUState *env;
> > target_ulong ep=0;
>
> Here you have added a trailing space.
ok
>
> > @@ -40,32 +43,39 @@ void bamboo_init(ram_addr_t ram_size, in
> > target_ulong dt_base=0;
> > void *fdt;
> > int ret;
> > + int ram_stick_sizes[] = {256, 128, 64, 32, 16, 8 }; /* in Mega bytes */
> > + ram_addr_t tmp_ram_size;
> > + int i=0, k=0;
>
> Define ram_stick_sizes[] in MB and then remove all the shifting inside
> the loops.
You must mean define them in bytes. That can be done also.
>
> > uint32_t cpu_freq;
> > uint32_t timebase_freq;
> >
> > printf("%s: START\n", __func__);
> >
> > - /* Setup Memory */
> > - if (ram_size) {
> > - printf("Ram size specified on command line is %i bytes\n",
> > - (int)ram_size);
> > - printf("WARNING: RAM is hard coded to 144MB\n");
> > - }
> > - else {
> > - printf("Using defualt ram size of %iMB\n",
> > - ((int)ram_size/1024)/1024);
> > + /* Setup Memory */
> > + printf("Ram size passed is: %i MB\n",
> > + bytes_to_mb((int)ram_size));
> > +
> > + tmp_ram_size = ram_size;
> > +
> > + for (i=0; i < (sizeof(ram_sizes)/sizeof(ram_sizes[0])); i++)
> > + {
> > + for (k=0; k <
> > (sizeof(ram_stick_sizes)/sizeof(ram_stick_sizes[0])); k++)
> > + {
> > + if ((bytes_to_mb(ram_size)/ram_stick_sizes[k]) > 0)
> > + {
>
> Don't divide, just use a logical comparison.
This can be done. Though it really doesn't matter. Both ways work.
> Also, put all the open-braces on the previous lines.
ok
>
> > + ram_sizes[i] = mb_to_bytes(ram_stick_sizes[k]);
> > + tmp_ram_size -= mb_to_bytes(ram_stick_sizes[k]);
> > + break;
> > + }
> > + }
> > }
> > - /* Each bank can only have memory in configurations of
> > -* 16MB, 32MB, 64MB, 128MB, or 256MB
> > -*/
> > - ram_bases[0] = 0x0;
> > - ram_sizes[0] = 0x0800;
> > - ram_bases[1] = 0x0;
> > - ram_sizes[1] = 0x0100;
> > -
> > - printf("Ram size of domain is %d bytes\n", (int)ram_size);
> > + if (tmp_ram_size) {
> > + printf("WARNING: %i MB left over memory is ram\n",
> > + bytes_to_mb((int)tmp_ram_size));
> > + ram_size -= tmp_ram_size;
> > + }
> >
> > /* Setup CPU */
> > env = cpu_ppc_init("440");
>
> Remove tmp_ram_size completely. Just decrement ram_size in the loop
> and
> check if it's non-zero at the end.
tmp_ram_size is needed because we use ram_size later used allocate
memory.
>
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [kvm-ppc-devel] [PATCH 2 of 7] Add libfdt support to qemu
On Tue, 2008-03-18 at 15:06 -0500, Jerone Young wrote:
> +##
> +# libfdt probe
> +#
> +if test -z "$device_tree_support" -a \
> + "$cpu" = "powerpc"; then
> + device_tree_support="no"
> + cat > $TMPC << EOF
> +#include
> +/* XXX uncomment later when libfdt is built before this test */
> +//int main(void) { void *fdt; return fdt_create(fdt, 1024); }
> +int main (void) {return 0;}
> +EOF
> +# XXX for now do not try to link to libfdt and just check for header */
> +# if $cc $ARCH_CFLAGS $CFLAGS $LDFLAGS -o $TMPE $TMPC -lfdt 2> /dev/null ;
> then
> + if $cc $ARCH_CFLAGS $CFLAGS $LDFLAGS -o $TMPE $TMPC 2> /dev/null; then
> + device_tree_support="yes"
> + else
> +echo
> +echo "Error: Could not find libfdt"
> +echo "Make sure to have the libfdt libs and headers installed."
> +echo
> +exit 1
> + fi
> +fi
What is the problem here? Should you describe it in the patch
description? Did you mean to fix this before committing?
--
Hollis Blanchard
IBM Linux Technology Center
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [kvm-ppc-devel] [PATCH 3 of 7] Create new load_uimage() & gunzip support to uboot loader in Qemu
On Tue, 2008-03-18 at 15:06 -0500, Jerone Young wrote:
> +tmp_loaded_image_size = hdr->ih_size;
> +
> +if (hdr->ih_comp == IH_COMP_GZIP) {
> + uncompressed_data = qemu_malloc(MAX_KERNEL_SIZE);
> + ret = gunzip(uncompressed_data, MAX_KERNEL_SIZE,
> +(unsigned char *) data,
> +&tmp_loaded_image_size);
> +
> + if (ret < 0) {
> +fprintf(stderr, "Unable to decompress gziped image!\n");
> +goto fail;
> +}
> +
> +qemu_free(data);
> +cpu_physical_memory_write_rom(hdr->ih_load, uncompressed_data,
> + tmp_loaded_image_size);
> +
> +}
> +else {
> +cpu_physical_memory_write_rom(hdr->ih_load, data,
> + tmp_loaded_image_size);
> +}
> +
> +if (loaded_image_size != NULL)
> +*loaded_image_size = tmp_loaded_image_size;
> +
> +if ( load_address != NULL)
> + *load_address = hdr->ih_load;
Your whitespace in here is all over the place. Please fix.
--
Hollis Blanchard
IBM Linux Technology Center
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [kvm-ppc-devel] [PATCH 7 of 7] Add ability to specify ram on command line for bamboo board model
On Tue, 2008-03-18 at 15:06 -0500, Jerone Young wrote:
> # HG changeset patch
> # User Jerone Young <[EMAIL PROTECTED]>
> # Date 1205870472 18000
> # Branch merge
> # Node ID 4f90f7d25186f55bfb1503764af5264201df067f
> # Parent ac0fc9dfd78d2eddd083326e9b635a9286fc3b19
> Add ability to specify ram on command line for bamboo board model
>
> This patch adds the ability to now specify ram sizes on the command line.
> Due to the nature of the code there are restictions on exactly how
> much ram and the multiple that the size must match.
>
> Signed-off-by: Jerone Young <[EMAIL PROTECTED]>
>
> diff --git a/qemu/hw/ppc440_bamboo.c b/qemu/hw/ppc440_bamboo.c
> --- a/qemu/hw/ppc440_bamboo.c
> +++ b/qemu/hw/ppc440_bamboo.c
> @@ -15,6 +15,9 @@
>
> #define BINARY_DEVICE_TREE_FILE "bamboo.dtb"
>
> +#define bytes_to_mb(a) (a>>20)
> +#define mb_to_bytes(a) (a<<20)
> +
> /* PPC 440 refrence demo board
> *
> * 440 PowerPC CPU
> @@ -28,7 +31,7 @@ void bamboo_init(ram_addr_t ram_size, in
> const char *cpu_model)
> {
> char buf[1024];
> - target_phys_addr_t ram_bases[2], ram_sizes[2];
> + target_phys_addr_t ram_bases[2], ram_sizes[2];
> qemu_irq *pic;
> CPUState *env;
> target_ulong ep=0;
Here you have added a trailing space.
> @@ -40,32 +43,39 @@ void bamboo_init(ram_addr_t ram_size, in
> target_ulong dt_base=0;
> void *fdt;
> int ret;
> + int ram_stick_sizes[] = {256, 128, 64, 32, 16, 8 }; /* in Mega bytes */
> + ram_addr_t tmp_ram_size;
> + int i=0, k=0;
Define ram_stick_sizes[] in MB and then remove all the shifting inside
the loops.
> uint32_t cpu_freq;
> uint32_t timebase_freq;
>
> printf("%s: START\n", __func__);
>
> - /* Setup Memory */
> - if (ram_size) {
> - printf("Ram size specified on command line is %i bytes\n",
> - (int)ram_size);
> - printf("WARNING: RAM is hard coded to 144MB\n");
> - }
> - else {
> - printf("Using defualt ram size of %iMB\n",
> - ((int)ram_size/1024)/1024);
> + /* Setup Memory */
> + printf("Ram size passed is: %i MB\n",
> + bytes_to_mb((int)ram_size));
> +
> + tmp_ram_size = ram_size;
> +
> + for (i=0; i < (sizeof(ram_sizes)/sizeof(ram_sizes[0])); i++)
> + {
> + for (k=0; k <
> (sizeof(ram_stick_sizes)/sizeof(ram_stick_sizes[0])); k++)
> + {
> + if ((bytes_to_mb(ram_size)/ram_stick_sizes[k]) > 0)
> + {
Don't divide, just use a logical comparison.
Also, put all the open-braces on the previous lines.
> + ram_sizes[i] = mb_to_bytes(ram_stick_sizes[k]);
> + tmp_ram_size -= mb_to_bytes(ram_stick_sizes[k]);
> + break;
> + }
> + }
> }
> - /* Each bank can only have memory in configurations of
> - * 16MB, 32MB, 64MB, 128MB, or 256MB
> - */
> - ram_bases[0] = 0x0;
> - ram_sizes[0] = 0x0800;
> - ram_bases[1] = 0x0;
> - ram_sizes[1] = 0x0100;
> -
> - printf("Ram size of domain is %d bytes\n", (int)ram_size);
> + if (tmp_ram_size) {
> + printf("WARNING: %i MB left over memory is ram\n",
> + bytes_to_mb((int)tmp_ram_size));
> + ram_size -= tmp_ram_size;
> + }
>
> /* Setup CPU */
> env = cpu_ppc_init("440");
Remove tmp_ram_size completely. Just decrement ram_size in the loop and
check if it's non-zero at the end.
--
Hollis Blanchard
IBM Linux Technology Center
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 4 of 7] Add PPC 440EP bamboo board device tree source & binary into qemu
# HG changeset patch
# User Jerone Young <[EMAIL PROTECTED]>
# Date 1205870472 18000
# Branch merge
# Node ID ba2876c3e8916ba9c19b75c4464cbb8dc6858fbd
# Parent 25515e6983ba1e070cbdcb7be1527426a097048b
Add PPC 440EP bamboo board device tree source & binary into qemu
This patch places the bamboo device tree for the PPC 440EP bamboo board into
the pc-bios directory of the qemu source. This also adds a rule into the
pc-bios/Makefile to build device tree files.
Signed-off-by: Jerone Young <[EMAIL PROTECTED]>
diff --git a/qemu/Makefile b/qemu/Makefile
--- a/qemu/Makefile
+++ b/qemu/Makefile
@@ -195,7 +195,8 @@ endif
mkdir -p "$(DESTDIR)$(datadir)"
for x in bios.bin vgabios.bin vgabios-cirrus.bin ppc_rom.bin \
video.x openbios-sparc32 pxe-ne2k_pci.bin \
- pxe-rtl8139.bin pxe-pcnet.bin pxe-e1000.bin extboot.bin; \
+ pxe-rtl8139.bin pxe-pcnet.bin pxe-e1000.bin extboot.bin \
+ bamboo.dtb; \
do \
$(INSTALL) -m 644 $(SRC_PATH)/pc-bios/$$x
"$(DESTDIR)$(datadir)"; \
done
diff --git a/qemu/pc-bios/Makefile b/qemu/pc-bios/Makefile
--- a/qemu/pc-bios/Makefile
+++ b/qemu/pc-bios/Makefile
@@ -12,6 +12,9 @@ all: $(TARGETS)
%.o: %.S
$(CC) $(DEFINES) -c -o $@ $<
+%.dtb: %.dts
+ dtc -O dtb -I dts -o $@ $<
+
clean:
- rm -f $(TARGETS) *.o *~
+ rm -f $(TARGETS) *.o *~ *.dtb
diff --git a/qemu/pc-bios/bamboo.dtb b/qemu/pc-bios/bamboo.dtb
new file mode 100644
index
..e02fa8e0bf23b992b04fe87dfce37d4cc08777a6
GIT binary patch
literal 2663
zc$~FXOKa6Y6h7&LdnW9X_Yk([EMAIL PROTECTED]>9}pJL
zM>[EMAIL PROTECTED]>>Jv&[EMAIL PROTECTED]|3x*(9n1CQu([EMAIL PROTECTED]
zRX%1N(`%;=)p>7N2oe=G;`xsF{YL$2@)[EMAIL PROTECTED];&zso~hZ)`=%c3Sb{
zGRd!&dm8)FuQsFnw%^3Gg>;*ZAFm(FdWl!W
zX`z~lhq6m-EZbqVj*GYs%OgsEL&[EMAIL PROTECTED]
z6>iC1owbfQH|94E#lF>s
z9D(`X9q4d[EMAIL PROTECTED]>!v4CS--Kln8N
zhED_YVIHCSp656NR+eNX?8UdcE>wDU8Eg?++&A-zU#2ezDrgrFDjcT-#^>kY{Ot!Z
z^K)B%-)m3K`7cnu6LZ9}A{NIwWv&~;T[EMAIL PROTECTED])yN=Ivkru3)MA?+o
z1Hicyw`&[EMAIL PROTECTED](ocgdU8AO?UeJr+<`3v52$S`X{M0}h7a^>O}
hww)+RiJO_zG!pI5
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without
+ * any warranty of any kind, whether express or implied.
+ */
+
+/ {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ model = "amcc,bamboo";
+ compatible = "amcc,bamboo";
+ dcr-parent = <&/cpus/[EMAIL PROTECTED]>;
+
+ aliases {
+ serial0 = &UART0;
+ serial1 = &UART1;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ [EMAIL PROTECTED] {
+ device_type = "cpu";
+ model = "PowerPC,440EP";
+ reg = <0>;
+ clock-frequency = <1fca0550>;
+ timebase-frequency = <017d7840>;
+ i-cache-line-size = <20>;
+ d-cache-line-size = <20>;
+ i-cache-size = <8000>;
+ d-cache-size = <8000>;
+ dcr-controller;
+ dcr-access-method = "native";
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0 0 900>;
+ };
+
+ UIC0: interrupt-controller0 {
+ compatible = "ibm,uic-440ep","ibm,uic";
+ interrupt-controller;
+ cell-index = <0>;
+ dcr-reg = <0c0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ };
+/*
+ UIC1: interrupt-controller1 {
+ compatible = "ibm,uic-440ep","ibm,uic";
+ interrupt-controller;
+ cell-index = <1>;
+ dcr-reg = <0d0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <1e 4 1f 4>;
+ interrupt-parent = <&UIC0>;
+ };
+*/
+
+ SDR0: sdr {
+ compatible = "ibm,sdr-440ep";
+ dcr-reg = <00e 002>;
+ };
+
+ CPR0: cpr {
+ compatible = "ibm,cpr-440ep";
+ dcr-reg = <00c 002>;
+ };
+
+ plb {
+ compatible = "ibm,plb-440ep", "ibm,plb-440gp", "ibm,plb4";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges;
+ clock-frequency = <07f28154>;
+
+ SDRAM0: sdram {
+ compatible = "ibm,sdram-440ep", "ibm,sdram-405gp";
+ dcr-reg = <010 2>;
+ };
+
+ DMA0: dma {
+ compatible = "ibm,dma-440ep", "ibm,dma-440gp";
+ dcr-reg = <100 027>;
+ };
+
[kvm-devel] [PATCH] convert init_rmode_tss to slots_lock
init_rmode_tss was forgotten during the conversion from mmap_sem to slots_lock. There are several sites reading the slots data without taking slots_lock, including tdp_page_fault. I'll be sending a patch to move acquision to vcpu_run as suggested by Avi later today. INFO: task qemu-system-x86:3748 blocked for more than 120 seconds. Call Trace: [] __down_read+0x86/0x9e [] do_page_fault+0x346/0x78e [] trace_hardirqs_on_thunk+0x35/0x3a [] error_exit+0x0/0xa9 [] copy_user_generic_string+0x17/0x40 [] :kvm:kvm_write_guest_page+0x3e/0x5f [] :kvm_intel:init_rmode_tss+0xa7/0xf9 [] :kvm_intel:vmx_vcpu_reset+0x10/0x38a [] :kvm:kvm_arch_vcpu_setup+0x20/0x53 [] :kvm:kvm_vm_ioctl+0xad/0x1cf [] __lock_acquire+0x4f7/0xc28 [] vfs_ioctl+0x21/0x6b [] do_vfs_ioctl+0x252/0x26b [] sys_ioctl+0x3c/0x5e [] system_call_after_swapgs+0x7b/0x80 Signed-off-by: Marcelo Tosatti <[EMAIL PROTECTED]> Index: kvm/arch/x86/kvm/vmx.c === --- kvm.orig/arch/x86/kvm/vmx.c +++ kvm/arch/x86/kvm/vmx.c @@ -1480,7 +1480,7 @@ static int init_rmode_tss(struct kvm *kv int ret = 0; int r; - down_read(¤t->mm->mmap_sem); + down_read(&kvm->slots_lock); r = kvm_clear_guest_page(kvm, fn, 0, PAGE_SIZE); if (r < 0) goto out; @@ -1503,7 +1503,7 @@ static int init_rmode_tss(struct kvm *kv ret = 1; out: - up_read(¤t->mm->mmap_sem); + up_read(&kvm->slots_lock); return ret; } - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 6 of 7] Modify PPC bamboo & ppc440 board models
# HG changeset patch
# User Jerone Young <[EMAIL PROTECTED]>
# Date 1205870472 18000
# Branch merge
# Node ID ac0fc9dfd78d2eddd083326e9b635a9286fc3b19
# Parent 3e87db599895937824b9bf3369eb67ea7f5a7595
Modify PPC bamboo & ppc440 board models
This patch renames pp440_init to ppc440ep_init, as ppc440 is the name of the
core and ppc440ep is the name of the SOC. When we init we are initializing the
SOC.
Also in this patch we now call cpu_ppc_init for bamboo with string 440 .. as
440 is the core.
Signed-off-by: Jerone Young <[EMAIL PROTECTED]>
diff --git a/qemu/hw/ppc440.c b/qemu/hw/ppc440.c
--- a/qemu/hw/ppc440.c
+++ b/qemu/hw/ppc440.c
@@ -10,7 +10,7 @@
#include "ppc440.h"
-void ppc440_init(CPUState *env,
+void ppc440ep_init(CPUState *env,
target_phys_addr_t ram_bases[2],
target_phys_addr_t ram_sizes[2],
qemu_irq **picp,
diff --git a/qemu/hw/ppc440.h b/qemu/hw/ppc440.h
--- a/qemu/hw/ppc440.h
+++ b/qemu/hw/ppc440.h
@@ -20,7 +20,7 @@
#include "exec-all.h"
#include "boards.h"
-void ppc440_init(CPUState *env,
+void ppc440ep_init(CPUState *env,
target_phys_addr_t ram_bases[2],
target_phys_addr_t ram_sizes[2],
qemu_irq **picp,
diff --git a/qemu/hw/ppc440_bamboo.c b/qemu/hw/ppc440_bamboo.c
--- a/qemu/hw/ppc440_bamboo.c
+++ b/qemu/hw/ppc440_bamboo.c
@@ -68,8 +68,7 @@ void bamboo_init(ram_addr_t ram_size, in
printf("Ram size of domain is %d bytes\n", (int)ram_size);
/* Setup CPU */
- /* XXX We cheat for now and use 405 */
- env = cpu_ppc_init("405");
+ env = cpu_ppc_init("440");
if (!env) {
fprintf(stderr, "Unable to initilize CPU!\n");
exit(1);
@@ -77,7 +76,7 @@ void bamboo_init(ram_addr_t ram_size, in
/* call init */
printf("Calling function ppc440_init\n");
- ppc440_init(env, ram_bases, ram_sizes, &pic,1);
+ ppc440ep_init(env, ram_bases, ram_sizes, &pic,1);
printf("Done calling ppc440_init\n");
/* Register mem */
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 0 of 7] [v3] PowerPC kvm-userspace patches
This set address issues disscussed by Hollis & Anthony on the second go around. As well as some minor fixes. This set of patches enables the following: -Device tree Support - Add libfdt to kvm-userspace - Add bamboo device tree to qemu source - Detection of host Device Tree attributes - Device tree loading - Ability to specify initrd on the command line - Ability to add kernel arguments on the command line - Ability to load compressed uImages - Ability to specify memory on the command line Signed-off-by: Jerone Young <[EMAIL PROTECTED]> - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 2 of 7] Add libfdt support to qemu
# HG changeset patch
# User Jerone Young <[EMAIL PROTECTED]>
# Date 1205870472 18000
# Branch merge
# Node ID aa10b5ca2f11cd571ae8a06c1e92425b7f7407ca
# Parent 499d36637c8b4fcc0cd0008186d7974bb28369ab
Add libfdt support to qemu
This patch adds needed configuration options to compile in libfdt support
into qemu.
Signed-off-by: Jerone Young <[EMAIL PROTECTED]>
diff --git a/qemu/Makefile.target b/qemu/Makefile.target
--- a/qemu/Makefile.target
+++ b/qemu/Makefile.target
@@ -555,6 +555,11 @@ ifdef CONFIG_VNC_TLS
ifdef CONFIG_VNC_TLS
CPPFLAGS += $(CONFIG_VNC_TLS_CFLAGS)
LIBS += $(CONFIG_VNC_TLS_LIBS)
+endif
+
+ifdef CONFIG_LIBFDT
+LIBS += -lfdt
+DEPLIBS += libfdt.a
endif
# SCSI layer
diff --git a/qemu/configure b/qemu/configure
--- a/qemu/configure
+++ b/qemu/configure
@@ -112,6 +112,7 @@ uname_release=""
uname_release=""
curses="yes"
cpu_emulation="yes"
+device_tree_support=""
# OS specific
targetos=`uname -s`
@@ -345,6 +346,8 @@ for opt do
;;
--disable-cpu-emulation) cpu_emulation="no"
;;
+ --disable-libfdt) device_tree_support="no"
+ ;;
*) echo "ERROR: unknown option $opt"; exit 1
;;
esac
@@ -449,6 +452,7 @@ echo " --enable-uname-release=R Return
echo " --enable-uname-release=R Return R for uname -r in usermode emulation"
echo " --sparc_cpu=VBuild qemu for Sparc architecture v7, v8,
v8plus, v8plusa, v9"
echo " --disable-cpu-emulation disables use of qemu cpu emulation code"
+echo " --disable-libfdt disables use of libfdt support for device
tree"
echo ""
echo "NOTE: The object files are built at the place where configure is
launched"
exit 1
@@ -732,6 +736,31 @@ else
binsuffix="/bin"
fi
+##
+# libfdt probe
+#
+if test -z "$device_tree_support" -a \
+ "$cpu" = "powerpc"; then
+ device_tree_support="no"
+ cat > $TMPC << EOF
+#include
+/* XXX uncomment later when libfdt is built before this test */
+//int main(void) { void *fdt; return fdt_create(fdt, 1024); }
+int main (void) {return 0;}
+EOF
+# XXX for now do not try to link to libfdt and just check for header */
+# if $cc $ARCH_CFLAGS $CFLAGS $LDFLAGS -o $TMPE $TMPC -lfdt 2> /dev/null ; then
+ if $cc $ARCH_CFLAGS $CFLAGS $LDFLAGS -o $TMPE $TMPC 2> /dev/null; then
+ device_tree_support="yes"
+ else
+echo
+echo "Error: Could not find libfdt"
+echo "Make sure to have the libfdt libs and headers installed."
+echo
+exit 1
+ fi
+fi
+
echo "Install prefix$prefix"
echo "BIOS directory$prefix$datasuffix"
echo "binary directory $prefix$binsuffix"
@@ -793,6 +822,9 @@ echo "kqemu support $kqemu"
echo "kqemu support $kqemu"
echo "kvm support $kvm"
echo "CPU emulation $cpu_emulation"
+if test $cpu = "powerpc"; then
+echo "libfdt support$device_tree_support"
+fi
echo "Documentation $build_docs"
[ ! -z "$uname_release" ] && \
echo "uname -r $uname_release"
@@ -1186,6 +1218,10 @@ elif test "$target_cpu" = "ppcemb" ; the
echo "#define TARGET_ARCH \"ppcemb\"" >> $config_h
echo "#define TARGET_PPC 1" >> $config_h
echo "#define TARGET_PPCEMB 1" >> $config_h
+ if test "$device_tree_support" = "yes" ; then
+ echo "#define CONFIG_LIBFDT 1" >> $config_h
+ echo "CONFIG_LIBFDT=1" >> $config_mak
+ fi
configure_kvm
elif test "$target_cpu" = "ppc64" ; then
echo "TARGET_ARCH=ppc64" >> $config_mak
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 3 of 7] Create new load_uimage() & gunzip support to uboot loader in Qemu
# HG changeset patch
# User Jerone Young <[EMAIL PROTECTED]>
# Date 1205870472 18000
# Branch merge
# Node ID 25515e6983ba1e070cbdcb7be1527426a097048b
# Parent aa10b5ca2f11cd571ae8a06c1e92425b7f7407ca
Create new load_uimage() & gunzip support to uboot loader in Qemu
This patch adds the ability for the load address to be caputred when loading a
uImage or cuImage. It also adds a better return code as the size can be an
usigned long. This is done by creating a new function prototype and calling it
load_uimage. To keep compatibility with code already using the old load_uboot a
wrapper function has been created so current callers will not break them.
Also added is gunzip support to allow for loading of uimages with a compressed
kenrel images.
Signed-off-by: Jerone Young <[EMAIL PROTECTED]>
diff --git a/qemu/loader.c b/qemu/loader.c
--- a/qemu/loader.c
+++ b/qemu/loader.c
@@ -26,6 +26,8 @@
#include "sysemu.h"
#include "uboot_image.h"
+#include
+
/* return the size or -1 if error */
int get_image_size(const char *filename)
{
@@ -263,14 +265,106 @@ static void bswap_uboot_header(uboot_ima
}
/* Load a U-Boot image. */
-int load_uboot(const char *filename, target_ulong *ep, int *is_linux)
-{
-
+
+/* gunzip functionality is derived from gunzip function
+ * in uboot source code
+ */
+
+#defineZALLOC_ALIGNMENT16
+
+static void *zalloc(void *x, unsigned items, unsigned size)
+{
+ void *p;
+
+ size *= items;
+ size = (size + ZALLOC_ALIGNMENT - 1) & ~(ZALLOC_ALIGNMENT - 1);
+
+ p = malloc (size);
+
+ return (p);
+}
+
+static void zfree(void *x, void *addr, unsigned nb)
+{
+ free (addr);
+}
+
+
+#define HEAD_CRC 2
+#define EXTRA_FIELD4
+#define ORIG_NAME 8
+#define COMMENT0x10
+#define RESERVED 0xe0
+
+#define DEFLATED 8
+
+static int gunzip(void *dst, int dstlen, unsigned char *src,
+ unsigned long *lenp)
+{
+ z_stream s;
+ int r, i, flags;
+
+ /* skip header */
+ i = 10;
+ flags = src[3];
+ if (src[2] != DEFLATED || (flags & RESERVED) != 0) {
+ puts ("Error: Bad gzipped data\n");
+ return -1;
+ }
+ if ((flags & EXTRA_FIELD) != 0)
+ i = 12 + src[10] + (src[11] << 8);
+ if ((flags & ORIG_NAME) != 0)
+ while (src[i++] != 0)
+ ;
+ if ((flags & COMMENT) != 0)
+ while (src[i++] != 0)
+ ;
+ if ((flags & HEAD_CRC) != 0)
+ i += 2;
+ if (i >= *lenp) {
+ puts ("Error: gunzip out of data in header\n");
+ return -1;
+ }
+
+ s.zalloc = zalloc;
+ s.zfree = zfree;
+
+ r = inflateInit2(&s, -MAX_WBITS);
+ if (r != Z_OK) {
+ printf ("Error: inflateInit2() returned %d\n", r);
+ return (-1);
+ }
+ s.next_in = src + i;
+ s.avail_in = *lenp - i;
+ s.next_out = dst;
+ s.avail_out = dstlen;
+ r = inflate(&s, Z_FINISH);
+ if (r != Z_OK && r != Z_STREAM_END) {
+ printf ("Error: inflate() returned %d\n", r);
+ return -1;
+ }
+ *lenp = s.next_out - (unsigned char *) dst;
+ inflateEnd(&s);
+
+ return 0;
+}
+
+
+#define MAX_KERNEL_SIZE 8*1024*1024 //8MB
+/* This functions can load uImage & cuImage files */
+int load_uimage(const char *filename, target_ulong *ep,
+ target_ulong *load_address,
+ target_ulong *loaded_image_size,
+ int *is_linux)
+{
int fd;
int size;
+int ret;
uboot_image_header_t h;
uboot_image_header_t *hdr = &h;
uint8_t *data = NULL;
+uint8_t *uncompressed_data = NULL;
+unsigned long tmp_loaded_image_size;
fd = open(filename, O_RDONLY | O_BINARY);
if (fd < 0)
@@ -291,13 +385,14 @@ int load_uboot(const char *filename, tar
goto fail;
}
-/* TODO: Implement compressed images. */
-if (hdr->ih_comp != IH_COMP_NONE) {
-fprintf(stderr, "Unable to load compressed u-boot images\n");
+/* TODO bzip2 support */
+if (hdr->ih_comp == IH_COMP_BZIP2) {
+fprintf(stderr, "Unable to load bzip2 compressed u-boot images\n");
goto fail;
}
/* TODO: Check CPU type. */
+
if (is_linux) {
if (hdr->ih_type == IH_TYPE_KERNEL && hdr->ih_os == IH_OS_LINUX)
*is_linux = 1;
@@ -306,6 +401,7 @@ int load_uboot(const char *filename, tar
}
*ep = hdr->ih_ep;
+
data = qemu_malloc(hdr->ih_size);
if (!data)
goto fail;
@@ -315,9 +411,36 @@ int load_uboot(const char *filename, tar
goto fail;
}
-cpu_physical_memory_write_rom(hdr->ih_load, data, hdr->ih_size);
-
-return hdr->ih_size;
+tmp_loaded_image_size = hdr->ih_size;
+
+if (hdr->ih_comp == IH_COMP_GZIP) {
+ uncompressed_data = qemu_malloc(MAX_KERNEL_S
[kvm-devel] [PATCH 5 of 7] Add dynamic device tree manipulation & change uboot loader for PPC bamboo board model
# HG changeset patch
# User Jerone Young <[EMAIL PROTECTED]>
# Date 1205870472 18000
# Branch merge
# Node ID 3e87db599895937824b9bf3369eb67ea7f5a7595
# Parent ba2876c3e8916ba9c19b75c4464cbb8dc6858fbd
Add dynamic device tree manipulation & change uboot loader for PPC bamboo board
model
This patch adds code to dynamically manipulate the device tree when loaded into
memory. This allows us to finally have the ability to manipulate the kernel
command line & initrd from the qemu command line. This will also let us setup
different settings for the board.
This patch also now uses new uboot loader load_image() to load kernel image.
Signed-off-by: Jerone Young <[EMAIL PROTECTED]>
diff --git a/qemu/Makefile.target b/qemu/Makefile.target
--- a/qemu/Makefile.target
+++ b/qemu/Makefile.target
@@ -617,7 +617,7 @@ OBJS+= unin_pci.o ppc_chrp.o
OBJS+= unin_pci.o ppc_chrp.o
# PowerPC 4xx boards
OBJS+= pflash_cfi02.o ppc4xx_devs.o ppc405_uc.o ppc405_boards.o
-OBJS+= ppc440.o ppc440_bamboo.o
+OBJS+= ppc440.o ppc440_bamboo.o device_tree.o
endif
ifeq ($(TARGET_BASE_ARCH), mips)
OBJS+= mips_r4k.o mips_malta.o mips_pica61.o mips_mipssim.o
diff --git a/qemu/hw/device_tree.c b/qemu/hw/device_tree.c
new file mode 100644
--- /dev/null
+++ b/qemu/hw/device_tree.c
@@ -0,0 +1,181 @@
+/*
+ * Functions to help device tree manipulation using libfdt.
+ * It also provides functions to read entries from device tree proc
+ * interface.
+ *
+ * Copyright 2008 IBM Corporation.
+ * Authors: Jerone Young <[EMAIL PROTECTED]>
+ *
+ * This work is licensed under the GNU GPL license version 2 or later.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "config.h"
+#include "ppc440.h"
+
+#ifdef CONFIG_LIBFDT
+ #include "libfdt.h"
+#endif
+
+#define DT_PROC_INTERFACE_PATH "/proc/device-tree"
+
+/* FUNCTIONS FOR READING FROM DEVICE TREE OF HOST IN /PROC */
+
+/* This function reads device-tree property files that are of
+ * a single cell size
+ */
+uint32_t read_proc_dt_prop_cell(char *path_in_device_tree)
+{
+ char *buf = NULL;
+ int i;
+ uint32_t num;
+ FILE *stream;
+
+ i = snprintf(buf, 0, "%s/%s", DT_PROC_INTERFACE_PATH,
+ path_in_device_tree);
+
+ buf = (char *)malloc(i);
+ if (buf == NULL)
+ {
+ printf("%s: Unable to malloc string buffer buf\n",
+ __func__);
+ exit(1);
+ }
+
+ i = snprintf(buf, i+1, "%s/%s", DT_PROC_INTERFACE_PATH,
+ path_in_device_tree);
+
+ stream = fopen(buf, "rb");
+
+ if (stream == NULL)
+ {
+ printf("%s: Unable to open '%s'\n", __func__, buf);
+ exit(1);
+ }
+
+ fread(&num, sizeof(num), 1, stream);
+ fclose(stream);
+
+ return num;
+}
+
+/* FUNCTIONS FOR LOADING & MANIPULATION OF DEVICE TREE IN GUEST */
+
+#ifdef CONFIG_LIBFDT
+/* support functions */
+static int get_offset_of_node(void *fdt, char *node_path)
+{
+ int node_offset;
+ node_offset = fdt_path_offset(fdt, node_path);
+ if (node_offset < 0) {
+ printf("Unable to find node in device tree '%s'\n",
+ node_path);
+ exit(1);
+ }
+ return node_offset;
+}
+
+/* public functions */
+void *load_device_tree(char *filename_path, unsigned long load_addr)
+{
+ int dt_file_size;
+ int dt_file_load_size;
+ int new_dt_size;int ret;
+ void *dt_file = NULL;
+ void *fdt;
+
+ dt_file_size = get_image_size(filename_path);
+ if (dt_file_size < 0) {
+ printf("Unable to get size of device tree file");
+ goto fail;
+ }
+
+ /* First allocate space in qemu for device tree */
+ dt_file = qemu_malloc(dt_file_size);
+ if (dt_file == NULL) {
+ printf("Unable to allocate memory in qemu for device tree\n");
+ goto fail;
+ }
+ memset(dt_file, 0, dt_file_size);
+
+ dt_file_load_size = load_image(filename_path, dt_file);
+
+
+ /* XXX Second we place new copy of 2x size in guest memory
+* This give us enough room for manipulation.
+*/
+ new_dt_size = dt_file_size * 2;
+
+ fdt = (void *)load_addr;
+
+ ret = fdt_open_into(dt_file, fdt, new_dt_size);
+ if (ret) {
+ printf("Unable to copy device tree in memory\n");
+ goto fail;
+ }
+
+ /* Check sanity of device tree */
+ if (fdt_check_header(fdt)) {
+ printf ("Device tree file loaded into memory is invalid: %s\n",
+ filename_path);
+ goto fail;
+ }
+ /* free qemu memory with old device tree */
+ qemu_free(dt_file);
+ return fdt;
+
+fail:
+ if (dt_file)
+ qemu_free(dt_file);
+ return NULL;
+}
+
+void dump_device_tree_to_file(void *fdt, char *f
[kvm-devel] [PATCH 7 of 7] Add ability to specify ram on command line for bamboo board model
# HG changeset patch
# User Jerone Young <[EMAIL PROTECTED]>
# Date 1205870472 18000
# Branch merge
# Node ID 4f90f7d25186f55bfb1503764af5264201df067f
# Parent ac0fc9dfd78d2eddd083326e9b635a9286fc3b19
Add ability to specify ram on command line for bamboo board model
This patch adds the ability to now specify ram sizes on the command line.
Due to the nature of the code there are restictions on exactly how
much ram and the multiple that the size must match.
Signed-off-by: Jerone Young <[EMAIL PROTECTED]>
diff --git a/qemu/hw/ppc440_bamboo.c b/qemu/hw/ppc440_bamboo.c
--- a/qemu/hw/ppc440_bamboo.c
+++ b/qemu/hw/ppc440_bamboo.c
@@ -15,6 +15,9 @@
#define BINARY_DEVICE_TREE_FILE "bamboo.dtb"
+#define bytes_to_mb(a) (a>>20)
+#define mb_to_bytes(a) (a<<20)
+
/* PPC 440 refrence demo board
*
* 440 PowerPC CPU
@@ -28,7 +31,7 @@ void bamboo_init(ram_addr_t ram_size, in
const char *cpu_model)
{
char buf[1024];
- target_phys_addr_t ram_bases[2], ram_sizes[2];
+ target_phys_addr_t ram_bases[2], ram_sizes[2];
qemu_irq *pic;
CPUState *env;
target_ulong ep=0;
@@ -40,32 +43,39 @@ void bamboo_init(ram_addr_t ram_size, in
target_ulong dt_base=0;
void *fdt;
int ret;
+ int ram_stick_sizes[] = {256, 128, 64, 32, 16, 8 }; /* in Mega bytes */
+ ram_addr_t tmp_ram_size;
+ int i=0, k=0;
uint32_t cpu_freq;
uint32_t timebase_freq;
printf("%s: START\n", __func__);
- /* Setup Memory */
- if (ram_size) {
- printf("Ram size specified on command line is %i bytes\n",
- (int)ram_size);
- printf("WARNING: RAM is hard coded to 144MB\n");
- }
- else {
- printf("Using defualt ram size of %iMB\n",
- ((int)ram_size/1024)/1024);
+ /* Setup Memory */
+ printf("Ram size passed is: %i MB\n",
+ bytes_to_mb((int)ram_size));
+
+ tmp_ram_size = ram_size;
+
+ for (i=0; i < (sizeof(ram_sizes)/sizeof(ram_sizes[0])); i++)
+ {
+ for (k=0; k <
(sizeof(ram_stick_sizes)/sizeof(ram_stick_sizes[0])); k++)
+ {
+ if ((bytes_to_mb(ram_size)/ram_stick_sizes[k]) > 0)
+ {
+ ram_sizes[i] = mb_to_bytes(ram_stick_sizes[k]);
+ tmp_ram_size -= mb_to_bytes(ram_stick_sizes[k]);
+ break;
+ }
+ }
}
- /* Each bank can only have memory in configurations of
-* 16MB, 32MB, 64MB, 128MB, or 256MB
-*/
- ram_bases[0] = 0x0;
- ram_sizes[0] = 0x0800;
- ram_bases[1] = 0x0;
- ram_sizes[1] = 0x0100;
-
- printf("Ram size of domain is %d bytes\n", (int)ram_size);
+ if (tmp_ram_size) {
+ printf("WARNING: %i MB left over memory is ram\n",
+ bytes_to_mb((int)tmp_ram_size));
+ ram_size -= tmp_ram_size;
+ }
/* Setup CPU */
env = cpu_ppc_init("440");
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [ANNOUNCE] kvm-driver-disc-20080318
david ahern wrote: > Are you interested in collecting ports of the drivers for various > distributions? > What we would like to do, is have the kvm-guest-drivers-linux.git tree autogenerate backports for as far back as we need them. Posting what you needed to do for RHEL4 would be helpful. What would be most helpful is actually submitting a patch to that repo that did the awk/cpp magic to generate the backport. Regards, Anthony Liguori > I have the virtio drivers working with RHEL4. The virtio_net appears to be > working better than e1000 for the workload I am testing with (though I still > the > need the noapic boot option). The virtio_blk driver mostly works (the VM > freezes from time and time which gdb and strace seem to clear); its > performance > so far lags the scsi driver. > > david > > > Avi Kivity wrote: > >> This is the first release of the kvm drivers disc -- a collection of kvm >> guest drivers packaged as an ISO 9660 CD-ROM for easy installation. >> >> The driver disc can be obtained from the kvm download page, below. >> >> Initial release: >> - kvm-guest-drivers-linux-1 >> - kvm-guest-drivers-windows-1 >> >> http://kvm.qumranet.com >> >> > > - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > ___ > kvm-devel mailing list > kvm-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/kvm-devel > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [ANNOUNCE] kvm-driver-disc-20080318
Are you interested in collecting ports of the drivers for various distributions? I have the virtio drivers working with RHEL4. The virtio_net appears to be working better than e1000 for the workload I am testing with (though I still the need the noapic boot option). The virtio_blk driver mostly works (the VM freezes from time and time which gdb and strace seem to clear); its performance so far lags the scsi driver. david Avi Kivity wrote: > This is the first release of the kvm drivers disc -- a collection of kvm > guest drivers packaged as an ISO 9660 CD-ROM for easy installation. > > The driver disc can be obtained from the kvm download page, below. > > Initial release: > - kvm-guest-drivers-linux-1 > - kvm-guest-drivers-windows-1 > > http://kvm.qumranet.com > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] vmwarevga merge clash
Avi Kivity wrote: > Trying to merge qemu-cvs, there's a conflict in vmwarevga between two > changes that appear to be identical in purpose, only implemented > differently: 6d262b07a2046ed1fa0ec3fd61f00efbfcd5a9ef (master) and > 5aa90452c52e3a914e1f6bbf34331507fd7c5d52 (qemu-cvs). > > I think the correct action is to drop the local changes and accept the > qemu-cvs commit. Can you confirm? qemu cvs still sets the BAR registers which KVM didn't seem to like. However, I believe that what is in QEMU CVS is correct and that removing explicit BAR register setting is simply hiding a KVM bug. I'd suggest dropping the local changes and I'll investigate further. Regards, Anthony Liguori - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Fix sci irq set when acpi timer about to wrap
On Sun, 2008-03-16 at 19:08 +0200, Avi Kivity wrote: > Dor Laor wrote: > > >From 498f162fc9d9fb897c756273c481101a44a220de Mon Sep 17 00:00:00 2001 > > From: Dor Laor <[EMAIL PROTECTED]> > > Date: Thu, 13 Mar 2008 00:11:41 +0200 > > Subject: [PATCH] Fix sci irq set when acpi timer about to wrap. > > > > The acpi timer should generate sci irq when enabled and > > when bit 23 of the timer counter toogles. > > It fixes time reading by the performance counter api of windows guest. > > > > > > How does this relate to ce35c9534137b71327466fa9abc243cbe2d7e8dc? > It was buggy with the above commit. The code not only fix it but also makes it more readable. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [ANNOUNCE] kvm-guest-drivers-windows-1
Ian Kirk wrote: > Avi Kivity wrote: > > >> This is the first release of network drivers for Windows guests running >> on a kvm host. >> > > Any plans for Windows Server IIUC the XP drivers should also work for Windows 2003 Server. Windows 2008 Server and x64 variants are planned. > and block support? > No plans at this point. SCSI emulation should provide decent performance. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [ANNOUNCE] kvm-guest-drivers-windows-1
Ian, XP drivers are also supported on Win2003 server. Best regards, Yan Vugenfirer. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Kirk Sent: ג 18 מרץ 2008 17:19 To: Avi Kivity Cc: KVM Subject: Re: [kvm-devel] [ANNOUNCE] kvm-guest-drivers-windows-1 Avi Kivity wrote: > This is the first release of network drivers for Windows guests running > on a kvm host. Any plans for Windows Server and block support? - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [ANNOUNCE] kvm-driver-disc-20080318
This is the first release of the kvm drivers disc -- a collection of kvm guest drivers packaged as an ISO 9660 CD-ROM for easy installation. The driver disc can be obtained from the kvm download page, below. Initial release: - kvm-guest-drivers-linux-1 - kvm-guest-drivers-windows-1 http://kvm.qumranet.com -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [patch 17/24] QEMU/KVM: add cpu_unregister_io_memory and make io mem table index dynamic
Amit Shah wrote: > > > > So does the following fix the problem? > > > Yes, it does. Thanks. > Okay, applied. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [ANNOUNCE] kvm-guest-drivers-windows-1
Avi Kivity wrote: > This is the first release of network drivers for Windows guests running > on a kvm host. Any plans for Windows Server and block support? - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [ANNOUNCE] kvm-guest-drivers-windows-1
Daniel P. Berrange wrote: > On Tue, Mar 18, 2008 at 05:01:09PM +0200, Avi Kivity wrote: > >> This is the first release of network drivers for Windows guests running >> on a kvm host. The drivers are intended for Windows 2000 and Windows XP >> 32-bit. kvm-61 or later is needed in the host. At the moment only >> binaries are available. >> > > There's no license file inside the ZIP file - what license are the binaries > re-distributed under ? > > Good question. I'll find out. I imagine they'd be freely redistributable. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [ANNOUNCE] kvm-guest-drivers-windows-1
On Tue, Mar 18, 2008 at 05:01:09PM +0200, Avi Kivity wrote: > This is the first release of network drivers for Windows guests running > on a kvm host. The drivers are intended for Windows 2000 and Windows XP > 32-bit. kvm-61 or later is needed in the host. At the moment only > binaries are available. There's no license file inside the ZIP file - what license are the binaries re-distributed under ? Regards, Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [ANNOUNCE] kvm-guest-drivers-windows-1
This is the first release of network drivers for Windows guests running on a kvm host. The drivers are intended for Windows 2000 and Windows XP 32-bit. kvm-61 or later is needed in the host. At the moment only binaries are available. The drivers are available from the download page of the kvm website, below. To use, download the drivers into the guest (using one of the emulated network cards), and unpack the package. Reboot with '-net nic,model=virtio' instead of the usual setting, and when Windows prompts you for a driver location, select the appropriate directory in the package (Windows XP or Windows 2000). Initial release: - kvm network drivers for Windows 2000 and Windows XP (Yan Vugenfirer, Dor Laor) http://kvm.qumranet.com/ -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [patch 17/24] QEMU/KVM: add cpu_unregister_io_memory and make io mem table index dynamic
* Marcelo Tosatti wrote: > On Tue, Mar 18, 2008 at 06:02:10PM +0530, Amit Shah wrote: > > This patch broke -no-kvm-irqchip: ... > Hi Amit, > > There is no need to zero io_mem_used since its in the BSS. The loop in > io_mem_init() was meant to allocate the slots from 0 to 4, not free > them. Of course. > So does the following fix the problem? > > diff --git a/qemu/exec.c b/qemu/exec.c > index edeb21a..e5199cf 100644 > --- a/qemu/exec.c > +++ b/qemu/exec.c > @@ -2519,7 +2519,7 @@ static void io_mem_init(void) > cpu_register_io_memory(IO_MEM_UNASSIGNED >> IO_MEM_SHIFT, > unassigned_mem_re cpu_register_io_memory(IO_MEM_NOTDIRTY >> > IO_MEM_SHIFT, error_mem_read, not for (i=0; i<5; i++) - > io_mem_used[i] = 0; > +io_mem_used[i] = 1; > > #if defined(CONFIG_SOFTMMU) > io_mem_watch = cpu_register_io_memory(-1, watch_mem_read, Yes, it does. Thanks. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [patch 17/24] QEMU/KVM: add cpu_unregister_io_memory and make io mem table index dynamic
On Tue, Mar 18, 2008 at 06:02:10PM +0530, Amit Shah wrote:
> This patch broke -no-kvm-irqchip:
>
> * On Wednesday 12 March 2008 01:42:08 Marcelo Tosatti wrote:
> > So drivers can clear their mem io table entries on exit back to unassigned
> > state.
> >
> > Also make the io mem index allocation dynamic.
> >
> > Signed-off-by: Marcelo Tosatti <[EMAIL PROTECTED]>
> >
> > Index: kvm-userspace.hotplug2/qemu/cpu-all.h
> > ===
> > --- kvm-userspace.hotplug2.orig/qemu/cpu-all.h
> > +++ kvm-userspace.hotplug2/qemu/cpu-all.h
> > @@ -837,6 +837,7 @@ int cpu_register_io_memory(int io_index,
> > CPUReadMemoryFunc **mem_read,
> > CPUWriteMemoryFunc **mem_write,
> > void *opaque);
> > +void cpu_unregister_io_memory(int table_address);
> > CPUWriteMemoryFunc **cpu_get_io_memory_write(int io_index);
> > CPUReadMemoryFunc **cpu_get_io_memory_read(int io_index);
> >
> > Index: kvm-userspace.hotplug2/qemu/exec.c
> > ===
> > --- kvm-userspace.hotplug2.orig/qemu/exec.c
> > +++ kvm-userspace.hotplug2/qemu/exec.c
> > @@ -158,7 +158,7 @@ PhysPageDesc **l1_phys_map;
> > CPUWriteMemoryFunc *io_mem_write[IO_MEM_NB_ENTRIES][4];
> > CPUReadMemoryFunc *io_mem_read[IO_MEM_NB_ENTRIES][4];
> > void *io_mem_opaque[IO_MEM_NB_ENTRIES];
> > -static int io_mem_nb;
> > +char io_mem_used[IO_MEM_NB_ENTRIES];
> > #if defined(CONFIG_SOFTMMU)
> > static int io_mem_watch;
> > #endif
> > @@ -2498,12 +2498,28 @@ static void *subpage_init (target_phys_a
> > return mmio;
> > }
> >
> > +static int get_free_io_mem_idx(void)
> > +{
> > +int i;
> > +
> > +for (i = 0; i > +if (!io_mem_used[i]) {
> > +io_mem_used[i] = 1;
> > +return i;
> > +}
> > +
> > +return -1;
> > +}
> > +
> > static void io_mem_init(void)
> > {
> > +int i;
> > +
> > cpu_register_io_memory(IO_MEM_ROM >> IO_MEM_SHIFT, error_mem_read,
> > unassigned_mem_write, NULL); cpu_register_io_memory(IO_MEM_UNASSIGNED >>
> > IO_MEM_SHIFT, unassigned_mem_read, unassigned_mem_write, NULL);
> > cpu_register_io_memory(IO_MEM_NOTDIRTY >> IO_MEM_SHIFT, error_mem_read,
> > notdirty_mem_write, NULL); -io_mem_nb = 5;
> > +for (i=0; i<5; i++)
> > +io_mem_used[i] = 0;
>
> The remaining bits (5..IO_MEM_NB_ENTRIES) aren't initialised.
>
> >
> > #if defined(CONFIG_SOFTMMU)
> > io_mem_watch = cpu_register_io_memory(-1, watch_mem_read,
> > @@ -2530,9 +2546,9 @@ int cpu_register_io_memory(int io_index,
> > int i, subwidth = 0;
> >
> > if (io_index <= 0) {
> > -if (io_mem_nb >= IO_MEM_NB_ENTRIES)
> > -return -1;
> > -io_index = io_mem_nb++;
> > +io_index = get_free_io_mem_idx();
> > +if (io_index == -1)
> > +return io_index;
>
> io_mem_nb was initialised to 5 earlier; we now trample over the first 0..4
> bits.
>
> This fixes the issue; please check for correctness.
>
> From: Amit Shah <[EMAIL PROTECTED]>
> Date: Tue, 18 Mar 2008 18:01:05 +0530
> Subject: [PATCH] QEMU/KVM: fix initialization of IO memory regions
>
> Signed-off-by: Amit Shah <[EMAIL PROTECTED]>
> ---
> qemu/exec.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/qemu/exec.c b/qemu/exec.c
> index edeb21a..be15433 100644
> --- a/qemu/exec.c
> +++ b/qemu/exec.c
> @@ -2502,7 +2502,7 @@ static int get_free_io_mem_idx(void)
> {
> int i;
>
> -for (i = 0; i +for (i = 5; i if (!io_mem_used[i]) {
> io_mem_used[i] = 1;
> return i;
> @@ -2518,7 +2518,7 @@ static void io_mem_init(void)
> cpu_register_io_memory(IO_MEM_ROM >> IO_MEM_SHIFT, error_mem_read,
> unassigned_mem_write, NULL);
> cpu_register_io_memory(IO_MEM_UNASSIGNED >> IO_MEM_SHIFT,
> unassigned_mem_read, unassigned_mem_write, NULL);
> cpu_register_io_memory(IO_MEM_NOTDIRTY >> IO_MEM_SHIFT, error_mem_read,
> notdirty_mem_write, NULL);
> -for (i=0; i<5; i++)
> +for (i=5; i io_mem_used[i] = 0;
>
> #if defined(CONFIG_SOFTMMU)
Hi Amit,
There is no need to zero io_mem_used since its in the BSS. The loop in
io_mem_init() was meant to allocate the slots from 0 to 4, not free
them.
So does the following fix the problem?
diff --git a/qemu/exec.c b/qemu/exec.c
index edeb21a..e5199cf 100644
--- a/qemu/exec.c
+++ b/qemu/exec.c
@@ -2519,7 +2519,7 @@ static void io_mem_init(void)
cpu_register_io_memory(IO_MEM_UNASSIGNED >> IO_MEM_SHIFT,
unassigned_mem_re cpu_register_io_memory(IO_MEM_NOTDIRTY >> IO_MEM_SHIFT,
error_mem_read, not for (i=0; i<5; i++)
-io_mem_used[i] = 0;
+io_mem_used[i] = 1;
#if defined(CONFIG_SOFTMMU)
io_mem_watch = cpu_register_io_memory(-1, watch_mem_read,
-
This SF.net email is sponsored b
Re: [kvm-devel] [patch 17/24] QEMU/KVM: add cpu_unregister_io_memory and make io mem table index dynamic
This patch broke -no-kvm-irqchip:
* On Wednesday 12 March 2008 01:42:08 Marcelo Tosatti wrote:
> So drivers can clear their mem io table entries on exit back to unassigned
> state.
>
> Also make the io mem index allocation dynamic.
>
> Signed-off-by: Marcelo Tosatti <[EMAIL PROTECTED]>
>
> Index: kvm-userspace.hotplug2/qemu/cpu-all.h
> ===
> --- kvm-userspace.hotplug2.orig/qemu/cpu-all.h
> +++ kvm-userspace.hotplug2/qemu/cpu-all.h
> @@ -837,6 +837,7 @@ int cpu_register_io_memory(int io_index,
> CPUReadMemoryFunc **mem_read,
> CPUWriteMemoryFunc **mem_write,
> void *opaque);
> +void cpu_unregister_io_memory(int table_address);
> CPUWriteMemoryFunc **cpu_get_io_memory_write(int io_index);
> CPUReadMemoryFunc **cpu_get_io_memory_read(int io_index);
>
> Index: kvm-userspace.hotplug2/qemu/exec.c
> ===
> --- kvm-userspace.hotplug2.orig/qemu/exec.c
> +++ kvm-userspace.hotplug2/qemu/exec.c
> @@ -158,7 +158,7 @@ PhysPageDesc **l1_phys_map;
> CPUWriteMemoryFunc *io_mem_write[IO_MEM_NB_ENTRIES][4];
> CPUReadMemoryFunc *io_mem_read[IO_MEM_NB_ENTRIES][4];
> void *io_mem_opaque[IO_MEM_NB_ENTRIES];
> -static int io_mem_nb;
> +char io_mem_used[IO_MEM_NB_ENTRIES];
> #if defined(CONFIG_SOFTMMU)
> static int io_mem_watch;
> #endif
> @@ -2498,12 +2498,28 @@ static void *subpage_init (target_phys_a
> return mmio;
> }
>
> +static int get_free_io_mem_idx(void)
> +{
> +int i;
> +
> +for (i = 0; i +if (!io_mem_used[i]) {
> +io_mem_used[i] = 1;
> +return i;
> +}
> +
> +return -1;
> +}
> +
> static void io_mem_init(void)
> {
> +int i;
> +
> cpu_register_io_memory(IO_MEM_ROM >> IO_MEM_SHIFT, error_mem_read,
> unassigned_mem_write, NULL); cpu_register_io_memory(IO_MEM_UNASSIGNED >>
> IO_MEM_SHIFT, unassigned_mem_read, unassigned_mem_write, NULL);
> cpu_register_io_memory(IO_MEM_NOTDIRTY >> IO_MEM_SHIFT, error_mem_read,
> notdirty_mem_write, NULL); -io_mem_nb = 5;
> +for (i=0; i<5; i++)
> +io_mem_used[i] = 0;
The remaining bits (5..IO_MEM_NB_ENTRIES) aren't initialised.
>
> #if defined(CONFIG_SOFTMMU)
> io_mem_watch = cpu_register_io_memory(-1, watch_mem_read,
> @@ -2530,9 +2546,9 @@ int cpu_register_io_memory(int io_index,
> int i, subwidth = 0;
>
> if (io_index <= 0) {
> -if (io_mem_nb >= IO_MEM_NB_ENTRIES)
> -return -1;
> -io_index = io_mem_nb++;
> +io_index = get_free_io_mem_idx();
> +if (io_index == -1)
> +return io_index;
io_mem_nb was initialised to 5 earlier; we now trample over the first 0..4
bits.
This fixes the issue; please check for correctness.
From: Amit Shah <[EMAIL PROTECTED]>
Date: Tue, 18 Mar 2008 18:01:05 +0530
Subject: [PATCH] QEMU/KVM: fix initialization of IO memory regions
Signed-off-by: Amit Shah <[EMAIL PROTECTED]>
---
qemu/exec.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/qemu/exec.c b/qemu/exec.c
index edeb21a..be15433 100644
--- a/qemu/exec.c
+++ b/qemu/exec.c
@@ -2502,7 +2502,7 @@ static int get_free_io_mem_idx(void)
{
int i;
-for (i = 0; i> IO_MEM_SHIFT, error_mem_read,
unassigned_mem_write, NULL);
cpu_register_io_memory(IO_MEM_UNASSIGNED >> IO_MEM_SHIFT,
unassigned_mem_read, unassigned_mem_write, NULL);
cpu_register_io_memory(IO_MEM_NOTDIRTY >> IO_MEM_SHIFT, error_mem_read,
notdirty_mem_write, NULL);
-for (i=0; i<5; i++)
+for (i=5; ihttp://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 0/3 - resend] kvmclock reboot
Avi Kivity wrote: > Glauber Costa wrote: >>> >>> [Once a patchset has been applied and pushed (as seen on >>> kvm-commits), I prefer incremental patches] >>> >> But I think this is a very good case of an exception, since the >> applied patches would break bisect. I prefer to hear "damn glommer!" >> because of that than "damn glommer!!" because of a broken bisect. > > I fold them up before sending to Linus anyway, so upstream bisect > continues to work. For kvm.git, it's a choice between rewinding it a > bit (which may confuse anyone who pulls) and breaking bisect. > > ok, this wfm. I'll send incrementally next time. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 0/3 - resend] kvmclock reboot
Glauber Costa wrote: >> >> [Once a patchset has been applied and pushed (as seen on >> kvm-commits), I prefer incremental patches] >> > But I think this is a very good case of an exception, since the > applied patches would break bisect. I prefer to hear "damn glommer!" > because of that than "damn glommer!!" because of a broken bisect. I fold them up before sending to Linus anyway, so upstream bisect continues to work. For kvm.git, it's a choice between rewinding it a bit (which may confuse anyone who pulls) and breaking bisect. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 0/3 - resend] kvmclock reboot
Avi Kivity wrote: > Glauber Costa wrote: >> Avi, >> >> Hope this series is okay now. >> >> Thanks for the testing >> >> >> > > Applied, thanks. > > [Once a patchset has been applied and pushed (as seen on kvm-commits), I > prefer incremental patches] > But I think this is a very good case of an exception, since the applied patches would break bisect. I prefer to hear "damn glommer!" because of that than "damn glommer!!" because of a broken bisect. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 0/3 - resend] kvmclock reboot
Glauber Costa wrote: > Avi, > > Hope this series is okay now. > > Thanks for the testing > > > Applied, thanks. [Once a patchset has been applied and pushed (as seen on kvm-commits), I prefer incremental patches] -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 3/3] [PATCH] disable clock before rebooting.
This patch writes 0 (actually, what really matters is that the
LSB is cleared) to the system time msr before shutting down
the machine for kexec.
Without it, we can have a random memory location being written
when the guest comes back
It overrides the functions shutdown, used in the path of kernel_kexec() (sys.c)
and crash_shutdown, used in the path of crash_kexec() (kexec.c)
Signed-off-by: Glauber Costa <[EMAIL PROTECTED]>
---
arch/x86/kernel/kvmclock.c | 27 +++
1 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
index b999f5e..ddee040 100644
--- a/arch/x86/kernel/kvmclock.c
+++ b/arch/x86/kernel/kvmclock.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#define KVM_SCALE 22
@@ -143,6 +144,28 @@ static void kvm_setup_secondary_clock(void)
setup_secondary_APIC_clock();
}
+/*
+ * After the clock is registered, the host will keep writing to the
+ * registered memory location. If the guest happens to shutdown, this memory
+ * won't be valid. In cases like kexec, in which you install a new kernel, this
+ * means a random memory location will be kept being written. So before any
+ * kind of shutdown from our side, we unregister the clock by writting anything
+ * that does not have the 'enable' bit set in the msr
+ */
+#ifdef CONFIG_KEXEC
+static void kvm_crash_shutdown(struct pt_regs *regs)
+{
+ native_write_msr_safe(MSR_KVM_SYSTEM_TIME, 0, 0);
+ native_machine_crash_shutdown(regs);
+}
+#endif
+
+static void kvm_shutdown(void)
+{
+ native_write_msr_safe(MSR_KVM_SYSTEM_TIME, 0, 0);
+ native_machine_shutdown();
+}
+
void __init kvmclock_init(void)
{
if (!kvm_para_available())
@@ -155,6 +178,10 @@ void __init kvmclock_init(void)
pv_time_ops.set_wallclock = kvm_set_wallclock;
pv_time_ops.sched_clock = kvm_clock_read;
pv_apic_ops.setup_secondary_clock = kvm_setup_secondary_clock;
+ machine_ops.shutdown = kvm_shutdown;
+#ifdef CONFIG_KEXEC
+ machine_ops.crash_shutdown = kvm_crash_shutdown;
+#endif
clocksource_register(&kvm_clock);
}
}
--
1.5.0.6
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 2/3] [PATCH] make native_machine_shutdown non-static
it will allow external users to call it. It is mainly
useful for routines that will override its machine_ops
field for its own special purposes, but want to call the
normal shutdown routine after they're done
Signed-off-by: Glauber Costa <[EMAIL PROTECTED]>
---
arch/x86/kernel/reboot.c |2 +-
include/asm-x86/reboot.h |1 +
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index ea95f11..7215de6 100644
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -382,7 +382,7 @@ static void native_machine_emergency_restart(void)
}
}
-static void native_machine_shutdown(void)
+void native_machine_shutdown(void)
{
/* Stop the cpus and apics */
#ifdef CONFIG_SMP
diff --git a/include/asm-x86/reboot.h b/include/asm-x86/reboot.h
index ff9b546..c5e8722 100644
--- a/include/asm-x86/reboot.h
+++ b/include/asm-x86/reboot.h
@@ -17,5 +17,6 @@ extern struct machine_ops machine_ops;
void machine_real_restart(unsigned char *code, int length);
void native_machine_crash_shutdown(struct pt_regs *regs);
+void native_machine_shutdown(void);
#endif /* _ASM_REBOOT_H */
--
1.5.0.6
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 1/3] [PATCH] allow machine_crash_shutdown to be replaced
This patch a llows machine_crash_shutdown to
be replaced, just like any of the other functions
in machine_ops
Signed-off-by: Glauber Costa <[EMAIL PROTECTED]>
---
arch/x86/kernel/crash.c |3 ++-
arch/x86/kernel/reboot.c | 11 ++-
include/asm-x86/reboot.h |1 +
3 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index 9a5fa0a..d262306 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_X86_32
#include
@@ -121,7 +122,7 @@ static void nmi_shootdown_cpus(void)
}
#endif
-void machine_crash_shutdown(struct pt_regs *regs)
+void native_machine_crash_shutdown(struct pt_regs *regs)
{
/* This function is only called after the system
* has panicked or is otherwise in a critical state.
diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index 55ceb8c..ea95f11 100644
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -453,7 +453,10 @@ struct machine_ops machine_ops = {
.shutdown = native_machine_shutdown,
.emergency_restart = native_machine_emergency_restart,
.restart = native_machine_restart,
- .halt = native_machine_halt
+ .halt = native_machine_halt,
+#ifdef CONFIG_KEXEC
+ .crash_shutdown = native_machine_crash_shutdown,
+#endif
};
void machine_power_off(void)
@@ -481,3 +484,9 @@ void machine_halt(void)
machine_ops.halt();
}
+#ifdef CONFIG_KEXEC
+void machine_crash_shutdown(struct pt_regs *regs)
+{
+ machine_ops.crash_shutdown(regs);
+}
+#endif
diff --git a/include/asm-x86/reboot.h b/include/asm-x86/reboot.h
index e9e3ffc..ff9b546 100644
--- a/include/asm-x86/reboot.h
+++ b/include/asm-x86/reboot.h
@@ -16,5 +16,6 @@ struct machine_ops
extern struct machine_ops machine_ops;
void machine_real_restart(unsigned char *code, int length);
+void native_machine_crash_shutdown(struct pt_regs *regs);
#endif /* _ASM_REBOOT_H */
--
1.5.0.6
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 0/3 - resend] kvmclock reboot
Avi, Hope this series is okay now. Thanks for the testing - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] use slots_lock to protect writes to the wall clock
Glauber Costa wrote: > >>> [EMAIL PROTECTED] linux-2.6 (master)]$ git grep down_read.*slots_lock >>> arch/x86/kvm/ | wc -l >>> 16 >> >> We take the lock for read 16 times, could be narrowed down to >> probably once (with a drop and re-take around guest mode). > > Since it will be written to so rarely, that's probably fine. > > Moreover, the time setting up guest entry and handling exits is bounded and usually short. [We need to drop the lock when emulating hlt, too, for this to hold] -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] use slots_lock to protect writes to the wall clock
Avi Kivity wrote: > Glauber Costa wrote: >>> >>> This lock is fairly annoying. What do you think about taking it in >>> vcpu_run unconditionally and only dropping it while in guest mode? >>> Most exits are mmu (or with npt, mmio) so they need to take it anyway. >>> >> Can't see the point. This is taken before updates to the wall clock, >> not system time. > > I mean in general, not related to wall clock. Oh, sorry. >> [EMAIL PROTECTED] linux-2.6 (master)]$ git grep down_read.*slots_lock >> arch/x86/kvm/ | wc -l >> 16 > > We take the lock for read 16 times, could be narrowed down to probably > once (with a drop and re-take around guest mode). Since it will be written to so rarely, that's probably fine. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] use slots_lock to protect writes to the wall clock
Glauber Costa wrote: >> >> This lock is fairly annoying. What do you think about taking it in >> vcpu_run unconditionally and only dropping it while in guest mode? >> Most exits are mmu (or with npt, mmio) so they need to take it anyway. >> > Can't see the point. This is taken before updates to the wall clock, > not system time. I mean in general, not related to wall clock. > [EMAIL PROTECTED] linux-2.6 (master)]$ git grep down_read.*slots_lock > arch/x86/kvm/ | wc -l > 16 We take the lock for read 16 times, could be narrowed down to probably once (with a drop and re-take around guest mode). -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] use slots_lock to protect writes to the wall clock
Avi Kivity wrote: > Glauber Costa wrote: >> As Marcelo pointed out, we need slots_lock to protect >> against slots changing under our nose during wall clock >> writing. >> >> This patch address this issue. >> >> > > Applied, thanks. > > This lock is fairly annoying. What do you think about taking it in > vcpu_run unconditionally and only dropping it while in guest mode? Most > exits are mmu (or with npt, mmio) so they need to take it anyway. > Can't see the point. This is taken before updates to the wall clock, not system time. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] tools to dump guest memory and generate core file
Avi Kivity wrote: > david ahern wrote: > >> Attaching gdb to qemu you work with addresses as seen by the qemu process; >> the >> idea is to work with addresses as seen inside the guest. >> >> >> Now, if you attach gdb to the qemu process, >> >> gdb /usr/local/bin/qemu-system-x86_64 2346 >> >> > I meant connecting to the gdb stub in qemu that represents the guest: > > (gdb) target remote localhost:1234 > > Of course, it means starting qemu with the gdb stub enabled. We might > add a monitor command to start it after the fact. > gdbserver is the monitor command you're looking for: (qemu) help gdbserver gdbserver [port] -- start gdbserver session (default port=1234) - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] Законодательство о БАНКРОТСТВЕ
Aктуальные вопросы правового регулирования коммерческой деятельности в 2008г. 31 марта - 02 апреля 2008, Санкт-Петербург Программа включает следующие пункты: 1. Применение ФЗ "Об акционерных обществах", ФЗ "Об обществах с ограниченной ответственностью". Комментарии к последним изменениям законодательства и рекомендации по его применению. 2. Новое в регулировании процедур проведения эмиссии акций. Практические аспекты регистрации эмиссии акций. Оборот и оформление сделок с акциями. 3. Новое решение вопросов осуществления крупных сделок и сделок с заинтересованностью. 4. Актуальные вопросы реорганизация акционерных обществ. 5. Последняя судебно-арбитражная практика по применению законодательства об АО и ООО. 6. Применение ФЗ "О несостоятельности (банкротстве)". Основания для возбуждения дел о банкротстве. Вопросы отстранения арбитражных управляющих. Уполномоченные органы РФ в делах о банкротстве. 7. Налоговые последствия гражданско-правовых сделок. 8. Налоговые проверки в 2008 году: условия назначения, права и обязанности налоговых органов и налогоплательщика, процессуальные особенности осуществления и оформления результатов. 9. Рекомендации по защите прав налогоплательщика при проведении налоговых проверок. 10. ФЗ "О государственной регистрации прав на недвижимое имущество и сделок с ним". Арбитражная практика по вопросам государственной регистрации. Обжалование действий органов государственной регистрации недвижимости. 11. Особенности заключения, исполнения и расторжения договоров аренды недвижимости. 12. Новое в практике применения Земельного кодекса РФ и иных законодательных актов, связанных с оборотом земельных участков, разграничением прав на земельные участки, особенностями приобретения, реализации и защиты прав на земельные участки отдельных категорий. 13. Правовое регулирование труда нормами гражданского и трудового права. Проверки Государственной инспекции труда (по труду). 14. Административная ответственность за нарушения Антимонопольного законодательства РФ, законодательства РФ о рекламе. Новые тенденции. 15. Защита интеллектуальной собственности в свете части IV ГК РФ. 16. Правовое регулирование внешнеэкономической деятельности. Полная программа: (812) 983 - 290б - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] KVM Test result, kernel a16664b.., userspace 3017d05.. one new issue
Avi Kivity wrote: > Yunfeng Zhao wrote: > >> Hi All, >> This is today's KVM test result against kvm.git >> a16664b59065b8ae877b213e68a6f962ac359ca4 and kvm-userspace.git >> 3017d054a6a9f37bfffee4ebf0bf52a51c9860b5. >> >> >> One new issue: >> 1. booting smp windows guests has 30% chance of hang >> https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1910923&group_id=180599 >> >> >> > Is this a regression? What was the last known good commit? > > It should be a regression. We haven't identified which commit was the last workable commit yet. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 0/3] kvmclock: shutdown clock before reboot
Avi Kivity wrote: > Glauber Costa wrote: >> Avi, >> >> This series now apply ontop of kvm.git. >> Only the needed function from machine_ops is made non-static. >> >> > > Applied, thanks. Er, compilation breaks if CONFIG_KEXEC is not set (i386). -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] vmwarevga merge clash
Trying to merge qemu-cvs, there's a conflict in vmwarevga between two changes that appear to be identical in purpose, only implemented differently: 6d262b07a2046ed1fa0ec3fd61f00efbfcd5a9ef (master) and 5aa90452c52e3a914e1f6bbf34331507fd7c5d52 (qemu-cvs). I think the correct action is to drop the local changes and accept the qemu-cvs commit. Can you confirm? -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
