All of lore.kernel.org
 help / color / mirror / Atom feed
* [Qemu-devel] [PULL v2 3/9] ahci-test: test atapi read_cd with bcl, nb_sectors = 0
From: John Snow @ 2016-11-14 16:25 UTC (permalink / raw)
  To: qemu-devel; +Cc: peter.maydell, jsnow
In-Reply-To: <1479140746-22142-1-git-send-email-jsnow@redhat.com>

Commit 9ef2e93f introduced the concept of tagging ATAPI commands as
NONDATA, but this introduced a regression for certain commands better
described as CONDDATA. read_cd is such a command that both requires
a non-zero BCL if a transfer size is set, but is perfectly content to
accept a zero BCL if the transfer size is 0.

This test adds a regression test for the case where BCL and nb_sectors
are both 0.

Flesh out the CDROM tests by:

(1) Allowing the test to specify a BCL
(2) Allowing the buffer comparison test to compare a 0-size buffer
(3) Fix the BCL specification in libqos (It is LE, not BE)
(4) Add a nice human-readable message for future SCSI command additions

Signed-off-by: John Snow <jsnow@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Message-id: 1477970211-25754-4-git-send-email-jsnow@redhat.com
[Line length edit --js]
Signed-off-by: John Snow <jsnow@redhat.com>
---
 tests/ahci-test.c   | 36 +++++++++++++++++++++++++++++-------
 tests/libqos/ahci.c | 28 +++++++++++++++++++++-------
 tests/libqos/ahci.h | 17 ++++++++++-------
 3 files changed, 60 insertions(+), 21 deletions(-)

diff --git a/tests/ahci-test.c b/tests/ahci-test.c
index a271cad..0b1b6f7 100644
--- a/tests/ahci-test.c
+++ b/tests/ahci-test.c
@@ -1473,8 +1473,13 @@ static int ahci_cb_cmp_buff(AHCIQState *ahci, AHCICommand *cmd,
                             const AHCIOpts *opts)
 {
     unsigned char *tx = opts->opaque;
-    unsigned char *rx = g_malloc0(opts->size);
+    unsigned char *rx;
 
+    if (!opts->size) {
+        return 0;
+    }
+
+    rx = g_malloc0(opts->size);
     bufread(opts->buffer, rx, opts->size);
     g_assert_cmphex(memcmp(tx, rx, opts->size), ==, 0);
     g_free(rx);
@@ -1482,7 +1487,8 @@ static int ahci_cb_cmp_buff(AHCIQState *ahci, AHCICommand *cmd,
     return 0;
 }
 
-static void ahci_test_cdrom(int nsectors, bool dma)
+static void ahci_test_cdrom(int nsectors, bool dma, uint8_t cmd,
+                            bool override_bcl, uint16_t bcl)
 {
     AHCIQState *ahci;
     unsigned char *tx;
@@ -1493,6 +1499,8 @@ static void ahci_test_cdrom(int nsectors, bool dma)
         .atapi = true,
         .atapi_dma = dma,
         .post_cb = ahci_cb_cmp_buff,
+        .set_bcl = override_bcl,
+        .bcl = bcl,
     };
     uint64_t iso_size = ATAPI_SECTOR_SIZE * (nsectors + 1);
 
@@ -1506,7 +1514,7 @@ static void ahci_test_cdrom(int nsectors, bool dma)
                                 "-device ide-cd,drive=drive0 ", iso);
 
     /* Build & Send AHCI command */
-    ahci_exec(ahci, ahci_port_select(ahci), CMD_ATAPI_READ_10, &opts);
+    ahci_exec(ahci, ahci_port_select(ahci), cmd, &opts);
 
     /* Cleanup */
     g_free(tx);
@@ -1514,24 +1522,36 @@ static void ahci_test_cdrom(int nsectors, bool dma)
     remove_iso(fd, iso);
 }
 
+static void ahci_test_cdrom_read10(int nsectors, bool dma)
+{
+    ahci_test_cdrom(nsectors, dma, CMD_ATAPI_READ_10, false, 0);
+}
+
 static void test_cdrom_dma(void)
 {
-    ahci_test_cdrom(1, true);
+    ahci_test_cdrom_read10(1, true);
 }
 
 static void test_cdrom_dma_multi(void)
 {
-    ahci_test_cdrom(3, true);
+    ahci_test_cdrom_read10(3, true);
 }
 
 static void test_cdrom_pio(void)
 {
-    ahci_test_cdrom(1, false);
+    ahci_test_cdrom_read10(1, false);
 }
 
 static void test_cdrom_pio_multi(void)
 {
-    ahci_test_cdrom(3, false);
+    ahci_test_cdrom_read10(3, false);
+}
+
+/* Regression test: Test that a READ_CD command with a BCL of 0 but a size of 0
+ * completes as a NOP instead of erroring out. */
+static void test_atapi_bcl(void)
+{
+    ahci_test_cdrom(0, false, CMD_ATAPI_READ_CD, true, 0);
 }
 
 /******************************************************************************/
@@ -1823,6 +1843,8 @@ int main(int argc, char **argv)
     qtest_add_func("/ahci/cdrom/pio/single", test_cdrom_pio);
     qtest_add_func("/ahci/cdrom/pio/multi", test_cdrom_pio_multi);
 
+    qtest_add_func("/ahci/cdrom/pio/bcl", test_atapi_bcl);
+
     ret = g_test_run();
 
     /* Cleanup */
diff --git a/tests/libqos/ahci.c b/tests/libqos/ahci.c
index 5180d65..0e9354b 100644
--- a/tests/libqos/ahci.c
+++ b/tests/libqos/ahci.c
@@ -633,7 +633,8 @@ void ahci_exec(AHCIQState *ahci, uint8_t port,
 
     /* Command creation */
     if (opts->atapi) {
-        cmd = ahci_atapi_command_create(op);
+        uint16_t bcl = opts->set_bcl ? opts->bcl : ATAPI_SECTOR_SIZE;
+        cmd = ahci_atapi_command_create(op, bcl);
         if (opts->atapi_dma) {
             ahci_command_enable_atapi_dma(cmd);
         }
@@ -864,16 +865,12 @@ AHCICommand *ahci_command_create(uint8_t command_name)
     return cmd;
 }
 
-AHCICommand *ahci_atapi_command_create(uint8_t scsi_cmd)
+AHCICommand *ahci_atapi_command_create(uint8_t scsi_cmd, uint16_t bcl)
 {
     AHCICommand *cmd = ahci_command_create(CMD_PACKET);
     cmd->atapi_cmd = g_malloc0(16);
     cmd->atapi_cmd[0] = scsi_cmd;
-    /* ATAPI needs a PIO transfer chunk size set inside of the LBA registers.
-     * The block/sector size is a natural default. */
-    cmd->fis.lba_lo[1] = ATAPI_SECTOR_SIZE >> 8 & 0xFF;
-    cmd->fis.lba_lo[2] = ATAPI_SECTOR_SIZE & 0xFF;
-
+    stw_le_p(&cmd->fis.lba_lo[1], bcl);
     return cmd;
 }
 
@@ -901,12 +898,17 @@ static void ahci_atapi_command_set_offset(AHCICommand *cmd, uint64_t lba)
 
     switch (cbd[0]) {
     case CMD_ATAPI_READ_10:
+    case CMD_ATAPI_READ_CD:
         g_assert_cmpuint(lba, <=, UINT32_MAX);
         stl_be_p(&cbd[2], lba);
         break;
     default:
         /* SCSI doesn't have uniform packet formats,
          * so you have to add support for it manually. Sorry! */
+        fprintf(stderr, "The Libqos AHCI driver does not support the "
+                "set_offset operation for ATAPI command 0x%02x, "
+                "please add support.\n",
+                cbd[0]);
         g_assert_not_reached();
     }
 }
@@ -951,6 +953,7 @@ static void ahci_atapi_set_size(AHCICommand *cmd, uint64_t xbytes)
 {
     unsigned char *cbd = cmd->atapi_cmd;
     uint64_t nsectors = xbytes / 2048;
+    uint32_t tmp;
     g_assert(cbd);
 
     switch (cbd[0]) {
@@ -958,9 +961,20 @@ static void ahci_atapi_set_size(AHCICommand *cmd, uint64_t xbytes)
         g_assert_cmpuint(nsectors, <=, UINT16_MAX);
         stw_be_p(&cbd[7], nsectors);
         break;
+    case CMD_ATAPI_READ_CD:
+        /* 24bit BE store */
+        g_assert_cmpuint(nsectors, <, 1ULL << 24);
+        tmp = nsectors;
+        cbd[6] = (tmp & 0xFF0000) >> 16;
+        cbd[7] = (tmp & 0xFF00) >> 8;
+        cbd[8] = (tmp & 0xFF);
+        break;
     default:
         /* SCSI doesn't have uniform packet formats,
          * so you have to add support for it manually. Sorry! */
+        fprintf(stderr, "The Libqos AHCI driver does not support the set_size "
+                "operation for ATAPI command 0x%02x, please add support.\n",
+                cbd[0]);
         g_assert_not_reached();
     }
 }
diff --git a/tests/libqos/ahci.h b/tests/libqos/ahci.h
index caaafe3..f144fab 100644
--- a/tests/libqos/ahci.h
+++ b/tests/libqos/ahci.h
@@ -288,6 +288,7 @@ enum {
 /* ATAPI Commands */
 enum {
     CMD_ATAPI_READ_10 = 0x28,
+    CMD_ATAPI_READ_CD = 0xbe,
 };
 
 /* AHCI Command Header Flags & Masks*/
@@ -462,12 +463,14 @@ typedef struct AHCICommand AHCICommand;
 
 /* Options to ahci_exec */
 typedef struct AHCIOpts {
-    size_t size;
-    unsigned prd_size;
-    uint64_t lba;
-    uint64_t buffer;
-    bool atapi;
-    bool atapi_dma;
+    size_t size;        /* Size of transfer */
+    unsigned prd_size;  /* Size per-each PRD */
+    bool set_bcl;       /* Override the default BCL of ATAPI_SECTOR_SIZE */
+    unsigned bcl;       /* Byte Count Limit, for ATAPI PIO */
+    uint64_t lba;       /* Starting LBA offset */
+    uint64_t buffer;    /* Pointer to source or destination guest buffer */
+    bool atapi;         /* ATAPI command? */
+    bool atapi_dma;     /* Use DMA for ATAPI? */
     bool error;
     int (*pre_cb)(AHCIQState*, AHCICommand*, const struct AHCIOpts *);
     int (*mid_cb)(AHCIQState*, AHCICommand*, const struct AHCIOpts *);
@@ -599,7 +602,7 @@ void ahci_exec(AHCIQState *ahci, uint8_t port,
 
 /* Command: Fine-grained lifecycle */
 AHCICommand *ahci_command_create(uint8_t command_name);
-AHCICommand *ahci_atapi_command_create(uint8_t scsi_cmd);
+AHCICommand *ahci_atapi_command_create(uint8_t scsi_cmd, uint16_t bcl);
 void ahci_command_commit(AHCIQState *ahci, AHCICommand *cmd, uint8_t port);
 void ahci_command_issue(AHCIQState *ahci, AHCICommand *cmd);
 void ahci_command_issue_async(AHCIQState *ahci, AHCICommand *cmd);
-- 
2.7.4

^ permalink raw reply related

* [Qemu-devel] [PULL v2 5/9] libqtest: add qmp_eventwait_ref
From: John Snow @ 2016-11-14 16:25 UTC (permalink / raw)
  To: qemu-devel; +Cc: peter.maydell, jsnow
In-Reply-To: <1479140746-22142-1-git-send-email-jsnow@redhat.com>

Wait for an event, but return a copy so we can investigate parameters.

Signed-off-by: John Snow <jsnow@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Message-id: 1478553214-497-3-git-send-email-jsnow@redhat.com
Signed-off-by: John Snow <jsnow@redhat.com>
---
 tests/libqtest.c | 13 ++++++++++---
 tests/libqtest.h | 22 ++++++++++++++++++++++
 2 files changed, 32 insertions(+), 3 deletions(-)

diff --git a/tests/libqtest.c b/tests/libqtest.c
index d4e6bff..6f69752 100644
--- a/tests/libqtest.c
+++ b/tests/libqtest.c
@@ -533,7 +533,7 @@ void qtest_qmp_discard_response(QTestState *s, const char *fmt, ...)
     QDECREF(response);
 }
 
-void qtest_qmp_eventwait(QTestState *s, const char *event)
+QDict *qtest_qmp_eventwait_ref(QTestState *s, const char *event)
 {
     QDict *response;
 
@@ -541,13 +541,20 @@ void qtest_qmp_eventwait(QTestState *s, const char *event)
         response = qtest_qmp_receive(s);
         if ((qdict_haskey(response, "event")) &&
             (strcmp(qdict_get_str(response, "event"), event) == 0)) {
-            QDECREF(response);
-            break;
+            return response;
         }
         QDECREF(response);
     }
 }
 
+void qtest_qmp_eventwait(QTestState *s, const char *event)
+{
+    QDict *response;
+
+    response = qtest_qmp_eventwait_ref(s, event);
+    QDECREF(response);
+}
+
 char *qtest_hmpv(QTestState *s, const char *fmt, va_list ap)
 {
     char *cmd;
diff --git a/tests/libqtest.h b/tests/libqtest.h
index 0224f06..90f182e 100644
--- a/tests/libqtest.h
+++ b/tests/libqtest.h
@@ -114,6 +114,16 @@ QDict *qtest_qmp_receive(QTestState *s);
 void qtest_qmp_eventwait(QTestState *s, const char *event);
 
 /**
+ * qtest_qmp_eventwait_ref:
+ * @s: #QTestState instance to operate on.
+ * @s: #event event to wait for.
+ *
+ * Continuosly polls for QMP responses until it receives the desired event.
+ * Returns a copy of the event for further investigation.
+ */
+QDict *qtest_qmp_eventwait_ref(QTestState *s, const char *event);
+
+/**
  * qtest_hmpv:
  * @s: #QTestState instance to operate on.
  * @fmt...: HMP command to send to QEMU
@@ -559,6 +569,18 @@ static inline void qmp_eventwait(const char *event)
 }
 
 /**
+ * qmp_eventwait_ref:
+ * @s: #event event to wait for.
+ *
+ * Continuosly polls for QMP responses until it receives the desired event.
+ * Returns a copy of the event for further investigation.
+ */
+static inline QDict *qmp_eventwait_ref(const char *event)
+{
+    return qtest_qmp_eventwait_ref(global_qtest, event);
+}
+
+/**
  * hmp:
  * @fmt...: HMP command to send to QEMU
  *
-- 
2.7.4

^ permalink raw reply related

* [Qemu-devel] [PULL v2 1/9] atapi: classify read_cd as conditionally returning data
From: John Snow @ 2016-11-14 16:25 UTC (permalink / raw)
  To: qemu-devel; +Cc: peter.maydell, jsnow
In-Reply-To: <1479140746-22142-1-git-send-email-jsnow@redhat.com>

For the purposes of byte_count_limit verification, add a new flag that
identifies read_cd as sometimes returning data, then check the BCL in
its command handler after we know that it will indeed return data.

Reported-by: Hervé Poussineau <hpoussin@reactos.org>
Signed-off-by: John Snow <jsnow@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Message-id: 1477970211-25754-2-git-send-email-jsnow@redhat.com
Signed-off-by: John Snow <jsnow@redhat.com>
---
 hw/ide/atapi.c | 51 ++++++++++++++++++++++++++++++++++++++++-----------
 1 file changed, 40 insertions(+), 11 deletions(-)

diff --git a/hw/ide/atapi.c b/hw/ide/atapi.c
index 6189675..fc1d19c 100644
--- a/hw/ide/atapi.c
+++ b/hw/ide/atapi.c
@@ -637,6 +637,23 @@ static unsigned int event_status_media(IDEState *s,
     return 8; /* We wrote to 4 extra bytes from the header */
 }
 
+/*
+ * Before transferring data or otherwise signalling acceptance of a command
+ * marked CONDDATA, we must check the validity of the byte_count_limit.
+ */
+static bool validate_bcl(IDEState *s)
+{
+    /* TODO: Check IDENTIFY data word 125 for defacult BCL (currently 0) */
+    if (s->atapi_dma || atapi_byte_count_limit(s)) {
+        return true;
+    }
+
+    /* TODO: Move abort back into core.c and introduce proper error flow between
+     *       ATAPI layer and IDE core layer */
+    ide_abort_command(s);
+    return false;
+}
+
 static void cmd_get_event_status_notification(IDEState *s,
                                               uint8_t *buf)
 {
@@ -1028,12 +1045,19 @@ static void cmd_read_cd(IDEState *s, uint8_t* buf)
         return;
     }
 
-    transfer_request = buf[9];
-    switch(transfer_request & 0xf8) {
-    case 0x00:
+    transfer_request = buf[9] & 0xf8;
+    if (transfer_request == 0x00) {
         /* nothing */
         ide_atapi_cmd_ok(s);
-        break;
+        return;
+    }
+
+    /* Check validity of BCL before transferring data */
+    if (!validate_bcl(s)) {
+        return;
+    }
+
+    switch (transfer_request) {
     case 0x10:
         /* normal read */
         ide_atapi_cmd_read(s, lba, nb_sectors, 2048);
@@ -1266,6 +1290,14 @@ enum {
      * See ATA8-ACS3 "7.21.5 Byte Count Limit"
      */
     NONDATA = 0x04,
+
+    /*
+     * CONDDATA implies a command that transfers data only conditionally based
+     * on the presence of suboptions. It should be exempt from the BCL check at
+     * command validation time, but it needs to be checked at the command
+     * handler level instead.
+     */
+    CONDDATA = 0x08,
 };
 
 static const struct AtapiCmd {
@@ -1289,7 +1321,7 @@ static const struct AtapiCmd {
     [ 0xad ] = { cmd_read_dvd_structure,            CHECK_READY },
     [ 0xbb ] = { cmd_set_speed,                     NONDATA },
     [ 0xbd ] = { cmd_mechanism_status,              0 },
-    [ 0xbe ] = { cmd_read_cd,                       CHECK_READY },
+    [ 0xbe ] = { cmd_read_cd,                       CHECK_READY | CONDDATA },
     /* [1] handler detects and reports not ready condition itself */
 };
 
@@ -1348,15 +1380,12 @@ void ide_atapi_cmd(IDEState *s)
         return;
     }
 
-    /* Nondata commands permit the byte_count_limit to be 0.
+    /* Commands that don't transfer DATA permit the byte_count_limit to be 0.
      * If this is a data-transferring PIO command and BCL is 0,
      * we abort at the /ATA/ level, not the ATAPI level.
      * See ATA8 ACS3 section 7.17.6.49 and 7.21.5 */
-    if (cmd->handler && !(cmd->flags & NONDATA)) {
-        /* TODO: Check IDENTIFY data word 125 for default BCL (currently 0) */
-        if (!(atapi_byte_count_limit(s) || s->atapi_dma)) {
-            /* TODO: Move abort back into core.c and make static inline again */
-            ide_abort_command(s);
+    if (cmd->handler && !(cmd->flags & (NONDATA | CONDDATA))) {
+        if (!validate_bcl(s)) {
             return;
         }
     }
-- 
2.7.4

^ permalink raw reply related

* [Qemu-devel] [PULL v2 7/9] libqos/ahci: Add ATAPI tray macros
From: John Snow @ 2016-11-14 16:25 UTC (permalink / raw)
  To: qemu-devel; +Cc: peter.maydell, jsnow
In-Reply-To: <1479140746-22142-1-git-send-email-jsnow@redhat.com>

(1) Add START_STOP_UNIT command to ahci-test suite
(2) Add eject/start macro commands; this is not a data transfer
    command so it is not well-served by the existing generic pipeline.

Signed-off-by: John Snow <jsnow@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Message-id: 1478553214-497-5-git-send-email-jsnow@redhat.com
Signed-off-by: John Snow <jsnow@redhat.com>
---
 tests/libqos/ahci.c | 30 ++++++++++++++++++++++++++++++
 tests/libqos/ahci.h |  7 +++++--
 2 files changed, 35 insertions(+), 2 deletions(-)

diff --git a/tests/libqos/ahci.c b/tests/libqos/ahci.c
index 99e85d5..79398b4 100644
--- a/tests/libqos/ahci.c
+++ b/tests/libqos/ahci.c
@@ -882,6 +882,30 @@ AHCICommand *ahci_atapi_command_create(uint8_t scsi_cmd, uint16_t bcl)
     return cmd;
 }
 
+void ahci_atapi_eject(AHCIQState *ahci, uint8_t port)
+{
+    AHCICommand *cmd = ahci_atapi_command_create(CMD_ATAPI_START_STOP_UNIT, 0);
+    ahci_command_set_size(cmd, 0);
+
+    cmd->atapi_cmd[4] = 0x02; /* loej = true */
+    ahci_command_commit(ahci, cmd, port);
+    ahci_command_issue(ahci, cmd);
+    ahci_command_verify(ahci, cmd);
+    ahci_command_free(cmd);
+}
+
+void ahci_atapi_load(AHCIQState *ahci, uint8_t port)
+{
+    AHCICommand *cmd = ahci_atapi_command_create(CMD_ATAPI_START_STOP_UNIT, 0);
+    ahci_command_set_size(cmd, 0);
+
+    cmd->atapi_cmd[4] = 0x03; /* loej,start = true */
+    ahci_command_commit(ahci, cmd, port);
+    ahci_command_issue(ahci, cmd);
+    ahci_command_verify(ahci, cmd);
+    ahci_command_free(cmd);
+}
+
 void ahci_command_free(AHCICommand *cmd)
 {
     g_free(cmd->atapi_cmd);
@@ -910,6 +934,9 @@ static void ahci_atapi_command_set_offset(AHCICommand *cmd, uint64_t lba)
         g_assert_cmpuint(lba, <=, UINT32_MAX);
         stl_be_p(&cbd[2], lba);
         break;
+    case CMD_ATAPI_START_STOP_UNIT:
+        g_assert_cmpuint(lba, ==, 0x00);
+        break;
     default:
         /* SCSI doesn't have uniform packet formats,
          * so you have to add support for it manually. Sorry! */
@@ -977,6 +1004,9 @@ static void ahci_atapi_set_size(AHCICommand *cmd, uint64_t xbytes)
         cbd[7] = (tmp & 0xFF00) >> 8;
         cbd[8] = (tmp & 0xFF);
         break;
+    case CMD_ATAPI_START_STOP_UNIT:
+        g_assert_cmpuint(xbytes, ==, 0);
+        break;
     default:
         /* SCSI doesn't have uniform packet formats,
          * so you have to add support for it manually. Sorry! */
diff --git a/tests/libqos/ahci.h b/tests/libqos/ahci.h
index bbe04f8..05ce3de 100644
--- a/tests/libqos/ahci.h
+++ b/tests/libqos/ahci.h
@@ -287,8 +287,9 @@ enum {
 
 /* ATAPI Commands */
 enum {
-    CMD_ATAPI_READ_10 = 0x28,
-    CMD_ATAPI_READ_CD = 0xbe,
+    CMD_ATAPI_START_STOP_UNIT = 0x1b,
+    CMD_ATAPI_READ_10         = 0x28,
+    CMD_ATAPI_READ_CD         = 0xbe,
 };
 
 /* AHCI Command Header Flags & Masks*/
@@ -600,6 +601,8 @@ void ahci_io(AHCIQState *ahci, uint8_t port, uint8_t ide_cmd,
              void *buffer, size_t bufsize, uint64_t sector);
 void ahci_exec(AHCIQState *ahci, uint8_t port,
                uint8_t op, const AHCIOpts *opts);
+void ahci_atapi_eject(AHCIQState *ahci, uint8_t port);
+void ahci_atapi_load(AHCIQState *ahci, uint8_t port);
 
 /* Command: Fine-grained lifecycle */
 AHCICommand *ahci_command_create(uint8_t command_name);
-- 
2.7.4

^ permalink raw reply related

* [Qemu-devel] [PULL v2 4/9] block-backend: Always notify on blk_eject
From: John Snow @ 2016-11-14 16:25 UTC (permalink / raw)
  To: qemu-devel; +Cc: peter.maydell, jsnow
In-Reply-To: <1479140746-22142-1-git-send-email-jsnow@redhat.com>

blk_eject is only used by scsi-disk and atapi, and in both cases we
only attempt to invoke blk_eject if we have a bona-fide change in
tray state.

The "issue" here is that the tray state does not generate a QMP event
unless there is a medium/BDS attached to the device, so if libvirt et al
are waiting for a tray event to occur from an empty-but-closed drive,
software opening that drive will not emit an event and libvirt will
wait forever.

Change this by modifying blk_eject to always emit an event, instead of
conditionally on a "real" backend eject.

Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1373264

Reported-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: John Snow <jsnow@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Message-id: 1478553214-497-2-git-send-email-jsnow@redhat.com
Signed-off-by: John Snow <jsnow@redhat.com>
---
 block/block-backend.c | 13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/block/block-backend.c b/block/block-backend.c
index 27a7f6f..efbf398 100644
--- a/block/block-backend.c
+++ b/block/block-backend.c
@@ -1393,13 +1393,14 @@ void blk_eject(BlockBackend *blk, bool eject_flag)
 
     if (bs) {
         bdrv_eject(bs, eject_flag);
-
-        id = blk_get_attached_dev_id(blk);
-        qapi_event_send_device_tray_moved(blk_name(blk), id,
-                                          eject_flag, &error_abort);
-        g_free(id);
-
     }
+
+    /* Whether or not we ejected on the backend,
+     * the frontend experienced a tray event. */
+    id = blk_get_attached_dev_id(blk);
+    qapi_event_send_device_tray_moved(blk_name(blk), id,
+                                      eject_flag, &error_abort);
+    g_free(id);
 }
 
 int blk_get_flags(BlockBackend *blk)
-- 
2.7.4

^ permalink raw reply related

* [Qemu-devel] [PULL v2 2/9] ahci-test: Create smaller test ISO images
From: John Snow @ 2016-11-14 16:25 UTC (permalink / raw)
  To: qemu-devel; +Cc: peter.maydell, jsnow
In-Reply-To: <1479140746-22142-1-git-send-email-jsnow@redhat.com>

These can simply be the size of the number of sectors we're reading,
plus one for a buffer. We don't need them to be any larger.

Signed-off-by: John Snow <jsnow@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Message-id: 1477970211-25754-3-git-send-email-jsnow@redhat.com
Signed-off-by: John Snow <jsnow@redhat.com>
---
 tests/ahci-test.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tests/ahci-test.c b/tests/ahci-test.c
index 70bcafa..a271cad 100644
--- a/tests/ahci-test.c
+++ b/tests/ahci-test.c
@@ -1494,9 +1494,10 @@ static void ahci_test_cdrom(int nsectors, bool dma)
         .atapi_dma = dma,
         .post_cb = ahci_cb_cmp_buff,
     };
+    uint64_t iso_size = ATAPI_SECTOR_SIZE * (nsectors + 1);
 
     /* Prepare ISO and fill 'tx' buffer */
-    fd = prepare_iso(1024 * 1024, &tx, &iso);
+    fd = prepare_iso(iso_size, &tx, &iso);
     opts.opaque = tx;
 
     /* Standard startup wonkery, but use ide-cd and our special iso file */
-- 
2.7.4

^ permalink raw reply related

* [Qemu-devel] [PULL v2 6/9] libqos/ahci: Support expected errors
From: John Snow @ 2016-11-14 16:25 UTC (permalink / raw)
  To: qemu-devel; +Cc: peter.maydell, jsnow
In-Reply-To: <1479140746-22142-1-git-send-email-jsnow@redhat.com>

Sometimes we know we'll get back an error, so let's have the
test framework understand that.

Signed-off-by: John Snow <jsnow@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Message-id: 1478553214-497-4-git-send-email-jsnow@redhat.com
Signed-off-by: John Snow <jsnow@redhat.com>
---
 tests/libqos/ahci.c | 16 ++++++++++++----
 tests/libqos/ahci.h |  3 ++-
 2 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/tests/libqos/ahci.c b/tests/libqos/ahci.c
index 0e9354b..99e85d5 100644
--- a/tests/libqos/ahci.c
+++ b/tests/libqos/ahci.c
@@ -86,6 +86,7 @@ struct AHCICommand {
     uint8_t name;
     uint8_t port;
     uint8_t slot;
+    uint8_t errors;
     uint32_t interrupts;
     uint64_t xbytes;
     uint32_t prd_size;
@@ -402,12 +403,14 @@ void ahci_port_clear(AHCIQState *ahci, uint8_t port)
 /**
  * Check a port for errors.
  */
-void ahci_port_check_error(AHCIQState *ahci, uint8_t port)
+void ahci_port_check_error(AHCIQState *ahci, uint8_t port,
+                           uint32_t imask, uint8_t emask)
 {
     uint32_t reg;
 
     /* The upper 9 bits of the IS register all indicate errors. */
     reg = ahci_px_rreg(ahci, port, AHCI_PX_IS);
+    reg &= ~imask;
     reg >>= 23;
     g_assert_cmphex(reg, ==, 0);
 
@@ -417,8 +420,13 @@ void ahci_port_check_error(AHCIQState *ahci, uint8_t port)
 
     /* The TFD also has two error sections. */
     reg = ahci_px_rreg(ahci, port, AHCI_PX_TFD);
-    ASSERT_BIT_CLEAR(reg, AHCI_PX_TFD_STS_ERR);
-    ASSERT_BIT_CLEAR(reg, AHCI_PX_TFD_ERR);
+    if (!emask) {
+        ASSERT_BIT_CLEAR(reg, AHCI_PX_TFD_STS_ERR);
+    } else {
+        ASSERT_BIT_SET(reg, AHCI_PX_TFD_STS_ERR);
+    }
+    ASSERT_BIT_CLEAR(reg, AHCI_PX_TFD_ERR & (~emask << 8));
+    ASSERT_BIT_SET(reg, AHCI_PX_TFD_ERR & (emask << 8));
 }
 
 void ahci_port_check_interrupts(AHCIQState *ahci, uint8_t port,
@@ -1119,7 +1127,7 @@ void ahci_command_verify(AHCIQState *ahci, AHCICommand *cmd)
     uint8_t slot = cmd->slot;
     uint8_t port = cmd->port;
 
-    ahci_port_check_error(ahci, port);
+    ahci_port_check_error(ahci, port, cmd->interrupts, cmd->errors);
     ahci_port_check_interrupts(ahci, port, cmd->interrupts);
     ahci_port_check_nonbusy(ahci, port, slot);
     ahci_port_check_cmd_sanity(ahci, cmd);
diff --git a/tests/libqos/ahci.h b/tests/libqos/ahci.h
index f144fab..bbe04f8 100644
--- a/tests/libqos/ahci.h
+++ b/tests/libqos/ahci.h
@@ -576,7 +576,8 @@ void ahci_set_command_header(AHCIQState *ahci, uint8_t port,
 void ahci_destroy_command(AHCIQState *ahci, uint8_t port, uint8_t slot);
 
 /* AHCI sanity check routines */
-void ahci_port_check_error(AHCIQState *ahci, uint8_t port);
+void ahci_port_check_error(AHCIQState *ahci, uint8_t port,
+                           uint32_t imask, uint8_t emask);
 void ahci_port_check_interrupts(AHCIQState *ahci, uint8_t port,
                                 uint32_t intr_mask);
 void ahci_port_check_nonbusy(AHCIQState *ahci, uint8_t port, uint8_t slot);
-- 
2.7.4

^ permalink raw reply related

* [Qemu-devel] [PULL v2 0/9] Ide patches
From: John Snow @ 2016-11-14 16:25 UTC (permalink / raw)
  To: qemu-devel; +Cc: peter.maydell, jsnow

The following changes since commit 83c83f9a5266ff113060f887f106a47920fa6974:

  Merge remote-tracking branch 'bonzini/tags/for-upstream' into staging (2016-11-11 12:51:50 +0000)

are available in the git repository at:

  https://github.com/jnsnow/qemu.git tags/ide-pull-request

for you to fetch changes up to 22381d4180fa71614ad195b54fe81e0ffb77b01e:

  ahci-test: add QMP tray test for ATAPI (2016-11-14 11:15:55 -0500)

----------------------------------------------------------------

v2: Rebase, add Kevin's RBs and fix line length in two places.

----------------------------------------------------------------

John Snow (9):
  atapi: classify read_cd as conditionally returning data
  ahci-test: Create smaller test ISO images
  ahci-test: test atapi read_cd with bcl, nb_sectors = 0
  block-backend: Always notify on blk_eject
  libqtest: add qmp_eventwait_ref
  libqos/ahci: Support expected errors
  libqos/ahci: Add ATAPI tray macros
  libqos/ahci: Add get_sense and test_ready
  ahci-test: add QMP tray test for ATAPI

 block/block-backend.c |  13 ++---
 hw/ide/atapi.c        |  51 +++++++++++++++----
 tests/ahci-test.c     | 137 +++++++++++++++++++++++++++++++++++++++++++++++---
 tests/libqos/ahci.c   | 124 +++++++++++++++++++++++++++++++++++++++++----
 tests/libqos/ahci.h   |  42 ++++++++++++----
 tests/libqtest.c      |  13 +++--
 tests/libqtest.h      |  22 ++++++++
 7 files changed, 354 insertions(+), 48 deletions(-)

-- 
2.7.4

^ permalink raw reply

* Re: [GIT PULL] fbdev fixes for 4.9
From: Linus Torvalds @ 2016-11-14 16:25 UTC (permalink / raw)
  To: Tomi Valkeinen; +Cc: linux-fbdev, linux-kernel@vger.kernel.org
In-Reply-To: <b74835d1-b878-55ec-65d3-dd3766a5b194@ti.com>

On Mon, Nov 14, 2016 at 3:44 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>
> Please pull two fbdev fixes for 4.9.

No.

This has obviously never even been test-compiled. It introduces two
new annoying warnings.

                 Linus

^ permalink raw reply

* Re: [PATCH 3/3] ovl: redirect on rename-dir
From: Amir Goldstein @ 2016-11-14 16:25 UTC (permalink / raw)
  To: Miklos Szeredi
  Cc: Raphael Hertzog, Konstantin Khlebnikov, Miklos Szeredi,
	linux-unionfs@vger.kernel.org, Guillem Jover, linux-fsdevel,
	Linux Kernel Mailing List
In-Reply-To: <CAOQ4uxiC+O93=Dbgogc-GpL_7rF-qCRXeGzy3epVfpZRHNQf=A@mail.gmail.com>

On Sun, Nov 13, 2016 at 12:00 PM, Amir Goldstein <amir73il@gmail.com> wrote:
> On Fri, Nov 11, 2016 at 12:39 AM, Miklos Szeredi <miklos@szeredi.hu> wrote:
>> New version is at:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git #redirect
>>
>> News:
>> - it actually should work in all cases
>> - when rename is not cross directory, just store the new name instead
>> of a full path, as suggested by Amir
>> - when redirect path is too long fall back to EXDEV (the max length
>> should probably be a module param)
>>
>
> Looks goods, except for the case of change from relative to absolute
> redirect of the victim dentry. IIUC, ovl_set_redirect() will return immediately
> because ovl_dentry_is_redirect() and will not get to setting the absolute
> redirect.
>

I added some more tests to catch this problem at:
https://github.com/amir73il/unionmount-testsuite.git #ovl_rename_dir

In the new version, upper recycling is optional and you can set a bound
to the number of layers. This is needed to catch the bug because the
scenario is:
- Rename populated dir in same dir
- Move the populated dir to another dir
- Re-mount
- Populated dir is empty

The following test run demonstrates it:

$ sudo ./run --ov=0 rename-move-dir
...
TEST rename-move-dir.py:37: Rename populated dir and move into another
 ./run --rename /mnt/a/dir102 /mnt/a/dir102x
 ./run --rename /mnt/a/dir102 /mnt/a/dir102x -E ENOENT
 ./run --rename /mnt/a/dir102x /mnt/a/empty102/dir102
 ./run --rename /mnt/a/dir102x /mnt/a/empty102/dir102 -E ENOENT
 ./run --open-file /mnt/a/dir102 -r -d -E ENOENT
 ./run --open-file /mnt/a/dir102x -r -d -E ENOENT
 ./run --open-file /mnt/a/empty102/dir102 -r -d
/mnt/a/empty102/dir102/a: File is missing


Amir.

^ permalink raw reply

* [U-Boot] MAINTAINERS: mark sunxi status as Orphan
From: Tom Rini @ 2016-11-14 16:25 UTC (permalink / raw)
  To: u-boot
In-Reply-To: <20161114115325.1601-1-hdegoede@redhat.com>

On Mon, Nov 14, 2016 at 12:53:25PM +0100, Hans de Goede wrote:

> Ian has not had any time for sunxi for some time now and I'm
> in the same situation now, so I'm stepping down as sunxi
> custodian and marking the sunxi support as Orphan.
> 
> Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
> Cc: Chen-Yu Tsai <wens@csie.org>
> Cc: Ian Campbell <ijc@hellion.org.uk>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> Acked-by: Ian Campbell <ijc@hellion.org.uk>

Sadly, applied to u-boot/master.  Once again, thanks for all the time
you've spent!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161114/2df0d6ed/attachment.sig>

^ permalink raw reply

* Re: [Qemu-devel] TCP performance problems - GSO/TSO, MSS, 8139cp related
From: Stefan Hajnoczi @ 2016-11-14 16:25 UTC (permalink / raw)
  To: Russell King - ARM Linux, David Woodhouse
  Cc: jasowang, vyasevic, stefanha, netdev, qemu-devel,
	igor.v.kovalenko, dgilbert
In-Reply-To: <20161114092947.GB2031@work-vm>

[-- Attachment #1: Type: text/plain, Size: 3792 bytes --]

On Mon, Nov 14, 2016 at 09:29:48AM +0000, Dr. David Alan Gilbert wrote:
> * Russell King - ARM Linux (linux@armlinux.org.uk) wrote:
> > On Fri, Nov 11, 2016 at 09:23:43PM +0000, David Woodhouse wrote:
> > > It's also *fairly* unlikely that the kernel in the guest has developed
> > > a bug and isn't setting gso_size sanely. I'm more inclined to suspect
> > > that qemu isn't properly emulating those bits. But at first glance at
> > > the code, it looks like *that's* been there for the last decade too...
> > 
> > I take issue with that, having looked at the qemu rtl8139 code:
> > 
> >                 if ((txdw0 & CP_TX_LGSEN) && ip_protocol == IP_PROTO_TCP)
> >                 {
> >                     int large_send_mss = (txdw0 >> 16) & CP_TC_LGSEN_MSS_MASK;
> > 
> >                     DPRINTF("+++ C+ mode offloaded task TSO MTU=%d IP data %d "
> >                         "frame data %d specified MSS=%d\n", ETH_MTU,
> >                         ip_data_len, saved_size - ETH_HLEN, large_send_mss);
> > 
> > That's the only reference to "large_send_mss" there, other than that,
> > the MSS value that gets stuck into the field by 8139cp.c is completely
> > unused.  Instead, qemu does this:
> > 
> >                 eth_payload_data = saved_buffer + ETH_HLEN;
> >                 eth_payload_len  = saved_size   - ETH_HLEN;
> > 
> >                 ip = (ip_header*)eth_payload_data;
> > 
> >                     hlen = IP_HEADER_LENGTH(ip);
> >                     ip_data_len = be16_to_cpu(ip->ip_len) - hlen;
> > 
> >                     tcp_header *p_tcp_hdr = (tcp_header*)(eth_payload_data + hlen);
> >                     int tcp_hlen = TCP_HEADER_DATA_OFFSET(p_tcp_hdr);
> > 
> >                     /* ETH_MTU = ip header len + tcp header len + payload */
> >                     int tcp_data_len = ip_data_len - tcp_hlen;
> >                     int tcp_chunk_size = ETH_MTU - hlen - tcp_hlen;
> > 
> >                     for (tcp_send_offset = 0; tcp_send_offset < tcp_data_len; tcp_send_offset += tcp_chunk_size)
> >                     {
> > 
> > It uses a fixed value of ETH_MTU to calculate the size of the TCP
> > data chunks, and this is not surprisingly the well known:
> > 
> > #define ETH_MTU     1500
> > 
> > Qemu seems to be buggy - it ignores the MSS value, and always tries to
> > send 1500 byte frames.
> 
> cc'ing in Stefan who last touched that code and Jason and Vlad who
> know the net code.

CCing Igor Kovalenko who implemented "fixed for TCP segmentation
offloading - removed dependency on slirp.h" in 2006.  I don't actually
expect him to remember this from 10 years ago though :).

Looking at the history the large_send_mss variable was never used for
anything beyond the debug printf.

The datasheet for this NIC is here:
http://realtek.info/pdf/rtl8139cp.pdf.  See 9.2.1 Transmit.

Does this untested patch work for you?

diff --git a/hw/net/rtl8139.c b/hw/net/rtl8139.c
index f05e59c..a3f1af5 100644
--- a/hw/net/rtl8139.c
+++ b/hw/net/rtl8139.c
@@ -2167,9 +2167,13 @@ static int rtl8139_cplus_transmit_one(RTL8139State *s)
                     goto skip_offload;
                 }
 
-                /* ETH_MTU = ip header len + tcp header len + payload */
+                /* MSS too small */
+                if (tcp_hlen + hlen >= large_send_mss) {
+                    goto skip_offload;
+                }
+
                 int tcp_data_len = ip_data_len - tcp_hlen;
-                int tcp_chunk_size = ETH_MTU - hlen - tcp_hlen;
+                int tcp_chunk_size = large_send_mss - hlen - tcp_hlen;
 
                 DPRINTF("+++ C+ mode TSO IP data len %d TCP hlen %d TCP "
                     "data len %d TCP chunk size %d\n", ip_data_len,

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

^ permalink raw reply related

* Re: Change call ABI on PA-RISC
From: Helge Deller @ 2016-11-14 16:24 UTC (permalink / raw)
  To: John David Anglin, Jeff Law; +Cc: linux-parisc@vger.kernel.org
In-Reply-To: <77ee085f-205e-5fcb-d5e8-86bc95d5b9eb@bell.net>

On 14.11.2016 16:11, John David Anglin wrote:
> On 2016-11-14 3:21 AM, Jeff Law wrote:
>> On 11/13/2016 12:48 PM, Helge Deller wrote:
>>> On 13.11.2016 19:56, Jeff Law wrote:
>>>> On 11/13/2016 11:37 AM, Helge Deller wrote:
>>>>> If you are going to change the ABI, maybe we can add more
>>>>> things as well? Which comes to my mind here is for example an
>>>>> optimized mcount() function which allows changing the return
>>>>> pointer (see -mmcount-ra-address on MIPS) ?
>>> 
>>>> As in twiddling RP to return to a different point?
>>> 
>>> No, that's not the use case for me.

I was wrong.
It's actually the use case to modify the RP...

>>> I was working on the ftrace functionality in the Linux kernel. 
>>> I'd need to look up the full details again, but as far as I
>>> remember one of the tracers wants to know the function to which
>>> the caller of mcount() would return, so some kind of simple
>>> __builtin_return_address(2).

>> Ah.  Isn't that going to be sitting at sp-20 or something like
>> that.  My PA is rusty, but my recollection is that's supposed to be
>> at a fixed location in the frame.

Yes, sp-10.

0000000000000000 <irq_to_desc>:
   0:   08 03 02 41     copy r3,r1
   4:   0f c2 12 c1     std rp,-10(sp)
   8:   08 1e 02 43     copy sp,r3
   c:   73 c1 00 a8     std,ma r1,50(sp)
  10:   37 dd 00 20     ldo 10(sp),ret1
  14:   0c 65 12 d0     std r5,8(r3)
  18:   00 00 14 b9     mfia r25
  1c:   db 45 0b e0     extrd,u,* r26,63,32,r5
  20:   70 64 00 20     std r4,10(r3)
  24:   08 02 02 5a     copy rp,r26
  28:   37 39 3f d1     ldo -18(r25),r25
  2c:   08 1b 02 44     copy dp,r4
  30:   2b 60 00 00     addil L%0,dp,r1
  34:   50 21 00 00     ldd 0(r1),r1
  38:   0c 20 10 c1     ldd 0(r1),r1
  3c:   50 22 00 20     ldd 10(r1),rp
  40:   e8 40 f0 00     bve,l (rp),rp
  44:   50 3b 00 30     ldd 18(r1),dp


> The return address of the the function to which the caller of
> mcount() would return is passed to mcount() in %r26.  The saved value
> in the frame is not directly useful as one lacks the frame offset of
> the routine calling mcount.

What I want to archieve is to modify the return pointer, in order
to be able to track when the function returns to his caller.
The kernel ftracer uses this then to generate call stacks and to
time the function.
Looking at the above code, it should then be possible for me
to modify -10(r3), but is there a guarantee that it's always at
-10(r3) and that r3 is used?
That's the reason I asked if we could modify mcount to
give the address (in the stack) of the return pointer, but maybe
it's just overkill for this use case ?

Helge 

^ permalink raw reply

* Re: [PATCH v2 00/46] Nandsim facelift (part I of II)
From: Richard Weinberger @ 2016-11-14 16:24 UTC (permalink / raw)
  To: Boris Brezillon; +Cc: Daniel Walter, linux-mtd@lists.infradead.org, LKML
In-Reply-To: <20161016182441.49adc653@bbrezillon>

Boris,

sorry for the late answer. I was not on CC, therefore this mail was
unnoticed by me. :-(

On Sun, Oct 16, 2016 at 6:24 PM, Boris Brezillon
<boris.brezillon@free-electrons.com> wrote:
> Daniel, Richard,
>
> On Wed, 21 Sep 2016 11:43:29 +0200
> Daniel Walter <dwalter@sigma-star.at> wrote:
>
>> Changes since V1:
>>   Incooperate feedback for nand_cleanup()
>>   Improve commit messages

[..-]

> I really like the new approach for 2 reasons:
> 1/ it allows creating several NAND devs, and you can do that after the
>    module has been loaded.
> 2/ it fixes the partial NAND detection support by allowing one to
>    describe its NAND in term of page size, eraseblock size, oob
>    size, ...
>
> But I'm wondering if we should not create a new driver instead of
> trying to fix the old one (I must admit I haven't been through the 46
> patches of this series, but last time we discussed it on IRC, Richard
> said it actually was a complete rewrite of the nandsim driver).
>
> Moreover, if we specify the flash layout manually, maybe we could make
> it an mtdsim driver instead of restricting the emulation to NAND
> devices.
>
> What do you think?

I think we don't need a completely new driver. This series just adds
functionality to nandsim without much cost, in fact we reuse also some
bits from nandsim.
If we add a new nandsim alike driver we basically give up the current nandsim
and it will die a painful death. This series tries to avoid that.
What we can do is splitting nandsim into three files (common, old and new).

P.s: Yes, I'm aware of the fact that then I'll have to maintain the beast. ;-\

-- 
Thanks,
//richard

^ permalink raw reply

* Re: [Qemu-devel] [PATCH] tcg/mips: Add support for mips64el backend
From: Aurelien Jarno @ 2016-11-14 16:24 UTC (permalink / raw)
  To: Jin Guojie; +Cc: Richard Henderson, qemu-devel
In-Reply-To: <tencent_15C727792D3238FF7AEC75B6@qq.com>

Hi,

On 2016-11-14 17:33, Jin Guojie wrote:
> Richard,
> 
> I have studied your V2 patch
> 
> https://lists.nongnu.org/archive/html/qemu-devel/2016-02/msg02969.html
> 
> . Though I have not tested this patch on Loongson machine, I feel this 
> patch has implemented MIPS64 ISA very completely, including big/little
> endian, N32 and N64 ABI. The use of #if is more clean. Many corner cases
> are well handled. My patch is only a subset of yours.
> 
> I wonder why your patch have not be merged into the mainstream.
> If I had seen it before, I don't need to waste time reinventing my patch.
> 
> Since tcg target for MIPS64 is of great use for developers, I 
> really hope this feature can be merged into mainstream.
> 
> Is your v2 patch still in review process? Is there chance for this
> patch to be merged in a not so long term? Or should other code
> work should be done before being merged?

Please see:
 https://lists.nongnu.org/archive/html/qemu-devel/2016-02/msg06444.html

In short this patch set looks overall good, but breaks support for
existing big-endian 32-bit hosts. It also doesn't fully work on 64-bit
hosts for 32-bit guests, but I guess that's something acceptable, as
it's not a regression.

Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net

^ permalink raw reply

* Re: Long delays creating a netns after deleting one (possibly RCU related)
From: Paul E. McKenney @ 2016-11-14 16:24 UTC (permalink / raw)
  To: Cong Wang
  Cc: Rolf Neugebauer, LKML, Linux Kernel Network Developers,
	Justin Cormack, Ian Campbell
In-Reply-To: <CAM_iQpUq14GsvGyz2xA1PkDq5YO743T68Zh2zm=NJZQ9S2Ahqg@mail.gmail.com>

On Sun, Nov 13, 2016 at 10:47:01PM -0800, Cong Wang wrote:
> On Fri, Nov 11, 2016 at 4:55 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> > On Fri, Nov 11, 2016 at 4:23 PM, Paul E. McKenney
> > <paulmck@linux.vnet.ibm.com> wrote:
> >>
> >> Ah!  This net_mutex is different than RTNL.  Should synchronize_net() be
> >> modified to check for net_mutex being held in addition to the current
> >> checks for RTNL being held?
> >>
> >
> > Good point!
> >
> > Like commit be3fc413da9eb17cce0991f214ab0, checking
> > for net_mutex for this case seems to be an optimization, I assume
> > synchronize_rcu_expedited() and synchronize_rcu() have the same
> > behavior...
> 
> Thinking a bit more, I think commit be3fc413da9eb17cce0991f
> gets wrong on rtnl_is_locked(), the lock could be locked by other
> process not by the current one, therefore it should be
> lockdep_rtnl_is_held() which, however, is defined only when LOCKDEP
> is enabled... Sigh.
> 
> I don't see any better way than letting callers decide if they want the
> expedited version or not, but this requires changes of all callers of
> synchronize_net(). Hm.

I must confess that I don't understand how it would help to use an
expedited grace period when some other process is holding RTNL.
In contrast, I do well understand how it helps when the current process
is holding RTNL.

So what am I missing here?

							Thanx, Paul

^ permalink raw reply

* Re: [RFC PATCH v3 10/20] Add support to access boot related data in the clear
From: Tom Lendacky @ 2016-11-14 16:24 UTC (permalink / raw)
  To: Kani, Toshimitsu, kvm@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	kasan-dev@googlegroups.com, x86@kernel.org,
	iommu@lists.linux-foundation.org, linux-efi@vger.kernel.org,
	linux-arch@vger.kernel.org, linux-doc@vger.kernel.org
  Cc: matt@codeblueprint.co.uk, corbet@lwn.net, tglx@linutronix.de,
	konrad.wilk@oracle.com, joro@8bytes.org, dvyukov@google.com,
	aryabinin@virtuozzo.com, riel@redhat.com, lwoodman@redhat.com,
	mingo@redhat.com, hpa@zytor.com, luto@kernel.org,
	pbonzini@redhat.com, bp@alien8.de, glider@google.com,
	rkrcmar@redhat.com, arnd@arndb.de
In-Reply-To: <1478880929.20881.148.camel@hpe.com>

On 11/11/2016 10:17 AM, Kani, Toshimitsu wrote:
> On Wed, 2016-11-09 at 18:36 -0600, Tom Lendacky wrote:
>> Boot data (such as EFI related data) is not encrypted when the system
>> is booted and needs to be accessed unencrypted.  Add support to apply
>> the proper attributes to the EFI page tables and to the
>> early_memremap and memremap APIs to identify the type of data being
>> accessed so that the proper encryption attribute can be applied.
>  :
>> +static bool memremap_apply_encryption(resource_size_t phys_addr,
>> +				      unsigned long size)
>> +{
>> +	/* SME is not active, just return true */
>> +	if (!sme_me_mask)
>> +		return true;
>> +
>> +	/* Check if the address is part of the setup data */
>> +	if (memremap_setup_data(phys_addr, size))
>> +		return false;
>> +
>> +	/* Check if the address is part of EFI boot/runtime data */
>> +	switch (efi_mem_type(phys_addr)) {
>> +	case EFI_BOOT_SERVICES_DATA:
>> +	case EFI_RUNTIME_SERVICES_DATA:
>> +		return false;
>> +	}
>> +
>> +	/* Check if the address is outside kernel usable area */
>> +	switch (e820_get_entry_type(phys_addr, phys_addr + size -
>> 1)) {
>> +	case E820_RESERVED:
>> +	case E820_ACPI:
>> +	case E820_NVS:
>> +	case E820_UNUSABLE:
>> +		return false;
>> +	}
>> +
>> +	return true;
>> +}
> 
> Are you supporting encryption for E820_PMEM ranges?  If so, this
> encryption will persist across a reboot and does not need to be
> encrypted again, right?  Also, how do you keep a same key across a
> reboot?

The key will change across a reboot... so I need to look into this
more for memory that isn't used as traditional system ram.

Thanks,
Tom

> 
> Thanks,
> -Toshi
> 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply

* Re: [RFC PATCH v3 10/20] Add support to access boot related data in the clear
From: Tom Lendacky @ 2016-11-14 16:24 UTC (permalink / raw)
  To: Kani, Toshimitsu, kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
	kasan-dev-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org,
	x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
	iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
	linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
  Cc: riel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
	rkrcmar-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
	arnd-r2nGTMty4D4@public.gmane.org,
	pbonzini-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
	matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org,
	glider-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org,
	corbet-T1hC0tSOHrs@public.gmane.org,
	mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
	bp-Gina5bIWoIWzQB+pC5nmwQ@public.gmane.org,
	luto-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
	hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org,
	aryabinin-5HdwGun5lf+gSpxsJD1C4w@public.gmane.org,
	tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org,
	lwoodman-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
	dvyukov-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org
In-Reply-To: <1478880929.20881.148.camel-ZPxbGqLxI0U@public.gmane.org>

On 11/11/2016 10:17 AM, Kani, Toshimitsu wrote:
> On Wed, 2016-11-09 at 18:36 -0600, Tom Lendacky wrote:
>> Boot data (such as EFI related data) is not encrypted when the system
>> is booted and needs to be accessed unencrypted.  Add support to apply
>> the proper attributes to the EFI page tables and to the
>> early_memremap and memremap APIs to identify the type of data being
>> accessed so that the proper encryption attribute can be applied.
>  :
>> +static bool memremap_apply_encryption(resource_size_t phys_addr,
>> +				      unsigned long size)
>> +{
>> +	/* SME is not active, just return true */
>> +	if (!sme_me_mask)
>> +		return true;
>> +
>> +	/* Check if the address is part of the setup data */
>> +	if (memremap_setup_data(phys_addr, size))
>> +		return false;
>> +
>> +	/* Check if the address is part of EFI boot/runtime data */
>> +	switch (efi_mem_type(phys_addr)) {
>> +	case EFI_BOOT_SERVICES_DATA:
>> +	case EFI_RUNTIME_SERVICES_DATA:
>> +		return false;
>> +	}
>> +
>> +	/* Check if the address is outside kernel usable area */
>> +	switch (e820_get_entry_type(phys_addr, phys_addr + size -
>> 1)) {
>> +	case E820_RESERVED:
>> +	case E820_ACPI:
>> +	case E820_NVS:
>> +	case E820_UNUSABLE:
>> +		return false;
>> +	}
>> +
>> +	return true;
>> +}
> 
> Are you supporting encryption for E820_PMEM ranges?  If so, this
> encryption will persist across a reboot and does not need to be
> encrypted again, right?  Also, how do you keep a same key across a
> reboot?

The key will change across a reboot... so I need to look into this
more for memory that isn't used as traditional system ram.

Thanks,
Tom

> 
> Thanks,
> -Toshi
> 

^ permalink raw reply

* Re: [PATCH v2] kexec: Increase the upper limit for RAM segments
From: Goel, Sameer @ 2016-11-14 16:23 UTC (permalink / raw)
  To: xlpang, geoff; +Cc: kexec, bhe
In-Reply-To: <5829974D.4020901@redhat.com>

I meant MAX_MEMORY_RANGES. Updated KEXEC_SEGMENT_MAX to just match this. 
I can revert KEXEC_SEGMENT_MAX.

Thanks,
Sameer

On 11/14/2016 3:51 AM, Xunlei Pang wrote:
> On 2016/11/12 at 06:21, Sameer Goel wrote:
>> On a newer UEFI based Qualcomm target the number of system ram regions
>> retrieved from /proc/iomem are ~40. So increasing the current hardcoded
>> values to 64 from 16.
>
> I am a little confused, memory regions from /proc/iomem should be MAX_MEMORY_RANGES used
> as the elfcorehdr, while KEXEC_SEGMENT_MAX stands for the kexec segments passed to the kexec
> syscall, like kernel image, initrd image, purgatory, etc.
>
> Do you mean KEXEC_SEGMENT_MAX or MAX_MEMORY_RANGES?
>
> Regards,
> Xunlei
>
>>
>> Signed-off-by: Sameer Goel <sgoel@codeaurora.org>
>> ---
>>  kexec/arch/arm64/kexec-arm64.h | 2 +-
>>  kexec/kexec-syscall.h          | 2 +-
>>  2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/kexec/arch/arm64/kexec-arm64.h b/kexec/arch/arm64/kexec-arm64.h
>> index bac62f8..bd4c20e 100644
>> --- a/kexec/arch/arm64/kexec-arm64.h
>> +++ b/kexec/arch/arm64/kexec-arm64.h
>> @@ -11,7 +11,7 @@
>>  #include "image-header.h"
>>  #include "kexec.h"
>>
>> -#define KEXEC_SEGMENT_MAX 16
>> +#define KEXEC_SEGMENT_MAX 64
>>
>>  #define BOOT_BLOCK_VERSION 17
>>  #define BOOT_BLOCK_LAST_COMP_VERSION 16
>> diff --git a/kexec/kexec-syscall.h b/kexec/kexec-syscall.h
>> index c0d0bea..f84c937 100644
>> --- a/kexec/kexec-syscall.h
>> +++ b/kexec/kexec-syscall.h
>> @@ -115,7 +115,7 @@ static inline long kexec_file_load(int kernel_fd, int initrd_fd,
>>  #define KEXEC_ARCH_MIPS    ( 8 << 16)
>>  #define KEXEC_ARCH_CRIS    (76 << 16)
>>
>> -#define KEXEC_MAX_SEGMENTS 16
>> +#define KEXEC_MAX_SEGMENTS 64
>>
>>  #ifdef __i386__
>>  #define KEXEC_ARCH_NATIVE	KEXEC_ARCH_386
>
>

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply

* Re: [PATCH 00/13] topology: Update physical link support for ABI v5
From: Takashi Iwai @ 2016-11-14 16:23 UTC (permalink / raw)
  To: mengdong.lin
  Cc: alsa-devel, vinod.koul, hardik.t.shah, guneshwor.o.singh,
	liam.r.girdwood, broonie, mengdong.lin
In-Reply-To: <cover.1478407716.git.mengdong.lin@linux.intel.com>

On Sun, 06 Nov 2016 06:10:06 +0100,
mengdong.lin@linux.intel.com wrote:
> 
> From: Mengdong Lin <mengdong.lin@linux.intel.com>
> 
> This series completes support for physical DAI links of ABI v5, including
> ABI updates and code refactoring. The kernel can support the ABI updates
> in a backward compatible way.
> 
> There will be another small series for the remaining user space patches.
> 
> Mengdong Lin (13):
>   topology: Use snd_config_get_bool to simplify boolean flag parsing
>   topology: Merge an element's be & cc pointer to one link pointer
>   topology: Define a function to build a single physical DAI link
>   topology: ABI - Define DAI physical PCM data formats
>   topology: ABI - Update physical DAI link configurations to ABI v5
>   topology: Rename varaibles for add physical links by C API
>   topology: Define new type and section name to configure physical links
>   topology: Parse HW configurations of physical DAI links defined by C
>     API
>   topology: Parse HW configurations of physical DAI links in text conf
>     file
>   topology: Parse link flags of physical DAI links
>   topology: Parse and build private data of physical links
>   topology: Parse name and stream name of physical DAI links
>   topology: Remove BE or CC in comments of physical links C API template

Now merged all patches.  Thanks.


Takashi

^ permalink raw reply

* Re: linux-next: manual merge of the sound tree with the jc_docs tree
From: Takashi Iwai @ 2016-11-14 16:23 UTC (permalink / raw)
  To: Jonathan Corbet
  Cc: Stephen Rothwell, linux-next, linux-kernel, Jarkko Sakkinen,
	SeongJae Park
In-Reply-To: <20161114091159.670ada51@lwn.net>

On Mon, 14 Nov 2016 17:11:59 +0100,
Jonathan Corbet wrote:
> 
> On Mon, 14 Nov 2016 09:01:13 +0100
> Takashi Iwai <tiwai@suse.de> wrote:
> 
> > > Sigh.  I'm glad this work is being done, but if we're going to create
> > > some coordinated documentation it might be good to involve the docs
> > > maintainer when doing it...  
> > 
> > Sorry, will put you guys in Cc at the next time (although all
> > conversions have been done in the sound tree).
> 
> That's kind of my point.  The sound tree is not an appropriate place to be
> making changes to files like Documentation/index.rst.

Well, I meant just that I have *finished* all conversions in sound :)

> > > In this case, I would have liked the chance to comment.  This
> > > documentation belongs in the driver-api document, not the top-level
> > > one. So, in an ideal world, I'd like to see this stuff moved there,
> > > preferably with the patches going though the docs tree.  
> > 
> > If there needs any other changes, feel free to merge my
> > topic/restize-docs branch into yours and keep working there:
> >   git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
> > topic/resize-docs
> > 
> > It's based on vanilla 4.9-rc4, so it must be clean to be merged.  A
> > few misc fixes will come up in for-next branch, but they should be
> > harmless to your changes -- at least the api-related changes won't be
> > touched.
> 
> OK, I'll probably do that; expect me to run a patch by you that moves it
> to the proper place in the hierarchy.

Great, thanks.


Takashi

^ permalink raw reply

* Re: CfP Nov 18 2016 for FOSDEM 2017 Virtualization & IaaS DevRoom
From: Lars Kurth @ 2016-11-14 16:22 UTC (permalink / raw)
  To: Xen-devel, mirageos-devel, xen-users
In-Reply-To: <BF74B8CD-8409-4A40-83B7-689E8C1DB634@gmail.com>

Hi all,
a quick reminder that the CfP is closing on Friday
Lars

> On 19 Oct 2016, at 12:01, Lars Kurth <lars.kurth.xen@gmail.com> wrote:
> 
> Hi all,
> 
> I am co-organizing the FOSDEM 2017 Virtualization & IaaS DevRoom next year again. The CfP for the DevRoom is now open at http://www.ovirt.org/blog/2016/10/call-for-proposal-fosdem-2017/
> 
> Feel free to contact me with any questions
> 
> Regards
> Lars


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

^ permalink raw reply

* Re: GIT Problem/ISSUE
From: Konstantin Khomoutov @ 2016-11-14 16:22 UTC (permalink / raw)
  To: Robert Fellendorf; +Cc: git
In-Reply-To: <a3751faa-91b5-2ce8-767a-a25e25f23433@googlemail.com>

On Mon, 14 Nov 2016 16:59:41 +0100
Robert Fellendorf <robert.fellendorf@googlemail.com> wrote:

[...]
> Couldn't resolve host 'gitlab.lrz.de'
[...]

So, what happens when you open a console prompt (Click the Start menu
icon, type "cmd" without the double quotes and activate the application
found), type

  ping gitlab.lrz.de

there and hit the Enter key?

Does it successfully sends three network packets or you do get the
same/similar error message about the hostname "gitlab.lrz.de" being not
resolvable?

As it stands, this issue looks completely unrelated to Git -- please
read the Wikipedia page on the Domain Name System (DNS) for a start.

^ permalink raw reply

* Re: [PATCH 1/3] idle: add support for tasks that inject idle
From: Peter Zijlstra @ 2016-11-14 16:22 UTC (permalink / raw)
  To: Jacob Pan
  Cc: LKML, Linux PM, Thomas Gleixner, Ingo Molnar, Zhang Rui,
	Rafael Wysocki, Chen, Yu C, Sebastian Andrzej Siewior,
	Petr Mladek, Srinivas Pandruvada, Arjan van de Ven
In-Reply-To: <20161114082028.6c0ce338@jacob-builder>

On Mon, Nov 14, 2016 at 08:20:28AM -0800, Jacob Pan wrote:
> On Mon, 14 Nov 2016 16:01:19 +0100
> Peter Zijlstra <peterz@infradead.org> wrote:
> 
> > On Wed, Nov 09, 2016 at 11:05:10AM -0800, Jacob Pan wrote:
> > > +void play_idle()
> > > +{
> > > +	/*
> > > +	 * Only FIFO tasks can disable the tick since they don't
> > > need the forced
> > > +	 * preemption.
> > > +	 */
> > > +	WARN_ON_ONCE(current->policy != SCHED_FIFO);
> > > +	WARN_ON_ONCE(current->nr_cpus_allowed != 1);
> > > +	WARN_ON_ONCE(!(current->flags & PF_KTHREAD));
> > > +	WARN_ON_ONCE(!(current->flags & PF_NO_SETAFFINITY));
> > > +	rcu_sleep_check();
> > > +
> > > +	preempt_disable();
> > > +	current->flags |= PF_IDLE;
> > > +	do_idle();
> > > +	current->flags &= ~PF_IDLE;
> > > +
> > > +	preempt_fold_need_resched();
> > > +	preempt_enable();
> > > +}
> > > +EXPORT_SYMBOL_GPL(play_idle);  
> > 
> > Hurm.. didn't this initially also include the setup of the timer and
> > take an timeout argument?
> 
> right, the initial version has a timeout and
> 	init_timer_on_stack(timer);
> 
> I thought since this play_idle timer is likely to expire instead of
> being canceled, so I switched to hrtimer by caller. We don't have an on
> stack hrtimer, right? or Should we consider adding one?

hrtimer_init_on_stack() exists.

^ permalink raw reply

* [Bug 98170] [vdpau] Error when calling vdp_output_surface_create
From: bugzilla-daemon @ 2016-11-14 16:22 UTC (permalink / raw)
  To: dri-devel
In-Reply-To: <bug-98170-502@http.bugs.freedesktop.org/>


[-- Attachment #1.1: Type: text/plain, Size: 207 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=98170

--- Comment #8 from Branko <bagzy92@gmail.com> ---
FIXED In mesa-13.0.1.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 1038 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply


This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.