[Qemu-devel] Re: [PATCH 2/6] Use correct types to enable 2G support (v2)
On Sun, 2008-02-03 at 19:56 -0600, Anthony Liguori wrote: Hi Izik, Hi Anthony Liguori wrote: Index: qemu/cpu-all.h === --- qemu.orig/cpu-all.h 2008-02-01 15:24:45.0 -0600 +++ qemu/cpu-all.h 2008-02-01 15:28:48.0 -0600 @@ -695,7 +695,7 @@ /* page related stuff */ -#define TARGET_PAGE_SIZE (1 TARGET_PAGE_BITS) +#define TARGET_PAGE_SIZE (1ul TARGET_PAGE_BITS) #define TARGET_PAGE_MASK ~(TARGET_PAGE_SIZE - 1) #define TARGET_PAGE_ALIGN(addr) (((addr) + TARGET_PAGE_SIZE - 1) TARGET_PAGE_MASK Do you recall what this change fixed? As Paul pointed out in IRC, using the host type here doesn't really fix the problem (target_ulong would be more appropriate). However, we're both curious what problem it's actually fixing since sign extending the int should just work. ok the commit say: kvm: qemu: change the type of the various page masks to unsigned long prevents truncation with =4GB of guest physical memory as far as i remember it was used to address something with cpu_physical_memory_rw() probably related to TARGET_PAGE_SIZE or ~TARGET_PAGE_SIZE, the fact is that i dont know if it ever fixed anything
[Qemu-devel] Problems with dynticks clock
Hello, Any DOS game that I've tried eventually hangs the QEMU. GDB shows that QEMU is running in infinite loop in translated basic block and does not respond to any keyboard or mouse events. It looks like all events got lost and guest is waiting for timer update, while SDL is not getting its keyboard and mouse events from host. Could it be related to the infamous multithreading problem with events? If I start QEMU with rtc or unix clock this does not happen, or at least I never managed to trigger it. This is all on Linux host without kqemu loaded. Victor Shkamerda -- --- -- LIMITARE DE OBLIGATIUNI: Mesajele expediate din cadrul Bancii Nationale a Moldovei sunt transmise cu buna intentie si nu trebuie considerate drept obligatorii in activitatea acestei organizatii. Informatia transmisa este destinata doar pentru adresat si poate contine date confidentiale si / sau privilegiate. In caz ca primiti mesajul dat din greseala, va rugam sa contactati expeditorul si sa stergeti informatia in cauza din computerul Dvs. DISCLAIMER: Any e-mail messages from the National Bank of Moldova are sent in good faith, but shall not be binding nor construed as constituting any obligation on the part of the Bank. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you received this in error, please contact the sender and delete the material from any computer.
[Qemu-devel] qemu texi2pod.pl
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 08/02/04 14:47:50 Modified files: . : texi2pod.pl Log message: Update texi2pod.pl. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/texi2pod.pl?cvsroot=qemur1=1.2r2=1.3
Re: [kvm-devel] [Qemu-devel] [PATCH 6/6] QEMU support for the Kernel Virtual Machine interface (v2)
Hi Soren, Soren Hansen wrote: These need to move into VGA_STATE_COMMON instead. Otherwise vmware_vga will get confoozled becuase it relies on vga.c for its vesa implementation. The patch is at: http://people.ubuntu.com/~soren/0001-Move-common-VGAState-attributes-to-VGA_STATE_COMMON.patch Yes, I saw your patch on kvm-devel. It came too late to make my series but it looks like the right thing to do. Regards, Anthony Liguori /me grumbles about sourceforge's mailing list archive thing completely messing up the formatting of patches... - 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kvm-devel
[Qemu-devel] [PATCH 3/5] Fix daemonize options (v2)
The -daemonize option is too restrictive when using with SDL. It also switches
the working directory to / too early which causes block devices with a relative
path to fail.
The -daemonize option is needed for my regression testing so I've included this
patch in the series.
This patch hasn't changed since v1.
diff --git a/vl.c b/vl.c
index 7dcddf3..28d6f6c 100644
--- a/vl.c
+++ b/vl.c
@@ -8757,11 +8757,6 @@ int main(int argc, char **argv)
}
#ifndef _WIN32
-if (daemonize !nographic vnc_display == NULL) {
- fprintf(stderr, Can only daemonize if using -nographic or -vnc\n);
- daemonize = 0;
-}
-
if (daemonize) {
pid_t pid;
@@ -8799,7 +8794,6 @@ int main(int argc, char **argv)
exit(1);
umask(027);
- chdir(/);
signal(SIGTSTP, SIG_IGN);
signal(SIGTTOU, SIG_IGN);
@@ -9065,6 +9059,7 @@ int main(int argc, char **argv)
if (len != 1)
exit(1);
+ chdir(/);
TFR(fd = open(/dev/null, O_RDWR));
if (fd == -1)
exit(1);
[Qemu-devel] [PATCH 4/5] Tell BIOS about the number of CPUs (v2)
Previously, the BIOS would probe the CPUs for SMP guests. This tends to be very unreliably because of startup timing issues. By passing the number of CPUs in the CMOS, the BIOS can detect the number of CPUs much more reliably. Since v1, I've incorporated Fabrice's feedback so this is now a 1-liner. diff --git a/hw/pc.c b/hw/pc.c index 64827be..de99879 100644 --- a/hw/pc.c +++ b/hw/pc.c @@ -210,6 +210,7 @@ static void cmos_init(ram_addr_t ram_size, ram_addr_t above_4g_mem_size, rtc_set_memory(s, 0x5c, (unsigned int)above_4g_mem_size 24); rtc_set_memory(s, 0x5d, (uint64_t)above_4g_mem_size 32); } +rtc_set_memory(s, 0x5f, smp_cpus - 1); if (ram_size (16 * 1024 * 1024)) val = (ram_size / 65536) - ((16 * 1024 * 1024) / 65536);
[Qemu-devel] Re: [kvm-devel] [PATCH 1/5] Use correct types to enable 2G support (v3)
Izik Eidus wrote: On Mon, 2008-02-04 at 09:11 -0600, Anthony Liguori wrote: KVM supports more than 2GB of memory for x86_64 hosts. The following patch fixes a number of type related issues where int's were being used when they shouldn't have been. It also introduces CMOS support so the BIOS can build the appropriate e820 tables. again, you need patch the bios for this, as the bochs bios doesnt know how to map memory above 4 giga, and it doesnt know about this CMOS addresses, (look at the patch that i sent) Right, but the important point is, that in the absence of the bochs BIOS, this patch does no harm. Regards, Anthony Liguori
[Qemu-devel] Re: [PATCH 2/6] Use correct types to enable 2G support (v2)
Izik Eidus wrote: Do you recall what this change fixed? As Paul pointed out in IRC, using the host type here doesn't really fix the problem (target_ulong would be more appropriate). However, we're both curious what problem it's actually fixing since sign extending the int should just work. ok the commit say: kvm: qemu: change the type of the various page masks to unsigned long prevents truncation with =4GB of guest physical memory as far as i remember it was used to address something with cpu_physical_memory_rw() probably related to TARGET_PAGE_SIZE or ~TARGET_PAGE_SIZE, the fact is that i dont know if it ever fixed anything Thanks, that was my suspicion too. Regards, Anthony Liguori
[Qemu-devel] [PATCH 1/5] Use correct types to enable 2G support (v3)
KVM supports more than 2GB of memory for x86_64 hosts. The following patch
fixes a number of type related issues where int's were being used when they
shouldn't have been. It also introduces CMOS support so the BIOS can build
the appropriate e820 tables.
For v2 of this patch, I've moved ram_addr_t to cpu-all.h and switched
ram_size to be a ram_addr_t. I've also removed the memory limit check for
x86_64 (provided kqemu isn't enabled) and enabled the use of a 'M' or 'G'
suffix for the -m option. I've also tried to do a more thorough job of
updating the code to use the proper types.
This patch also includes support for setting up 2GB of memory for
TARGET_I386. KVM works quite happily with 5GB of ram but I suspect there
are still some uint32_t's in the non-KVM does not work when using more than
3GB of RAM.
Since v2, I got rid of an improper declaration of ram_size by moving it from
sysemu.h to cpu-all.h. I also added some code to handle wrap around in the
'-m' option. I also eliminated the unnecessary change to TARGET_PAGE_SIZE.
diff --git a/cpu-all.h b/cpu-all.h
index 7a7e655..cb03072 100644
--- a/cpu-all.h
+++ b/cpu-all.h
@@ -800,12 +800,16 @@ int cpu_inw(CPUState *env, int addr);
int cpu_inl(CPUState *env, int addr);
#endif
+/* address in the RAM (different from a physical address) */
+typedef unsigned long ram_addr_t;
+
/* memory API */
-extern int phys_ram_size;
+extern ram_addr_t phys_ram_size;
extern int phys_ram_fd;
extern uint8_t *phys_ram_base;
extern uint8_t *phys_ram_dirty;
+extern ram_addr_t ram_size;
/* physical memory access */
#define TLB_INVALID_MASK (1 3)
@@ -830,7 +834,7 @@ void cpu_register_physical_memory(target_phys_addr_t
start_addr,
unsigned long size,
unsigned long phys_offset);
uint32_t cpu_get_physical_page_desc(target_phys_addr_t addr);
-ram_addr_t qemu_ram_alloc(unsigned int size);
+ram_addr_t qemu_ram_alloc(unsigned long size);
void qemu_ram_free(ram_addr_t addr);
int cpu_register_io_memory(int io_index,
CPUReadMemoryFunc **mem_read,
diff --git a/cpu-defs.h b/cpu-defs.h
index 6979c11..60ac4c6 100644
--- a/cpu-defs.h
+++ b/cpu-defs.h
@@ -76,9 +76,6 @@ typedef uint64_t target_phys_addr_t;
#error TARGET_PHYS_ADDR_BITS undefined
#endif
-/* address in the RAM (different from a physical address) */
-typedef unsigned long ram_addr_t;
-
#define HOST_LONG_SIZE (HOST_LONG_BITS / 8)
#define EXCP_INTERRUPT 0x1 /* async interruption */
diff --git a/exec.c b/exec.c
index e9a5918..1e6ac97 100644
--- a/exec.c
+++ b/exec.c
@@ -73,6 +73,8 @@
#define TARGET_VIRT_ADDR_SPACE_BITS 42
#elif defined(TARGET_PPC64)
#define TARGET_PHYS_ADDR_SPACE_BITS 42
+#elif defined(TARGET_X86_64) !defined(USE_KQEMU)
+#define TARGET_PHYS_ADDR_SPACE_BITS 42
#else
/* Note: for compatibility with kqemu, we use 32 bits for x86_64 */
#define TARGET_PHYS_ADDR_SPACE_BITS 32
@@ -87,7 +89,7 @@ spinlock_t tb_lock = SPIN_LOCK_UNLOCKED;
uint8_t code_gen_buffer[CODE_GEN_BUFFER_SIZE] __attribute__((aligned (32)));
uint8_t *code_gen_ptr;
-int phys_ram_size;
+ram_addr_t phys_ram_size;
int phys_ram_fd;
uint8_t *phys_ram_base;
uint8_t *phys_ram_dirty;
@@ -112,7 +114,7 @@ typedef struct PageDesc {
typedef struct PhysPageDesc {
/* offset in host memory of the page + io_index in the low 12 bits */
-uint32_t phys_offset;
+ram_addr_t phys_offset;
} PhysPageDesc;
#define L2_BITS 10
@@ -1980,7 +1982,7 @@ static inline void tlb_set_dirty(CPUState *env,
static int subpage_register (subpage_t *mmio, uint32_t start, uint32_t end,
int memory);
-static void *subpage_init (target_phys_addr_t base, uint32_t *phys,
+static void *subpage_init (target_phys_addr_t base, ram_addr_t *phys,
int orig_memory);
#define CHECK_SUBPAGE(addr, start_addr, start_addr2, end_addr, end_addr2, \
need_subpage) \
@@ -2084,12 +2086,12 @@ uint32_t cpu_get_physical_page_desc(target_phys_addr_t
addr)
}
/* XXX: better than nothing */
-ram_addr_t qemu_ram_alloc(unsigned int size)
+ram_addr_t qemu_ram_alloc(unsigned long size)
{
ram_addr_t addr;
if ((phys_ram_alloc_offset + size) = phys_ram_size) {
-fprintf(stderr, Not enough memory (requested_size = %u, max memory =
%d)\n,
-size, phys_ram_size);
+fprintf(stderr, Not enough memory (requested_size = %lu, max memory =
% PRIu64 )\n,
+size, (uint64_t)phys_ram_size);
abort();
}
addr = phys_ram_alloc_offset;
@@ -2432,7 +2434,7 @@ static int subpage_register (subpage_t *mmio, uint32_t
start, uint32_t end,
return 0;
}
-static void *subpage_init (target_phys_addr_t base, uint32_t *phys,
+static void *subpage_init (target_phys_addr_t base, ram_addr_t *phys,
int orig_memory)
{
subpage_t *mmio;
diff --git
[Qemu-devel] Re: [kvm-devel] [PATCH 1/5] Use correct types to enable 2G support (v3)
On Mon, 2008-02-04 at 09:11 -0600, Anthony Liguori wrote: KVM supports more than 2GB of memory for x86_64 hosts. The following patch fixes a number of type related issues where int's were being used when they shouldn't have been. It also introduces CMOS support so the BIOS can build the appropriate e820 tables. again, you need patch the bios for this, as the bochs bios doesnt know how to map memory above 4 giga, and it doesnt know about this CMOS addresses, (look at the patch that i sent) For v2 of this patch, I've moved ram_addr_t to cpu-all.h and switched ram_size to be a ram_addr_t. I've also removed the memory limit check for x86_64 (provided kqemu isn't enabled) and enabled the use of a 'M' or 'G' suffix for the -m option. I've also tried to do a more thorough job of updating the code to use the proper types. This patch also includes support for setting up 2GB of memory for TARGET_I386. KVM works quite happily with 5GB of ram but I suspect there are still some uint32_t's in the non-KVM does not work when using more than 3GB of RAM. yes, the patch for kvm was never desgiend to solve the problems qemu would have with above 4 giga memory.
[Qemu-devel] hw/e1000.c patch for Solaris
Solaris has boolean_t defined, so this #ifndef allows hw/e1000.c to compile on Solaris. Ben --- qemu.ORIG/hw/e1000.c2008-02-02 21:20:18.0 -0500 +++ qemu/hw/e1000.c 2008-02-04 10:39:33.097052000 -0500 @@ -28,7 +28,9 @@ #include net.h #define __iomem +#ifndef __sun__ typedef int boolean_t; +#endif #include e1000_hw.h #define DEBUG
[Qemu-devel] Re: [kvm-devel] [PATCH 1/5] Use correct types to enable 2G support (v3)
On Mon, 2008-02-04 at 09:33 -0600, Anthony Liguori wrote: Izik Eidus wrote: On Mon, 2008-02-04 at 09:11 -0600, Anthony Liguori wrote: KVM supports more than 2GB of memory for x86_64 hosts. The following patch fixes a number of type related issues where int's were being used when they shouldn't have been. It also introduces CMOS support so the BIOS can build the appropriate e820 tables. again, you need patch the bios for this, as the bochs bios doesnt know how to map memory above 4 giga, and it doesnt know about this CMOS addresses, (look at the patch that i sent) Right, but the important point is, that in the absence of the bochs BIOS, this patch does no harm. yes, you are right, but beacuse that i saw that you patching the bios i thought you wanted to do it as well and just didnt see my email... Regards, Anthony Liguori
[Qemu-devel] [PATCH] fix typo in drive_init() (vl.c)
The following patch fixes a typo in drive_init().
Cheers,
--
Stuart Brady
Index: vl.c
===
RCS file: /sources/qemu/qemu/vl.c,v
retrieving revision 1.403
diff -u -r1.403 vl.c
--- vl.c3 Feb 2008 03:45:47 - 1.403
+++ vl.c4 Feb 2008 12:58:07 -
@@ -4928,7 +4928,7 @@
cache, NULL };
if (check_params(buf, sizeof(buf), params, str) 0) {
- fprintf(stderr, qemu: unknowm parameter '%s' in '%s'\n,
+ fprintf(stderr, qemu: unknown parameter '%s' in '%s'\n,
buf, str);
return -1;
}
[Qemu-devel] Fix writev syscall emulation
Hi,
OpenEmbedded/Poky use qemu for locale generation when cross compiling.
When we upgraded to qemu 0.9.1 it started giving locale generation
errors on all 64 bit machines and some 32 bit ones.
I've traced it to the writev syscall failing. localedef passes several
{ NULL, 0 } iovec entries which trip up lock_iovec(). That function is
returning an error for these but the return value isn't checked. The
syscall is therefore always made but sometimes with a iovec that has
only been half copied. If the total writes exceed size_t, EINVAL is
returned by the kernel and glibc code emulates the call with a write
which is most likely to happen on 32 bit so it sometimes works. size_t
is unlikely to be exceeded on 64 bit so that returns an EFAULT and
always corrupts/fails.
Anyhow, it seems 0 length iovec entries are allowed and we shouldn't
care about the addresses in those cases. The patch below is one way to
fix this. Ideally the return value of lock_iovec() needs be be checked
too.
Regards,
Richard
---
linux-user/syscall.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: qemu-0.9.1/linux-user/syscall.c
===
--- qemu-0.9.1.orig/linux-user/syscall.c2008-02-03 00:00:00.0
+
+++ qemu-0.9.1/linux-user/syscall.c 2008-02-03 00:00:38.0 +
@@ -1048,7 +1048,7 @@ static abi_long lock_iovec(int type, str
base = tswapl(target_vec[i].iov_base);
vec[i].iov_len = tswapl(target_vec[i].iov_len);
vec[i].iov_base = lock_user(type, base, vec[i].iov_len, copy);
- if (!vec[i].iov_base)
+ if (!vec[i].iov_base vec[i].iov_len)
goto fail;
}
unlock_user (target_vec, target_addr, 0);
Re: [Qemu-devel] @ref commands in man-page
Stuart Brady wrote:
Hi,
I've noticed that @ref{...} commands aren't handled properly in the
qemu man page -- you can see @ref{pcsys_monitor}, @ref{vnc_security} and
@ref{pcsys_keys} in the output. I'm not sure what the correct fix for
this is -- any thoughts?
texi2pod.pl fails to convert them properly, I commited an updated version.
Thiemo
[Qemu-devel] [PATCH 0/5] Support for the Kernel Virtual Machine interface (v3)
KVM is a Linux interface for providing userspace interfaces for accelerated virtualization. It has been included since 2.6.20 and supports Intel VT and AMD-V. Ports are under way for ia64, embedded PowerPC, and s390. This set of patches provide basic support for KVM in QEMU. It does not include all of the changes in the KVM QEMU branch (such as virtio, live migration, extboot, etc). However, if we can get these first portions merged, I will follow up with the remainder of the changes and I believe we can be fully merged in the very near future. The first 5 patches of this series are not KVM specific but are critical fixes for KVM to be functional. The 6th patch provides KVM support. The goal in providing KVM support is to make sure that when KVM support is not compiled in, the code paths aren't changed at all. I hope this makes it very easy to merge. KVM moves very quickly, so I'd appreciate if these patches can be reviewed as soon as possible as it's going to be tough to keep them in sync with the main KVM tree while they're out of tree. To enable KVM support, you have to have to libkvm installed. You should also explicitly specify the location of your kernel tree (with KVM headers) with the --kernel-path option. We will improve libkvm such that this isn't required in future versions. KVM also has an enhanced Bochs BIOS. I've tested these patches with out it and it's not strictly necessary for basic functionality. I would recommend pulling in a copy of it though as it has useful fixes even in the absence of KVM. A very large number of people have contributed to these patches with Avi Kivity being the main developer of this support. For a full listing of contributers, please consult the KVM ChangeLog[1]. Since v2, I've incorporated all the feedback received for v1. I was able to drop the option ROM refactoring too but introduced a new patch to fix an obvious bug with the VMware vga initialization pointed out by Paul Brook. Since v3, I've incorporated a few changes suggested by Paul Brook and rebased the patches to apply against the latest CVS. [1] http://kvm.qumranet.com/kvmwiki/ChangeLog
[Qemu-devel] [PATCH 2/5] SCI fixes (v2)
KVM supports the ability to use ACPI to shutdown guests. In order to enable
this requires some fixes to be able to generate the SCI interrupt and the
appropriate plumbing.
This patch hasn't changed since v1.
diff --git a/hw/acpi.c b/hw/acpi.c
index 2669e4e..e21ded0 100644
--- a/hw/acpi.c
+++ b/hw/acpi.c
@@ -49,6 +49,7 @@ typedef struct PIIX4PMState {
uint8_t smb_data1;
uint8_t smb_data[32];
uint8_t smb_index;
+qemu_irq irq;
} PIIX4PMState;
#define RTC_EN (1 10)
@@ -71,6 +72,8 @@ typedef struct PIIX4PMState {
#define SMBHSTDAT1 0x06
#define SMBBLKDAT 0x07
+PIIX4PMState *pm_state;
+
static uint32_t get_pmtmr(PIIX4PMState *s)
{
uint32_t d;
@@ -97,11 +100,12 @@ static void pm_update_sci(PIIX4PMState *s)
pmsts = get_pmsts(s);
sci_level = (((pmsts s-pmen)
(RTC_EN | PWRBTN_EN | GBL_EN | TMROF_EN)) != 0);
-qemu_set_irq(s-dev.irq[0], sci_level);
+qemu_set_irq(s-irq, sci_level);
/* schedule a timer interruption if needed */
if ((s-pmen TMROF_EN) !(pmsts TMROF_EN)) {
expire_time = muldiv64(s-tmr_overflow_time, ticks_per_sec, PM_FREQ);
qemu_mod_timer(s-tmr_timer, expire_time);
+s-tmr_overflow_time += 0x80;
} else {
qemu_del_timer(s-tmr_timer);
}
@@ -467,7 +471,8 @@ static int pm_load(QEMUFile* f,void* opaque,int version_id)
return 0;
}
-i2c_bus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t smb_io_base)
+i2c_bus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t smb_io_base,
+ qemu_irq sci_irq)
{
PIIX4PMState *s;
uint8_t *pci_conf;
@@ -475,6 +480,7 @@ i2c_bus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t
smb_io_base)
s = (PIIX4PMState *)pci_register_device(bus,
PM, sizeof(PIIX4PMState),
devfn, NULL, pm_write_config);
+pm_state = s;
pci_conf = s-dev.config;
pci_conf[0x00] = 0x86;
pci_conf[0x01] = 0x80;
@@ -514,5 +520,16 @@ i2c_bus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t
smb_io_base)
register_savevm(piix4_pm, 0, 1, pm_save, pm_load, s);
s-smbus = i2c_init_bus();
+s-irq = sci_irq;
return s-smbus;
}
+
+#if defined(TARGET_I386)
+void qemu_system_powerdown(void)
+{
+if(pm_state-pmen PWRBTN_EN) {
+pm_state-pmsts |= PWRBTN_EN;
+ pm_update_sci(pm_state);
+}
+}
+#endif
diff --git a/hw/mips_malta.c b/hw/mips_malta.c
index f3ce4ee..550862d 100644
--- a/hw/mips_malta.c
+++ b/hw/mips_malta.c
@@ -905,7 +905,7 @@ void mips_malta_init (ram_addr_t ram_size, int vga_ram_size,
piix4_devfn = piix4_init(pci_bus, 80);
pci_piix4_ide_init(pci_bus, hd, piix4_devfn + 1, i8259);
usb_uhci_piix4_init(pci_bus, piix4_devfn + 2);
-smbus = piix4_pm_init(pci_bus, piix4_devfn + 3, 0x1100);
+smbus = piix4_pm_init(pci_bus, piix4_devfn + 3, 0x1100, i8259[9]);
eeprom_buf = qemu_mallocz(8 * 256); /* XXX: make this persistent */
for (i = 0; i 8; i++) {
/* TODO: Populate SPD eeprom data. */
diff --git a/hw/pc.c b/hw/pc.c
index b04d578..64827be 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -1006,7 +1006,7 @@ static void pc_init1(ram_addr_t ram_size, int
vga_ram_size,
i2c_bus *smbus;
/* TODO: Populate SPD eeprom data. */
-smbus = piix4_pm_init(pci_bus, piix3_devfn + 3, 0xb100);
+smbus = piix4_pm_init(pci_bus, piix3_devfn + 3, 0xb100, i8259[9]);
for (i = 0; i 8; i++) {
smbus_eeprom_device_init(smbus, 0x50 + i, eeprom_buf + (i * 256));
}
diff --git a/hw/pc.h b/hw/pc.h
index beb711c..9f83050 100644
--- a/hw/pc.h
+++ b/hw/pc.h
@@ -88,7 +88,8 @@ int ioport_get_a20(void);
/* acpi.c */
extern int acpi_enabled;
-i2c_bus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t smb_io_base);
+i2c_bus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t smb_io_base,
+ qemu_irq sci_irq);
void piix4_smbus_register_device(SMBusDevice *dev, uint8_t addr);
void acpi_bios_init(void);
diff --git a/hw/piix_pci.c b/hw/piix_pci.c
index d5c7e1e..a1e04d4 100644
--- a/hw/piix_pci.c
+++ b/hw/piix_pci.c
@@ -220,7 +220,6 @@ static void piix3_set_irq(qemu_irq *pic, int irq_num, int
level)
{
int i, pic_irq, pic_level;
-piix3_dev-config[0x60 + irq_num] = ~0x80; // enable bit
pci_irq_levels[irq_num] = level;
/* now we change the pic irq level according to the piix irq mappings */
diff --git a/sysemu.h b/sysemu.h
index 8055afc..6ef2f9a 100644
--- a/sysemu.h
+++ b/sysemu.h
@@ -31,12 +31,16 @@ void cpu_disable_ticks(void);
void qemu_system_reset_request(void);
void qemu_system_shutdown_request(void);
void qemu_system_powerdown_request(void);
-#if !defined(TARGET_SPARC)
+int qemu_shutdown_requested(void);
+int qemu_reset_requested(void);
+int qemu_powerdown_requested(void);
+#if !defined(TARGET_SPARC) !defined(TARGET_I386)
// Please implement a power failure function to signal the OS
#define
[Qemu-devel] Re: [kvm-devel] [PATCH 1/5] Use correct types to enable 2G support (v3)
Anthony Liguori wrote:
KVM supports more than 2GB of memory for x86_64 hosts. The following patch
fixes a number of type related issues where int's were being used when they
shouldn't have been. It also introduces CMOS support so the BIOS can build
the appropriate e820 tables.
For v2 of this patch, I've moved ram_addr_t to cpu-all.h and switched
ram_size to be a ram_addr_t. I've also removed the memory limit check for
x86_64 (provided kqemu isn't enabled) and enabled the use of a 'M' or 'G'
suffix for the -m option. I've also tried to do a more thorough job of
updating the code to use the proper types.
This patch also includes support for setting up 2GB of memory for
TARGET_I386. KVM works quite happily with 5GB of ram but I suspect there
are still some uint32_t's in the non-KVM does not work when using more than
3GB of RAM.
Since v2, I got rid of an improper declaration of ram_size by moving it from
sysemu.h to cpu-all.h. I also added some code to handle wrap around in the
'-m' option. I also eliminated the unnecessary change to TARGET_PAGE_SIZE.
My apologies, there was a typo in this patch. Please apply the attached
patch (v4) instead.
Regards,
Anthony Liguori
Subject: [PATCH 1/5] Use correct types to enable 2G support (v4)
Cc: Avi Kivity [EMAIL PROTECTED]
Cc: Fabrice Bellard [EMAIL PROTECTED]
Cc: Paul Brook [EMAIL PROTECTED]
Cc: Andrzej Zaborowski [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
KVM supports more than 2GB of memory for x86_64 hosts. The following patch
fixes a number of type related issues where int's were being used when they
shouldn't have been. It also introduces CMOS support so the BIOS can build
the appropriate e820 tables.
For v2 of this patch, I've moved ram_addr_t to cpu-all.h and switched
ram_size to be a ram_addr_t. I've also removed the memory limit check for
x86_64 (provided kqemu isn't enabled) and enabled the use of a 'M' or 'G'
suffix for the -m option. I've also tried to do a more thorough job of
updating the code to use the proper types.
This patch also includes support for setting up 2GB of memory for
TARGET_I386. KVM works quite happily with 5GB of ram but I suspect there
are still some uint32_t's in the non-KVM does not work when using more than
3GB of RAM.
Since v2, I got rid of an improper declaration of ram_size by moving it from
sysemu.h to cpu-all.h. I also added some code to handle wrap around in the
'-m' option. I also eliminated the unnecessary change to TARGET_PAGE_SIZE.
Since v3, fix a typo in the -m option.
diff --git a/cpu-all.h b/cpu-all.h
index 7a7e655..cb03072 100644
--- a/cpu-all.h
+++ b/cpu-all.h
@@ -800,12 +800,16 @@ int cpu_inw(CPUState *env, int addr);
int cpu_inl(CPUState *env, int addr);
#endif
+/* address in the RAM (different from a physical address) */
+typedef unsigned long ram_addr_t;
+
/* memory API */
-extern int phys_ram_size;
+extern ram_addr_t phys_ram_size;
extern int phys_ram_fd;
extern uint8_t *phys_ram_base;
extern uint8_t *phys_ram_dirty;
+extern ram_addr_t ram_size;
/* physical memory access */
#define TLB_INVALID_MASK (1 3)
@@ -830,7 +834,7 @@ void cpu_register_physical_memory(target_phys_addr_t start_addr,
unsigned long size,
unsigned long phys_offset);
uint32_t cpu_get_physical_page_desc(target_phys_addr_t addr);
-ram_addr_t qemu_ram_alloc(unsigned int size);
+ram_addr_t qemu_ram_alloc(unsigned long size);
void qemu_ram_free(ram_addr_t addr);
int cpu_register_io_memory(int io_index,
CPUReadMemoryFunc **mem_read,
diff --git a/cpu-defs.h b/cpu-defs.h
index 6979c11..60ac4c6 100644
--- a/cpu-defs.h
+++ b/cpu-defs.h
@@ -76,9 +76,6 @@ typedef uint64_t target_phys_addr_t;
#error TARGET_PHYS_ADDR_BITS undefined
#endif
-/* address in the RAM (different from a physical address) */
-typedef unsigned long ram_addr_t;
-
#define HOST_LONG_SIZE (HOST_LONG_BITS / 8)
#define EXCP_INTERRUPT 0x1 /* async interruption */
diff --git a/exec.c b/exec.c
index e9a5918..1e6ac97 100644
--- a/exec.c
+++ b/exec.c
@@ -73,6 +73,8 @@
#define TARGET_VIRT_ADDR_SPACE_BITS 42
#elif defined(TARGET_PPC64)
#define TARGET_PHYS_ADDR_SPACE_BITS 42
+#elif defined(TARGET_X86_64) !defined(USE_KQEMU)
+#define TARGET_PHYS_ADDR_SPACE_BITS 42
#else
/* Note: for compatibility with kqemu, we use 32 bits for x86_64 */
#define TARGET_PHYS_ADDR_SPACE_BITS 32
@@ -87,7 +89,7 @@ spinlock_t tb_lock = SPIN_LOCK_UNLOCKED;
uint8_t code_gen_buffer[CODE_GEN_BUFFER_SIZE] __attribute__((aligned (32)));
uint8_t *code_gen_ptr;
-int phys_ram_size;
+ram_addr_t phys_ram_size;
int phys_ram_fd;
uint8_t *phys_ram_base;
uint8_t *phys_ram_dirty;
@@ -112,7 +114,7 @@ typedef struct PageDesc {
typedef struct PhysPageDesc {
/* offset in host memory of the page + io_index in the low 12 bits */
-uint32_t phys_offset;
+ram_addr_t phys_offset;
} PhysPageDesc;
#define L2_BITS 10
@@ -1980,7 +1982,7 @@ static inline
Re: [Qemu-devel] Fix writev syscall emulation
On [Mon, 04.02.2008 20:03], Richard Purdie wrote:
Hi,
OpenEmbedded/Poky use qemu for locale generation when cross compiling.
When we upgraded to qemu 0.9.1 it started giving locale generation
errors on all 64 bit machines and some 32 bit ones.
I've traced it to the writev syscall failing. localedef passes several
{ NULL, 0 } iovec entries which trip up lock_iovec(). That function is
returning an error for these but the return value isn't checked. The
syscall is therefore always made but sometimes with a iovec that has
only been half copied. If the total writes exceed size_t, EINVAL is
returned by the kernel and glibc code emulates the call with a write
which is most likely to happen on 32 bit so it sometimes works. size_t
is unlikely to be exceeded on 64 bit so that returns an EFAULT and
always corrupts/fails.
Anyhow, it seems 0 length iovec entries are allowed and we shouldn't
care about the addresses in those cases. The patch below is one way to
fix this. Ideally the return value of lock_iovec() needs be be checked
too.
Regards,
Richard
---
linux-user/syscall.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: qemu-0.9.1/linux-user/syscall.c
===
--- qemu-0.9.1.orig/linux-user/syscall.c 2008-02-03 00:00:00.0
+
+++ qemu-0.9.1/linux-user/syscall.c 2008-02-03 00:00:38.0 +
@@ -1048,7 +1048,7 @@ static abi_long lock_iovec(int type, str
base = tswapl(target_vec[i].iov_base);
vec[i].iov_len = tswapl(target_vec[i].iov_len);
vec[i].iov_base = lock_user(type, base, vec[i].iov_len, copy);
- if (!vec[i].iov_base)
+ if (!vec[i].iov_base vec[i].iov_len)
goto fail;
}
unlock_user (target_vec, target_addr, 0);
I have post similar patch some days ago.
--
Regards, Kirill A. Shutemov
+ Belarus, Minsk
+ Velesys Ltd, http://www.velesys.com/
+ ALT Linux Team, http://www.altlinux.com/
signature.asc
Description: Digital signature
[PATCH] Re: [Qemu-devel] qemu-img convert does not handle -O correctly
Am 04.02.2008 um 00:41 schrieb Dean Payne: Andreas Färber wrote: Hello, When running `qemu-img convert haikuware.vmdk -O qcow2 haikuware.qcow2` on OSX, it complains it cannot open '-O'. According to `qemu-img convert --help` my syntax is correct. Andreas I had similar problems and needed to change the order of parameters on the command line. For your statement try... qemu-img convert -f vmdk -O qcow2 haikuware.vmdk haikuware.qcow2 ... as -f and -O come first before filenames Thanks, that did work. Attached is a patch to fix the usage output. Andreas qemu-img-O.diff Description: Binary data
[Qemu-devel] qemu/linux-user syscall.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 08/02/04 22:26:57 Modified files: linux-user : syscall.c Log message: lock_iovec() fix CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/syscall.c?cvsroot=qemur1=1.161r2=1.162
[Qemu-devel] qemu/tcg tcg.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 08/02/04 22:03:16 Modified files: tcg: tcg.c Log message: win32: suppress alloca() warning CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/tcg.c?cvsroot=qemur1=1.3r2=1.4
[Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x
I'm running qemu (really, KVM) in a LAN that uses 10.0.2.x as the IP address block for workstations. So naturally when I booted a guest, it couldn't access machines inside the LAN. I tried the simplest thing that could possibly work: [EMAIL PROTECTED]:~/dnlds/qemu/qemu $ replace 10.0.2 10.0.3 -- `find -type f | grep -v -i CVS ` Booting that resulted in a virtual machine that, as I had hoped, used 10.0.3.15 and could therefore successfully talk to my 10.0.2.x IPs on the LAN. I've attached a 'cvs diff' against HEAD that results from the above command. Out of curiosity, are there plans to make the user-space networking stack IP range configurable at run-time rather than compile time? I'm not suggesting that this patch I attached become part of CVS HEAD necessarily; what I do hope is that this will inspire someone else on the list to make the handling of this more flexible, knowing now that it's fairly easy to do. (-: Even if not, this serves as a report to others that this trivial patch actually does what you'd hope/expect! -- Asheesh. -- It took me fifteen years to discover that I had no talent for writing, but I couldn't give it up because by that time I was too famous. -- Robert Benchley Index: qemu-doc.texi === RCS file: /sources/qemu/qemu/qemu-doc.texi,v retrieving revision 1.186 diff -r1.186 qemu-doc.texi 657c657 usual 10.0.2.2. --- usual 10.0.3.2. 676c676 10.0.2.4 smbserver --- 10.0.3.4 smbserver 692c692 is not specified, its value is 10.0.2.15 (default address given by the --- is not specified, its value is 10.0.3.15 (default address given by the 1497c1497 | (10.0.2.2) --- | (10.0.3.2) 1499c1499 DNS server (10.0.2.3) --- DNS server (10.0.3.3) 1501c1501 SMB server (10.0.2.4) --- SMB server (10.0.3.4) 1507c1507 to the hosts starting from 10.0.2.15. --- to the hosts starting from 10.0.3.15. 1510,1511c1510,1511 the address 10.0.2.2 and verify that you got an address in the range 10.0.2.x from the QEMU virtual DHCP server. --- the address 10.0.3.2 and verify that you got an address in the range 10.0.3.x from the QEMU virtual DHCP server. 1515c1515 router (10.0.2.2). --- router (10.0.3.2). Index: vl.c === RCS file: /sources/qemu/qemu/vl.c,v retrieving revision 1.403 diff -r1.403 vl.c 3773c3773 pstrcpy(buf, sizeof(buf), 10.0.2.15); --- pstrcpy(buf, sizeof(buf), 10.0.3.15); Index: slirp/ctl.h === RCS file: /sources/qemu/qemu/slirp/ctl.h,v retrieving revision 1.1 diff -r1.1 ctl.h 6,7c6,7 #define CTL_SPECIAL 10.0.2.0 #define CTL_LOCAL 10.0.2.15 --- #define CTL_SPECIAL 10.0.3.0 #define CTL_LOCAL 10.0.3.15
[Qemu-devel] qemu dyngen.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 08/02/04 22:00:42 Modified files: . : dyngen.c Log message: win32 fix CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/dyngen.c?cvsroot=qemur1=1.60r2=1.61
Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x
Mmm, actually, shouldn't qemu use a more private network like a RFC1918 172.16.0.0/12 network? (see http://www.ucam.org/cam-grin/) Samuel
Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x
You can always do what I do --- run openvpn between my QEMU sessions and set up private networks that way ;) On Feb 4, 2008 4:24 PM, Asheesh Laroia [EMAIL PROTECTED] wrote: I'm running qemu (really, KVM) in a LAN that uses 10.0.2.x as the IP address block for workstations. So naturally when I booted a guest, it couldn't access machines inside the LAN. I tried the simplest thing that could possibly work: [EMAIL PROTECTED]:~/dnlds/qemu/qemu $ replace 10.0.2 10.0.3 -- `find -type f | grep -v -i CVS ` Booting that resulted in a virtual machine that, as I had hoped, used 10.0.3.15 and could therefore successfully talk to my 10.0.2.x IPs on the LAN. I've attached a 'cvs diff' against HEAD that results from the above command. Out of curiosity, are there plans to make the user-space networking stack IP range configurable at run-time rather than compile time? I'm not suggesting that this patch I attached become part of CVS HEAD necessarily; what I do hope is that this will inspire someone else on the list to make the handling of this more flexible, knowing now that it's fairly easy to do. (-: Even if not, this serves as a report to others that this trivial patch actually does what you'd hope/expect! -- Asheesh. -- It took me fifteen years to discover that I had no talent for writing, but I couldn't give it up because by that time I was too famous. -- Robert Benchley -- -- Jonathan Kalbfeld ThoughtWave Technologies LLC www.thoughtwave.com +1 424 354 1814
Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x
Hi, On Mon, 4 Feb 2008, Asheesh Laroia wrote: Booting that resulted in a virtual machine that, as I had hoped, used 10.0.3.15 and could therefore successfully talk to my 10.0.2.x IPs on the LAN. I've attached a 'cvs diff' against HEAD that results from the above command. And the next guy comes, changing these to 10.0.4.x because he has a net which uses 10.0.3.x? Why not make this configurable with a command line option? Ciao, Dscho
