[Qemu-devel] qemu target-i386/translate.c tcg/tcg-op.h
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl 08/02/24 07:45:43 Modified files: target-i386: translate.c tcg: tcg-op.h Log message: More helper types, rearrange generic definitions CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/translate.c?cvsroot=qemu&r1=1.78&r2=1.79 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/tcg-op.h?cvsroot=qemu&r1=1.4&r2=1.5
[Qemu-devel] Re: [PATCH] Don't explicitly set BAR values for VMware VGA
Anthony Liguori wrote: Right now we set explict base addresses for the PCI IO regions in the VMware VGA device. We don't register the second region at all and instead directly map the physical memory. The problem is, the addresses we're setting in the BAR is not taken into account in the e820 mapping. This patch removes the explicit BARs and registers the second region through the normal PCI code. I've only tested with a Linux guest and the open source VMware VGA driver. This patch needs -p2 to apply against the QEMU CVS tree. Since it seems like qemu will apply this soon, I'll pick it up via the next merge. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH] linux-user, fix getgroups/getgroups32 when both args are zero.
Hi, > My version of patch to fix same problem: Oh, yes. You are right. I have read manpage again, and I found it says, if size is zero, list is not modified, but ... So, mine is wrong. We should check only "size". /yoshii
Re: [Qemu-devel] Re: [PATCH, RFC, WIP] TCG for Qemu target Sparc32/64
On Sat, Feb 23, 2008 at 07:23:49PM +0100, Fabrice Bellard wrote: > But do not mix the target specific defines with target independent > defines (in tcg-op.h there is a specific section for target specific > defines). Might it be worth moving that section into a new file? -- Stuart Brady
[Qemu-devel] Re: [kvm-devel] [PATCH] Don't explicitly set BAR values for VMware VGA
andrzej zaborowski wrote:
Oh, good question, and I think the answer be the reason why it's not
working here (*slaps self*). I'll apply the patch if you can confirm
that it works with some Ms Windows install.
I just tried with Windows XP and I have no problem detecting the card
with this patch.
FWIW, I needed to use the following patch to avoid SEGVs as it seems
there's a bug in the emulation where the update region is larger than
the screen. My first impression is that it's related to cursor drawing
as it only happens when I click on the start button and the update
region height is 36 pixels which looks like a cursor size to me. This
is true with or without the BAR patch though. I'll look into it a
little more and see what's going on.
Regards,
Anthony Liguori
I just launched the VM and checked what kind of Ms Windows set up this
is and it's a "Windows XP professional 2002" with VMware Tools
installed, and all the files on it have last modification date in 2004
or earlier. Apparently I stole the already set up VM from my dad's
computer on which he used VMware, somewhere in 2004. I then converted
the image to raw and always performed my tests with -snapshot on.
This may be why the system is unwilling to use different base
addresses.
diff --git a/qemu/hw/vmware_vga.c b/qemu/hw/vmware_vga.c
index f2a298e..0204d88 100644
--- a/qemu/hw/vmware_vga.c
+++ b/qemu/hw/vmware_vga.c
@@ -295,12 +295,31 @@ static inline void vmsvga_update_rect(struct vmsvga_state_s *s,
int x, int y, int w, int h)
{
#ifndef DIRECT_VRAM
-int line = h;
-int bypl = s->bypp * s->width;
-int width = s->bypp * w;
-int start = s->bypp * x + bypl * y;
-uint8_t *src = s->vram + start;
-uint8_t *dst = s->ds->data + start;
+int line;
+int bypl;
+int width;
+int start;
+uint8_t *src;
+uint8_t *dst;
+
+if ((x + w) > s->ds->width) {
+ fprintf(stderr, "update width too large x: %d, w: %d\n", x, w);
+ x = MIN(x, s->ds->width);
+ w = s->ds->width - x;
+}
+
+if ((y + h) > s->ds->height) {
+ fprintf(stderr, "update height too large y: %d, h: %d\n", y, h);
+ y = MIN(y, s->ds->height);
+ h = s->ds->height - y;
+}
+
+line = h;
+bypl = s->bypp * s->width;
+width = s->bypp * w;
+start = s->bypp * x + bypl * y;
+src = s->vram + start;
+dst = s->ds->data + start;
for (; line > 0; line --, src += bypl, dst += bypl)
memcpy(dst, src, width);
Re: [Qemu-devel] Re: [PATCH, RFC, WIP] TCG for Qemu target Sparc32/64
> Another point is that you should define TCG globals for each SPARC GPR. > It was not done for i386 because I feared performance regressions when > accessing to 16 bit or 8 bit sub-registers. On SPARC you do not have > this issue. How would these be kept consistent with CPUState? Paul
[Qemu-devel] Re: [PATCH, RFC, WIP] TCG for Qemu target Sparc32/64
> [...] >> Another point is that you should define TCG globals for each SPARC GPR. >> It was not done for i386 because I feared performance regressions when >> accessing to 16 bit or 8 bit sub-registers. On SPARC you do not have >> this issue. > > Nice idea. Would this also work for windowed registers? Yes, provided you use a fixed register to store regwptr. Then you can define the windowed registers as globals using this register as base. The real problem is to save and restore this register in cpu_exec() and in all the places where the regwptr CPU state field is accessed directly. TCG will handle these problems generically soon, but before it does it you can implement it "by hand". Regards, Fabrice.
[Qemu-devel] Re: [PATCH, RFC, WIP] TCG for Qemu target Sparc32/64
Blue Swirl wrote: > The attached patch enables most TCG ops for Qemu Sparc32/64 target. > Sparc32 softmmu and linux-user are OK, but Sparc64 and Sparc32plus > targets do not work. > > Comments? > > It would be nice to get rid of T2 usage in std (also stda and > casa/casxa) but I don't know how to pass a 64-bit value from legacy op > to TCG stores and loads on a 32-bit target and host. [...] Also don't forget that T2 is used in CPU restore state to handle delay slots. This part of the SPARC target is tricky and should be simplified. Another point is that you should define TCG globals for each SPARC GPR. It was not done for i386 because I feared performance regressions when accessing to 16 bit or 8 bit sub-registers. On SPARC you do not have this issue. Regarding the generic "xxx_tl" defines, I did not move it into TCG because I wanted TCG to be target independent. Since it is no longer the case because of the target memory access instructions, I think it is a good idea now. But do not mix the target specific defines with target independent defines (in tcg-op.h there is a specific section for target specific defines). Regards, Fabrice.
[Qemu-devel] Re: [PATCH] linux-user/mmap v3: Testsuite + bugfixes
On Fri, Feb 22, 2008 at 5:32 PM, Edgar E. Iglesias <[EMAIL PROTECTED]> wrote: > Hi, > > This is the third version of the linux-user/mmap bugfix patches: > > * Let the native mmap choose addresses for unfixed mappings. > * For file mappings, correct mapping of pages beyond EOF. > * Adds a small testsuite for linux-user/mmap. > > Tested with test-mmap for CRIS, MIPS, ARM and i386, simulated on linux-i686 > hosts. > > Felipe, I think the problems you are seeing are related to large mmaps > failing. By letting the native mmap choose the addresses for unfixed mmaps, I > hope your segfaults will go away. This patch does fix the weird issues I was having. Does the test checks for the issues I had? -- Felipe Contreras
