On Dec 27, 2014, at 8:19 PM, Peter Maydell wrote:
> On 28 December 2014 at 00:36, Programmingkid
> wrote:
>> The raw_getlength() function under Mac OS X incorrectly returned a constant
>> value instead of calculating the size of a real CD-ROM disc. This patch
>> fixes this problem and makes b
On 28 December 2014 at 00:36, Programmingkid wrote:
> The raw_getlength() function under Mac OS X incorrectly returned a constant
> value instead of calculating the size of a real CD-ROM disc. This patch fixes
> this problem and makes booting from a real CD-ROM disc possible again under
> Mac O
The raw_getlength() function under Mac OS X incorrectly returned a constant
value instead of calculating the size of a real CD-ROM disc. This patch fixes
this problem and makes booting from a real CD-ROM disc possible again under Mac
OS X.
signed-off-by: John Arbuckle
---
block/raw-posix.c
On 27/12/14 23:01, Peter Lieven wrote:
Am 27.12.2014 um 18:42 schrieb Denis V. Lunev:
On 27/12/14 17:52, Peter Lieven wrote:
Am 26.12.2014 um 20:15 schrieb Denis V. Lunev:
On 26/12/14 16:32, Denis V. Lunev wrote:
On 26/12/14 16:13, Peter Lieven wrote:
Am 26.12.2014 um 13:35 schrieb Denis V.
Am 27.12.2014 um 18:42 schrieb Denis V. Lunev:
> On 27/12/14 17:52, Peter Lieven wrote:
>> Am 26.12.2014 um 20:15 schrieb Denis V. Lunev:
>>> On 26/12/14 16:32, Denis V. Lunev wrote:
On 26/12/14 16:13, Peter Lieven wrote:
> Am 26.12.2014 um 13:35 schrieb Denis V. Lunev:
>> The check fo
On 27/12/14 17:52, Peter Lieven wrote:
Am 26.12.2014 um 20:15 schrieb Denis V. Lunev:
On 26/12/14 16:32, Denis V. Lunev wrote:
On 26/12/14 16:13, Peter Lieven wrote:
Am 26.12.2014 um 13:35 schrieb Denis V. Lunev:
The check for maximum length was added by
commit c31cb70728d2c0c8900b35a6678
On 26/12/2014 04:31, Yang Hongyang wrote:
> Please feel free to comment.
> We want comments/feedbacks as many as possiable please, thanks in advance.
Hi Yang,
I think it's possible to build COLO block replication from many basic
blocks that are already in QEMU. The only new piece would be the
Disk images may contain large all-zeroes gaps (1.66k sectors or 812 MiB
is seen in the real world). These blocks (type 2) do not need to be
extracted into a temporary buffer, there is no need to allocate memory
for these blocks nor to check its length.
(For the test image, the maximum uncompressed
This patch adds support for bzip2-compressed block entries as introduced
with OS X 10.4 (source: https://en.wikipedia.org/wiki/Apple_Disk_Image).
It was tested against a 5.2G "OS X Yosemite" installation image which
stores the BLXX block in the XML property list (instead of resource
forks) and has
The format is simple enough to avoid using a full-blown XML parser.
The offsets are based on the description at
http://newosxbook.com/DMG.html
Signed-off-by: Peter Wu
---
block/dmg.c | 69 +
1 file changed, 69 insertions(+)
diff --git
Right now the virtual size is always reported as zero which makes it
impossible to convert between formats.
After this patch, the number of sectors will be read from the BLXX
("mish") header.
To verify the behavior, the output of `dmg2img foo.dmg foo.img` was
compared against `qemu-img convert -f
Extract the mish block decoder such that this can be used for other
formats in the future. A new DmgHeaderState struct is introduced to
share state while decoding.
The code is kept unchanged as much as possible, a "fail" label is added
for example where a simple return would probably do.
Signed-o
Besides the offset, also read the resource length. This length is now
used in the extracted function to verify the end of the resource fork
against "count" from the resource fork.
Signed-off-by: Peter Wu
---
block/dmg.c | 90 -
1 file c
DMG files have a variable length with a UDIF trailer at the end of a
file. This UDIF trailer is essential as it describes the contents of
the image. At the moment however, the start of this trailer is almost
always incorrect as bdrv_getlength() returns a multiple of the block
size (rounded up). Thi
This patch addresses two issues:
- The data fork offset was not taken into account, resulting in failure
to read an InstallESD.dmg file (5164763151 bytes) which had a
non-zero DataForkOffset field.
- The offset of the previous block ("partition") was unconditionally
added to the current
Previously the chunk size was not checked, allowing for a large memory
allocation. This patch checks whether the chunks size is within the
resource fork length.
Signed-off-by: Peter Wu
---
block/dmg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block/dmg.c b/block/dmg.c
i
Hi,
These series improve QEMU support for DMG image files:
- Images which are not multiples of a block size (512) are now properly
recognized ("properly detect the UDIF trailer").
- Block descriptors stored in the XML plist section rather than the Resource
Fork are now recognized ("proces
As the decoded plist XML is not a pointer in the file,
dmg_read_mish_block must be able to process a buffer instead of a file
pointer. Since the full buffer must be processed, let's change the
return value again to just a success flag.
Signed-off-by: Peter Wu
---
block/dmg.c | 60 +++
Am 26.12.2014 um 20:15 schrieb Denis V. Lunev:
> On 26/12/14 16:32, Denis V. Lunev wrote:
>> On 26/12/14 16:13, Peter Lieven wrote:
>>> Am 26.12.2014 um 13:35 schrieb Denis V. Lunev:
The check for maximum length was added by
commit c31cb70728d2c0c8900b35a66784baa446fd5147
Autho
On 26/12/2014 18:59, Peter Maydell wrote:
> Mm, but once you're into such microoptimisations as this you really
> need to have a good justification for the effort, in the form of
> profiling measurements that indicate that this is a hot path.
> In this case that seems pretty unlikely, because I'd
20 matches
Mail list logo
