[Qemu-devel] [Bug 1273944] Re: multiboot header has 0 in mem_upper field

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1273944

Title:
  multiboot header has 0 in mem_upper field

Status in QEMU:
  Expired

Bug description:
  When booting a multiboot image,. mem_upper is now always zero.

  To test, build qemu from current git head, then do
cd tests/multiboot
./run_test.sh

  You will see the test fail.  In each case mem_upper is 0k.

  git-bisect says the bad commit is
  0169c511554cb0014a00290b0d3d26c31a49818f in qemu.git

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1273944/+subscriptions

[Qemu-devel] [Bug 1683084] [NEW] DNS server not working in QEMU usermode networking

[Mark]

Public bug reported:

Nslookup is returning "unknown host".
I try to ping 10.0.2.3 and it fails. Pinging 10.0.2.2 and 10.0.2.15 works 
correctly.
Downloading files via wget using a static IP works well.

Results of qemu monitor command "info network" included as an
attachment.

This bug was reported as a question on stack overflow:
http://stackoverflow.com/questions/43308310/dns-server-not-working-in-
qemu-usermode-networking.

This bug exists on 2.8.0 and 2.9-rc3.

** Affects: qemu
 Importance: Undecided
 Status: New

** Attachment added: "info network.png"
   
https://bugs.launchpad.net/bugs/1683084/+attachment/4862880/+files/info%20network.png

** Description changed:

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1683084

Title:
  DNS server not working in QEMU usermode networking

Status in QEMU:
  New

Bug description:
  Nslookup is returning "unknown host".
  I try to ping 10.0.2.3 and it fails. Pinging 10.0.2.2 and 10.0.2.15 works 
correctly.
  Downloading files via wget using a static IP works well.

  Results of qemu monitor command "info network" included as an
  attachment.

  This bug was reported as a question on stack overflow:
  http://stackoverflow.com/questions/43308310/dns-server-not-working-in-
  qemu-usermode-networking.

  This bug exists on 2.8.0 and 2.9-rc3.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1683084/+subscriptions

[Qemu-devel] [PATCH] timer.h: Provide monotonic time for ARM guests

[Pranith Kumar]

Tested and confirmed that the stretch i386 debian qcow2 image on a
raspberry pi 2 works.

Fixes: LP#: 893208 
Signed-off-by: Pranith Kumar 
---
 include/qemu/timer.h | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/include/qemu/timer.h b/include/qemu/timer.h
index e1742f2f3d..14c9558da4 100644
--- a/include/qemu/timer.h
+++ b/include/qemu/timer.h
@@ -1015,6 +1015,16 @@ static inline int64_t cpu_get_host_ticks(void)
 return cur - ofs;
 }
 
+#elif defined(__arm__) || defined(__aarch64__)
+
+/* ARM does not have a user-space readble cycle counter available.
+ * This is a compromise to get monotonically increasing time.
+ */
+static inline int64_t cpu_get_host_ticks(void)
+{
+return get_clock();
+}
+
 #else
 /* The host CPU doesn't have an easily accessible cycle counter.
Just return a monotonically increasing value.  This will be
-- 
2.11.0

[Qemu-devel] [PATCH] hw/arm: Qomify pxa2xx.c

[Suramya Shah]

Signed-off-by: Suramya Shah 
---
 hw/arm/pxa2xx.c | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/hw/arm/pxa2xx.c b/hw/arm/pxa2xx.c
index cfee392..eea551d 100644
--- a/hw/arm/pxa2xx.c
+++ b/hw/arm/pxa2xx.c
@@ -755,19 +755,18 @@ static void pxa2xx_ssp_reset(DeviceState *d)
 s->rx_start = s->rx_level = 0;
 }
 
-static int pxa2xx_ssp_init(SysBusDevice *sbd)
+static void pxa2xx_ssp_init(Object *obj)
 {
-DeviceState *dev = DEVICE(sbd);
-PXA2xxSSPState *s = PXA2XX_SSP(dev);
-
+DeviceState *dev = DEVICE(obj);
+PXA2xxSSPState *s = PXA2XX_SSP(obj);
+SysBusDevice *sbd = SYS_BUS_DEVICE(obj);
 sysbus_init_irq(sbd, &s->irq);
 
-memory_region_init_io(&s->iomem, OBJECT(s), &pxa2xx_ssp_ops, s,
+memory_region_init_io(&s->iomem, obj, &pxa2xx_ssp_ops, s,
   "pxa2xx-ssp", 0x1000);
 sysbus_init_mmio(sbd, &s->iomem);
 
 s->bus = ssi_create_bus(dev, "ssi");
-return 0;
 }
 
 /* Real-Time Clock */
@@ -2321,10 +2320,8 @@ PXA2xxState *pxa255_init(MemoryRegion *address_space, 
unsigned int sdram_size)
 
 static void pxa2xx_ssp_class_init(ObjectClass *klass, void *data)
 {
-SysBusDeviceClass *sdc = SYS_BUS_DEVICE_CLASS(klass);
 DeviceClass *dc = DEVICE_CLASS(klass);
 
-sdc->init = pxa2xx_ssp_init;
 dc->reset = pxa2xx_ssp_reset;
 dc->vmsd = &vmstate_pxa2xx_ssp;
 }
@@ -2333,6 +2330,7 @@ static const TypeInfo pxa2xx_ssp_info = {
 .name  = TYPE_PXA2XX_SSP,
 .parent= TYPE_SYS_BUS_DEVICE,
 .instance_size = sizeof(PXA2xxSSPState),
+.instance_init = pxa2xx_ssp_init,
 .class_init= pxa2xx_ssp_class_init,
 };
 
-- 
2.9.3

[Qemu-devel] [Bug 1667401] Re: qemu-ppc segfaults(SIGSEGV) on pthread_create

[William Barsse]

Fixed by commit 2635531f2006bfb0f943ad25b41e176709b79b37 (available in
2.9.0rc0)

** Changed in: qemu
   Status: New => Fix Committed

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1667401

Title:
  qemu-ppc segfaults(SIGSEGV) on pthread_create

Status in QEMU:
  Fix Committed

Bug description:
  qemu-ppc running on x86-64 hardware leads to a segfault when running the
  attached program (test.c). It simply creates a pthread, joins it and exits.

  It was compiled as follows on a Debian testing system:
  > powerpc-linux-gnuspe-gcc-6 -static -Wall -g -o test -pthread test.c

  Sample execution (expected output is "Hello - World!"):
  > qemu-ppc -cpu e500 ./test
  [...output...]
  Hello - qemu-ppc: /build/qemu-_M2UL5/qemu-2.8+dfsg/translate-all.c:175: 
tb_lock: Assertion `!have_tb_lock' failed.
  qemu-ppc: /build/qemu-_M2UL5/qemu-2.8+dfsg/translate-all.c:175: tb_lock: 
Assertion `!have_tb_lock' failed.
  [1]25747 segmentation fault  qemu-ppc -cpu e500 test
  [...end output...]

  The same behavior is observed when running on a PPC 604:

  > powerpc-linux-gnu-gcc -Wall -g -o test -pthread test.c
  > qemu-ppc ./test
  [... as above ...]

  Version information:
  powerpc-linux-gnu-gcc -v => gcc version 6.3.0 20170124 (Debian 6.3.0-5)
  qemu-ppc -version => qemu-ppc version 2.8.0(Debian 1:2.8+dfsg-2)

  The same experiment was conducted again using qemu from the git repository 
(commit: 796b288f7be875045670f963ce1b3c8e96ac):
  ~/tools/qemu/build/ppc-linux-user/qemu-ppc -version => qemu-ppc version 
2.8.50 (v2.8.0-1417-g796b288f7b-dirty)
  [...output...]
  Hello - qemu-ppc: [...redacted...]/tools/qemu/translate-all.c:175: tb_lock: 
Assertion `!have_tb_lock' failed.
  qemu-ppc: [...redacted...]/tools/qemu/translate-all.c:175: tb_lock: Assertion 
`!have_tb_lock' failed.
  [1]25996 segmentation fault  ~/tools/qemu/build/ppc-linux-user/qemu-ppc 
-cpu e500 test
  [...end output...]

  
  Executing with -strace option yields a surprising entry (see second clone() 
syscall below):
  [...]
  26007 
clone(CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,child_stack=0xf67fde60,parent_tidptr=0xf67fe368,tls=0xf68057d0,child_tidptr=0xf67fe368)
 = 26009
  26007 
clone(0,child_stack=0xf67fde60,parent_tidptr=0xf67fe368,tls=0xf68057d0,child_tidptr=0xf67fe368)
 = -1 errno=22 (Invalid argument)

  
  test.c works just fine if the pthread_create & pthread_join calls are removed
  (i.e. when compiled with -DNO_PTHREAD_CREATE).

  At first glance, the issue seems specific to PPC because compiling and running
  for x86_64 using qemu-x86_64 works fine.

  
  Additional info:
  > lddtree =qemu-ppc
  qemu-ppc => /usr/bin/qemu-ppc (interpreter => /lib64/ld-linux-x86-64.so.2)
  libgmodule-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0
  libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2
  ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2
  libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0
  libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3
  librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1
  libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6
  libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
  libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
  libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6

  > /lib/x86_64-linux-gnu/libc.so.6
  GNU C Library (Debian GLIBC 2.24-9) stable release version 2.24, by Roland 
McGrath et al.

  > uname -a
  Linux [...redacted...] 4.9.0-1-amd64 #1 SMP Debian 4.9.6-3 (2017-01-28) 
x86_64 GNU/Linux

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1667401/+subscriptions

Re: [Qemu-devel] [PATCH 04/14] cg3: switch to load_image_mr() and remove prom-addr hack

[Philippe Mathieu-Daudé]

On 04/05/2017 05:35 AM, Mark Cave-Ayland wrote:

Previous to the existence of load_image_mr(), the only way to load in the
FCode ROM image was to pass in its physical address via qdev properties
and use load_image_targphys().

Signed-off-by: Mark Cave-Ayland 


Reviewed-by: Philippe Mathieu-Daudé 


---
 hw/display/cg3.c |4 +---
 hw/sparc/sun4m.c |1 -
 2 files changed, 1 insertion(+), 4 deletions(-)

diff --git a/hw/display/cg3.c b/hw/display/cg3.c
index 178a6dd..3d36960 100644
--- a/hw/display/cg3.c
+++ b/hw/display/cg3.c
@@ -300,8 +300,7 @@ static void cg3_realizefn(DeviceState *dev, Error **errp)
 vmstate_register_ram_global(&s->rom);
 fcode_filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, CG3_ROM_FILE);
 if (fcode_filename) {
-ret = load_image_targphys(fcode_filename, s->prom_addr,
-  FCODE_MAX_ROM_SIZE);
+ret = load_image_mr(fcode_filename, &s->rom);
 g_free(fcode_filename);
 if (ret < 0 || ret > FCODE_MAX_ROM_SIZE) {
 error_report("cg3: could not load prom '%s'", CG3_ROM_FILE);
@@ -366,7 +365,6 @@ static Property cg3_properties[] = {
 DEFINE_PROP_UINT16("width",CG3State, width, -1),
 DEFINE_PROP_UINT16("height",   CG3State, height,-1),
 DEFINE_PROP_UINT16("depth",CG3State, depth, -1),
-DEFINE_PROP_UINT64("prom-addr",CG3State, prom_addr, -1),
 DEFINE_PROP_END_OF_LIST(),
 };

diff --git a/hw/sparc/sun4m.c b/hw/sparc/sun4m.c
index 873cd7d..7a0922b 100644
--- a/hw/sparc/sun4m.c
+++ b/hw/sparc/sun4m.c
@@ -544,7 +544,6 @@ static void cg3_init(hwaddr addr, qemu_irq irq, int 
vram_size, int width,
 qdev_prop_set_uint16(dev, "width", width);
 qdev_prop_set_uint16(dev, "height", height);
 qdev_prop_set_uint16(dev, "depth", depth);
-qdev_prop_set_uint64(dev, "prom-addr", addr);
 qdev_init_nofail(dev);
 s = SYS_BUS_DEVICE(dev);

Re: [Qemu-devel] [PATCH 14/14] tcx: switch to load_image_mr() and remove prom_addr hack

[Philippe Mathieu-Daudé]

On 04/05/2017 05:35 AM, Mark Cave-Ayland wrote:

Previous to the existence of load_image_mr(), the only way to load in the
FCode ROM image was to pass in its physical address via qdev properties
and use load_image_targphys().

Signed-off-by: Mark Cave-Ayland 


Reviewed-by: Philippe Mathieu-Daudé 


---
 hw/display/tcx.c |4 +---
 hw/sparc/sun4m.c |1 -
 2 files changed, 1 insertion(+), 4 deletions(-)

diff --git a/hw/display/tcx.c b/hw/display/tcx.c
index 3f00735..5a1115c 100644
--- a/hw/display/tcx.c
+++ b/hw/display/tcx.c
@@ -843,8 +843,7 @@ static void tcx_realizefn(DeviceState *dev, Error **errp)
 vmstate_register_ram_global(&s->rom);
 fcode_filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, TCX_ROM_FILE);
 if (fcode_filename) {
-ret = load_image_targphys(fcode_filename, s->prom_addr,
-  FCODE_MAX_ROM_SIZE);
+ret = load_image_mr(fcode_filename, &s->rom);
 g_free(fcode_filename);
 if (ret < 0 || ret > FCODE_MAX_ROM_SIZE) {
 error_report("tcx: could not load prom '%s'", TCX_ROM_FILE);
@@ -902,7 +901,6 @@ static Property tcx_properties[] = {
 DEFINE_PROP_UINT16("width",TCXState, width, -1),
 DEFINE_PROP_UINT16("height",   TCXState, height,-1),
 DEFINE_PROP_UINT16("depth",TCXState, depth, -1),
-DEFINE_PROP_UINT64("prom_addr", TCXState, prom_addr, -1),
 DEFINE_PROP_END_OF_LIST(),
 };

diff --git a/hw/sparc/sun4m.c b/hw/sparc/sun4m.c
index 7a0922b..5f022cc 100644
--- a/hw/sparc/sun4m.c
+++ b/hw/sparc/sun4m.c
@@ -491,7 +491,6 @@ static void tcx_init(hwaddr addr, qemu_irq irq, int 
vram_size, int width,
 qdev_prop_set_uint16(dev, "width", width);
 qdev_prop_set_uint16(dev, "height", height);
 qdev_prop_set_uint16(dev, "depth", depth);
-qdev_prop_set_uint64(dev, "prom_addr", addr);
 qdev_init_nofail(dev);
 s = SYS_BUS_DEVICE(dev);

Re: [Qemu-devel] [PATCH 05/14] tcx: alter tcx_set_dirty() to accept address and length parameters

[Philippe Mathieu-Daudé]

Hi Mark,

On 04/05/2017 05:35 AM, Mark Cave-Ayland wrote:

Signed-off-by: Mark Cave-Ayland 
---
 hw/display/tcx.c |   12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/hw/display/tcx.c b/hw/display/tcx.c
index 8e26aae..d24466f 100644
--- a/hw/display/tcx.c
+++ b/hw/display/tcx.c
@@ -93,9 +93,9 @@ typedef struct TCXState {
 uint16_t cursy;
 } TCXState;

-static void tcx_set_dirty(TCXState *s)
+static void tcx_set_dirty(TCXState *s, ram_addr_t addr, int len)


len is uint64_t

with this change:
Reviewed-by: Philippe Mathieu-Daudé 

This function can also be inlined.


 {
-memory_region_set_dirty(&s->vram_mem, 0, MAXX * MAXY);
+memory_region_set_dirty(&s->vram_mem, addr, len);
 }

 static inline int tcx24_check_dirty(TCXState *s, ram_addr_t page,
@@ -156,7 +156,7 @@ static void update_palette_entries(TCXState *s, int start, 
int end)
 break;
 }
 }
-tcx_set_dirty(s);
+tcx_set_dirty(s, 0, memory_region_size(&s->vram_mem));
 }

 static void tcx_draw_line32(TCXState *s1, uint8_t *d,
@@ -526,7 +526,7 @@ static void tcx_invalidate_display(void *opaque)
 {
 TCXState *s = opaque;

-tcx_set_dirty(s);
+tcx_set_dirty(s, 0, memory_region_size(&s->vram_mem));
 qemu_console_resize(s->con, s->width, s->height);
 }

@@ -534,7 +534,7 @@ static void tcx24_invalidate_display(void *opaque)
 {
 TCXState *s = opaque;

-tcx_set_dirty(s);
+tcx_set_dirty(s, 0, memory_region_size(&s->vram_mem));
 qemu_console_resize(s->con, s->width, s->height);
 }

@@ -543,7 +543,7 @@ static int vmstate_tcx_post_load(void *opaque, int 
version_id)
 TCXState *s = opaque;

 update_palette_entries(s, 0, 256);
-tcx_set_dirty(s);
+tcx_set_dirty(s, 0, memory_region_size(&s->vram_mem));
 return 0;
 }

Re: [Qemu-devel] [PATCH v2 0/9] arm: Implement M profile exception return properly

[Richard Henderson]

On 04/10/2017 10:13 AM, Peter Maydell wrote:

Peter Maydell (9):
  arm: Don't implement BXJ on M-profile CPUs
  arm: Thumb shift operations should not permit interworking branches
  arm: Factor out "generate right kind of step exception"
  arm: Move gen_set_condexec() and gen_set_pc_im() up in the file
  arm: Move condition-failed codepath generation out of if()
  arm: Abstract out "are we singlestepping" test to utility function
  arm: Track M profile handler mode state in TB flags
  arm: Implement M profile exception return properly
  arm: Remove workarounds for old M-profile exception return
implementation

 target/arm/cpu.h   |   9 +++
 target/arm/translate.h |   5 ++
 target/arm/cpu.c   |  43 +---
 target/arm/translate.c | 181 +
 4 files changed, 138 insertions(+), 100 deletions(-)


Reviewed-by: Richard Henderson 


r~

Re: [Qemu-devel] [PATCH 05/10] tcg: add jr opcode

[Richard Henderson]

On 04/11/2017 06:17 PM, Emilio G. Cota wrote:

This will be used by TCG targets to implement a fast path
for indirect branches.

I only have implemented and tested this on an i386 host, so
make this opcode optional and mark it as not implemented by
other TCG backends.


I don't think this is quite the right abstraction.  In particular, if we can 
always return a valid address from the helper, we can eliminate a conditional 
branch.


I think this should work as follows:

(1) tb_ret_addr gets moved into TCGContext so that it's available for other 
code to see.


(2) Have a generic helper

void *HELPER(lookup_tb_ptr)(CPUArchState *env, target_ulong addr)
{
TranslationBlock *tb = tb_from_jmp_cache(env, addr);
return tb ? tb->tc_ptr : tcg_ctx.tb_ret_addr;
}

(3) Emit TCG opcodes like

call t0,lookup_tb_ptr,env,addr
jmp_tb t0

(4) Emit code for jmp_tb like

mov %rax,%rdx   // save target into new register
xor %eax,%eax   // set return value a-la exit_tb
jmp *%edx   // branch to tb or epilogue.

(5) There needs to be a convenience function in tcg/tcg-op.c.  If the host does 
not support jmp_tb, we should just generate exit_tb like we do now.  There 
should be no ifdefs inside target/*.




r~

Re: [Qemu-devel] [PATCH 03/10] target/arm: optimize cross-page block chaining in softmmu

[Richard Henderson]

On 04/11/2017 06:17 PM, Emilio G. Cota wrote:

+uint32_t HELPER(cross_page_check)(CPUARMState *env, target_ulong vaddr)
+{
+return !!tb_from_jmp_cache(env, vaddr);
+}


FWIW, helpers like this that are intended to be used by more than one target 
should go into tcg-runtime.[ch].


That said, I don't think this is the proper abstraction.  More later...


r~

Re: [Qemu-devel] [PATCH 03/14] cg3: remove unused width and height variables

[Richard Henderson]

On 04/05/2017 01:35 AM, Mark Cave-Ayland wrote:

These aren't required since we can use the display width and height directly.

Signed-off-by: Mark Cave-Ayland 
---
 hw/display/cg3.c |   15 ++-
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/hw/display/cg3.c b/hw/display/cg3.c
index b42f60e..178a6dd 100644
--- a/hw/display/cg3.c
+++ b/hw/display/cg3.c
@@ -93,14 +93,11 @@ static void cg3_update_display(void *opaque)
 uint32_t *data;
 uint32_t dval;
 int x, y, y_start;
-unsigned int width, height;
 ram_addr_t page, page_min, page_max;

 if (surface_bits_per_pixel(surface) != 32) {
 return;
 }
-width = s->width;
-height = s->height;

 y_start = -1;
 page_min = -1;
@@ -110,11 +107,11 @@ static void cg3_update_display(void *opaque)
 data = (uint32_t *)surface_data(surface);

 memory_region_sync_dirty_bitmap(&s->vram_mem);
-for (y = 0; y < height; y++) {
+for (y = 0; y < s->height; y++) {


I suspect the generated code is much worse, since the compiler can no longer 
tell that the loop bounds are constant.


You probably do want to keep width and height in local variables across this 
function.



r~

Re: [Qemu-devel] [PATCH 03/10] vga: add vga_scanline_invalidated helper

[Richard Henderson]

On 04/04/2017 03:23 AM, Gerd Hoffmann wrote:

+static bool vga_scanline_invalidated(VGACommonState *s, int y)
+{
+if (y >= VGA_MAX_HEIGHT) {
+return false;
+}
+return s->invalidated_y_table[y >> 5] |= 1 << (y & 0x1f);
+}
+
 void vga_sync_dirty_bitmap(VGACommonState *s)
 {
 memory_region_sync_dirty_bitmap(&s->vram);
@@ -1638,8 +1646,8 @@ static void vga_draw_graphic(VGACommonState *s, int 
full_update)
 page1 = addr + bwidth - 1;
 update |= memory_region_get_dirty(&s->vram, page0, page1 - page0,
   DIRTY_MEMORY_VGA);
-/* explicit invalidation for the hardware cursor */
-update |= (s->invalidated_y_table[y >> 5] >> (y & 0x1f)) & 1;
+/* explicit invalidation for the hardware cursor (cirrus only) */
+update |= vga_scanline_invalidated(s, y);


The return stmt doesn't match what you're replacing.  Are you really intending 
to modify invalidated_y_table here?



r~

[Qemu-devel] DMG chunk size independence

[Ashijeet Acharya]

Hi,

Some of you are already aware but for the benefit of the open list,
this mail is regarding the task mentioned
Here -> http://wiki.qemu-project.org/ToDo/Block/DmgChunkSizeIndependence

I had a chat with Fam regarding this and he suggested a solution where
we fix the output buffer size to a max of say "64K" and keep inflating
until we reach the end of the input stream. We extract the required
data when we enter the desired range and discard the rest. Fam however
termed this as only a  "quick fix".

The ideal fix would obviously be if we can somehow predict the exact
location inside the compressed stream relative to the desired offset
in the output decompressed stream, such as a specific sector in a
chunk. Unfortunately this is not possible without doing a first pass
over the decompressed stream as answered on the zlib FAQ page
Here -> http://zlib.net/zlib_faq.html#faq28

AFAICT after reading the zran.c example in zlib, the above mentioned
ideal fix would ultimately lead us to decompress the whole chunk in
steps at least once to maintain an access point lookup table. This
solution is better if we get several random access requests over
different read requests, otherwise it ends up being equal to the fix
suggested by Fam plus some extra effort needed in building and
maintaining access points.

I have not explored the bzip2 compressed chunks yet but have naively
assumed that we will face the same situation there?

I would like the community's opinion on this and add their suggestions
if possible to give me some new thinking points.

Thanks
Ashijeet