[Qemu-devel] qemu/hw pckbd.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski balrog 08/02/10 13:39:24 Modified files: hw : pckbd.c Log message: Enhance PC kbd debugging (patch from Hervé Poussineau) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pckbd.c?cvsroot=qemur1=1.26r2=1.27
[Qemu-devel] qemu/hw pckbd.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/10/20 20:48:09 Modified files: hw : pckbd.c Log message: QEMU keyboard issue with Gujin-2.2, by Etienne Lorrain. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pckbd.c?cvsroot=qemur1=1.23r2=1.24
Re: [Qemu-devel] qemu/hw pckbd.c
On Wed, 2007-04-18 at 17:08 +0100, Paul Brook wrote: If you're interressed in such a feature, you may take a look of what I've done in hw/ppc405_uc.c. There are some device sharing the same memory page on those microcontrollers so I introduced a fake device called mmio that allow to register multiple devices into a single page in Qemu. I do use the serial_mm_init with the ioregister parameter set to 0 for those designs. This code may not be as generic as it would be if we want to make it a standard Qemu function, but this may give a basis or ideas for it. On Sparc32 there are several devices that would benefit from sub-page granularity, so I vote for making this generic. While you're fixing this, it would be good to fix overlapping devices as well ;-) Currently if you (temporarily) have overlapping regions then remove one of them you end up with unmapped memory. What is the correct behavior in such a case ? What device would you actually see ? May be it different to one architecture to another ? I think there are busses and/or architectures where this is not possible, you would only get a fault on the bus in such a case. So it seems to me not to be easy to find a generic and appropriate way to fix this behavior, don't you think ? -- J. Mayer [EMAIL PROTECTED] Never organized
Re: [Qemu-devel] qemu/hw pckbd.c
While you're fixing this, it would be good to fix overlapping devices as well ;-) Currently if you (temporarily) have overlapping regions then remove one of them you end up with unmapped memory. What is the correct behavior in such a case ? What device would you actually see ? May be it different to one architecture to another ? I think there are busses and/or architectures where this is not possible, you would only get a fault on the bus in such a case. So it seems to me not to be easy to find a generic and appropriate way to fix this behavior, don't you think ? I'm more concerned with what happens with devices with configurable address ranges overlap temporarily, eg. when an OS is re-allocating PCI device memory regions. Paul
Re: [Qemu-devel] qemu/hw pckbd.c
Ok, try this patch. It doesn't handle cases where the sub-page areas
are something else than IO. Though I don't know if it handles any
other cases for that matter, but at least Sparc32 may work. :-)
Index: qemu/exec.c
===
--- qemu.orig/exec.c 2007-04-19 18:07:26.0 +
+++ qemu/exec.c 2007-04-19 18:07:28.0 +
@@ -155,6 +155,14 @@
static int tb_flush_count;
static int tb_phys_invalidate_count;
+#define SUBPAGE_IDX(addr) ((addr) (TARGET_PAGE_BITS - 1))
+typedef struct subpage_t {
+target_phys_addr_t base;
+CPUReadMemoryFunc **mem_read[TARGET_PAGE_SIZE];
+CPUWriteMemoryFunc **mem_write[TARGET_PAGE_SIZE];
+void *opaque[TARGET_PAGE_SIZE];
+} subpage_t;
+
static void page_init(void)
{
/* NOTE: we can always suppose that qemu_host_page_size =
@@ -1896,6 +1904,10 @@
}
#endif /* defined(CONFIG_USER_ONLY) */
+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);
+
/* register physical memory. 'size' must be a multiple of the target
page size. If (phys_offset ~TARGET_PAGE_MASK) != 0, then it is an
io memory page */
@@ -1906,15 +1918,39 @@
target_phys_addr_t addr, end_addr;
PhysPageDesc *p;
CPUState *env;
+unsigned long orig_size = size;
+void *subpage;
size = (size + TARGET_PAGE_SIZE - 1) TARGET_PAGE_MASK;
end_addr = start_addr + size;
for(addr = start_addr; addr != end_addr; addr += TARGET_PAGE_SIZE) {
-p = phys_page_find_alloc(addr TARGET_PAGE_BITS, 1);
-p-phys_offset = phys_offset;
-if ((phys_offset ~TARGET_PAGE_MASK) = IO_MEM_ROM ||
-(phys_offset IO_MEM_ROMD))
-phys_offset += TARGET_PAGE_SIZE;
+p = phys_page_find(addr TARGET_PAGE_BITS);
+if (p p-phys_offset != IO_MEM_UNASSIGNED) {
+unsigned long orig_memory = p-phys_offset;
+target_phys_addr_t start_addr2, end_addr2;
+
+if (addr start_addr)
+start_addr2 = 0;
+else
+start_addr2 = start_addr ~TARGET_PAGE_MASK;
+
+if (end_addr - addr TARGET_PAGE_SIZE)
+end_addr2 = TARGET_PAGE_SIZE - 1;
+else
+end_addr2 = start_addr + orig_size - addr;
+
+if (!(orig_memory IO_MEM_SUBPAGE)) {
+subpage = subpage_init(addr, p-phys_offset);
+subpage_register(subpage, 0, TARGET_PAGE_SIZE, orig_memory);
+}
+subpage_register(io_mem_opaque[orig_memory], start_addr2, end_addr2, phys_offset);
+} else {
+p = phys_page_find_alloc(addr TARGET_PAGE_BITS, 1);
+p-phys_offset = phys_offset;
+if ((phys_offset ~TARGET_PAGE_MASK) = IO_MEM_ROM ||
+(phys_offset IO_MEM_ROMD))
+phys_offset += TARGET_PAGE_SIZE;
+}
}
/* since each CPU stores ram addresses in its TLB cache, we must
@@ -2150,6 +2186,146 @@
};
#endif
+static inline uint32_t subpage_readlen (subpage_t *mmio, target_phys_addr_t addr,
+ unsigned int len)
+{
+CPUReadMemoryFunc **mem_read;
+uint32_t ret;
+unsigned int idx;
+
+idx = SUBPAGE_IDX(addr - mmio-base);
+#if defined(DEBUG_SUBPAGE)
+printf(%s: subpage %p len %d addr PADDRX idx %d\n, __func__,
+ mmio, len, addr, idx);
+#endif
+mem_read = mmio-mem_read[idx];
+ret = (*mem_read[len])(mmio-opaque[idx], addr);
+
+return ret;
+}
+
+static inline void subpage_writelen (subpage_t *mmio, target_phys_addr_t addr,
+ uint32_t value, unsigned int len)
+{
+CPUWriteMemoryFunc **mem_write;
+unsigned int idx;
+
+idx = SUBPAGE_IDX(addr - mmio-base);
+#if defined(DEBUG_SUBPAGE)
+printf(%s: subpage %p len %d addr PADDRX idx %d value %08x\n, __func__,
+ mmio, len, addr, idx, value);
+#endif
+mem_write = mmio-mem_write[idx];
+(*mem_write[len])(mmio-opaque[idx], addr, value);
+}
+
+static uint32_t subpage_readb (void *opaque, target_phys_addr_t addr)
+{
+#if defined(DEBUG_SUBPAGE)
+printf(%s: addr PADDRX \n, __func__, addr);
+#endif
+
+return subpage_readlen(opaque, addr, 0);
+}
+
+static void subpage_writeb (void *opaque, target_phys_addr_t addr,
+uint32_t value)
+{
+#if defined(DEBUG_SUBPAGE)
+printf(%s: addr PADDRX val %08x\n, __func__, addr, value);
+#endif
+subpage_writelen(opaque, addr, value, 0);
+}
+
+static uint32_t subpage_readw (void *opaque, target_phys_addr_t addr)
+{
+#if defined(DEBUG_SUBPAGE)
+printf(%s: addr PADDRX \n, __func__, addr);
+#endif
+
+return subpage_readlen(opaque, addr, 1);
+}
+
+static void subpage_writew (void *opaque, target_phys_addr_t addr,
+uint32_t value)
+{
+#if
Re: [Qemu-devel] qemu/hw pckbd.c
On Mon, 2007-04-16 at 22:47 +, Thiemo Seufer wrote:
CVSROOT: /sources/qemu
Module name: qemu
Changes by: Thiemo Seufer ths 07/04/16 22:47:54
Modified files:
hw : pckbd.c
Log message:
Support it_shift for mmapped pckbd.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pckbd.c?cvsroot=qemur1=1.19r2=1.20
Thanks for the update.
Here's another small patch, based on the same idea of what is done for
the memory-mapped serial ports and which seems useful to implement some
targets: it may be needed not to register the I/O memory area in the
pckbd driver but let the caller do it.
Please take a look.
--
J. Mayer [EMAIL PROTECTED]
Never organized
Index: vl.h
===
RCS file: /sources/qemu/qemu/vl.h,v
retrieving revision 1.216
diff -u -d -d -p -r1.216 vl.h
--- vl.h 17 Apr 2007 16:28:29 - 1.216
+++ vl.h 18 Apr 2007 09:23:43 -
@@ -1035,8 +1035,9 @@ void *vmmouse_init(void *m);
/* pckbd.c */
-void i8042_init(qemu_irq kbd_irq, qemu_irq mouse_irq, uint32_t io_base);
-void i8042_mm_init(qemu_irq kbd_irq, qemu_irq mouse_irq, target_ulong base, int it_shift);
+void i8042_init(qemu_irq kdb_irq, qemu_irq mouse_irq, uint32_t io_base);
+void i8042_mm_init(qemu_irq kbd_irq, qemu_irq mouse_irq,
+ target_ulong base, int it_shift, int ioregister);
/* mc146818rtc.c */
Index: hw/pckbd.c
===
RCS file: /sources/qemu/qemu/hw/pckbd.c,v
retrieving revision 1.20
diff -u -d -d -p -r1.20 pckbd.c
--- hw/pckbd.c 16 Apr 2007 22:47:54 - 1.20
+++ hw/pckbd.c 18 Apr 2007 09:23:43 -
@@ -422,7 +421,7 @@ void kbd_mm_writeb (void *opaque, target
};
void i8042_mm_init(qemu_irq kbd_irq, qemu_irq mouse_irq, target_ulong base,
- int it_shift)
+ int it_shift, int ioregister)
{
KBDState *s = kbd_state;
int s_io_memory;
@@ -434,8 +493,10 @@ void i8042_mm_init(qemu_irq kbd_irq, qem
kbd_reset(s);
register_savevm(pckbd, 0, 3, kbd_save, kbd_load, s);
-s_io_memory = cpu_register_io_memory(0, kbd_mm_read, kbd_mm_write, s);
-cpu_register_physical_memory(base, 8 it_shift, s_io_memory);
+if (ioregister) {
+s_io_memory = cpu_register_io_memory(0, kbd_mm_read, kbd_mm_write, s);
+cpu_register_physical_memory(base, 8 it_shift, s_io_memory);
+}
s-kbd = ps2_kbd_init(kbd_update_kbd_irq, s);
s-mouse = ps2_mouse_init(kbd_update_aux_irq, s);
Re: [Qemu-devel] qemu/hw pckbd.c
J. Mayer wrote: On Mon, 2007-04-16 at 22:47 +, Thiemo Seufer wrote: CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/04/16 22:47:54 Modified files: hw : pckbd.c Log message: Support it_shift for mmapped pckbd. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pckbd.c?cvsroot=qemur1=1.19r2=1.20 Thanks for the update. Here's another small patch, based on the same idea of what is done for the memory-mapped serial ports and which seems useful to implement some targets: it may be needed not to register the I/O memory area in the pckbd driver but let the caller do it. Please take a look. Actually, I thought about adding such a feature but then decided to defer it until it is actually needed. OTOH, with qemu handling mmio at page granularity it is likely needed sooner or later, so we could just declare it a standard implementation feature. I am ok with it either way. Thiemo
Re: [Qemu-devel] qemu/hw pckbd.c
On Wed, 2007-04-18 at 14:06 +0100, Thiemo Seufer wrote: J. Mayer wrote: On Mon, 2007-04-16 at 22:47 +, Thiemo Seufer wrote: CVSROOT: /sources/qemu Module name: qemu Changes by: Thiemo Seufer ths 07/04/16 22:47:54 Modified files: hw : pckbd.c Log message: Support it_shift for mmapped pckbd. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pckbd.c?cvsroot=qemur1=1.19r2=1.20 Thanks for the update. Here's another small patch, based on the same idea of what is done for the memory-mapped serial ports and which seems useful to implement some targets: it may be needed not to register the I/O memory area in the pckbd driver but let the caller do it. Please take a look. Actually, I thought about adding such a feature but then decided to defer it until it is actually needed. OTOH, with qemu handling mmio at page granularity it is likely needed sooner or later, so we could just declare it a standard implementation feature. I am ok with it either way. If you're interressed in such a feature, you may take a look of what I've done in hw/ppc405_uc.c. There are some device sharing the same memory page on those microcontrollers so I introduced a fake device called mmio that allow to register multiple devices into a single page in Qemu. I do use the serial_mm_init with the ioregister parameter set to 0 for those designs. This code may not be as generic as it would be if we want to make it a standard Qemu function, but this may give a basis or ideas for it. -- Jocelyn Mayer [EMAIL PROTECTED]
Re: [Qemu-devel] qemu/hw pckbd.c
If you're interressed in such a feature, you may take a look of what I've done in hw/ppc405_uc.c. There are some device sharing the same memory page on those microcontrollers so I introduced a fake device called mmio that allow to register multiple devices into a single page in Qemu. I do use the serial_mm_init with the ioregister parameter set to 0 for those designs. This code may not be as generic as it would be if we want to make it a standard Qemu function, but this may give a basis or ideas for it. On Sparc32 there are several devices that would benefit from sub-page granularity, so I vote for making this generic. While you're fixing this, it would be good to fix overlapping devices as well ;-) Currently if you (temporarily) have overlapping regions then remove one of them you end up with unmapped memory. It may also make implementing flash devices simpler. Paul
[Qemu-devel] qemu/hw pckbd.c ps2.c
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Paul Brook [EMAIL PROTECTED] 06/04/08 14:12:31 Modified files: hw : pckbd.c ps2.c Log message: Keyboard savevm fix (malc). CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/pckbd.c.diff?tr1=1.14tr2=1.15r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/ps2.c.diff?tr1=1.2tr2=1.3r1=textr2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
