{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":115159616,"defaultBranch":"master","name":"nanos","ownerLogin":"nanovms","currentUserCanPush":false,"isFork":false,"isEmpty":false,"createdAt":"2017-12-23T00:25:34.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/38020270?v=4","public":true,"private":false,"isOrgOwned":true},"refInfo":{"name":"","listCacheKey":"v0:1717690671.0","currentOid":""},"activityList":{"items":[{"before":"8d7b5d57f760ba65b252fd7a1ec847aed7c0a23f","after":"355607a69a8289388c2d9274a3b2b0970e5e1947","ref":"refs/heads/feature/strace","pushedAt":"2024-06-07T08:16:57.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"francescolavra","name":"Francesco Lavra","path":"/francescolavra","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10710577?s=80&v=4"},"commit":{"message":"Klibs: add strace\n\nThis change adds a new \"strace\" klib which implements the main\nfunctionality of the Linux strace tool, i.e. can output records\nfor each syscall invoked by the user program, and can calculate\nrelevant statistics such as number of occurrences and execution\ntime.\nMost of the `thread_log()` macro calls in the Unix code in the\nkernel are being removed because they are redundant with the\ncorresponding strace output records; likewise, the code that\nimplements collection and reporting of syscall statistics is being\nmoved from the core syscall code to the strace klib. These changes,\ntogether with the removal of several related variables and struct\nfields, bring a reduction of the kernel binary size by 2.5%.\nThe manifest options that are used to confgure syscall tracing and\nstatistics collection (namely, `debugsyscalls`, `notrace`,\n`tracelist`, and `syscall_summary`) remain the same, but are now\nacted upon by the strace klib instead of the main kernel, thus they\ntake effect only if the strace klib is included in an image.\nThe `trace` manifest option is still handled in the main kernel\ncode, but now it only controls tracing of kernel internals.","shortMessageHtmlLink":"Klibs: add strace"}},{"before":"d2278dec8e1986ec4d0b9659d3779bc862aa9d1a","after":"8d7b5d57f760ba65b252fd7a1ec847aed7c0a23f","ref":"refs/heads/feature/strace","pushedAt":"2024-06-07T07:35:51.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"francescolavra","name":"Francesco Lavra","path":"/francescolavra","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10710577?s=80&v=4"},"commit":{"message":"Klibs: add strace\n\nThis change adds a new \"strace\" klib which implements the main\nfunctionality of the Linux strace tool, i.e. can output records\nfor each syscall invoked by the user program, and can calculate\nrelevant statistics such as number of occurrences and execution\ntime.\nMost of the `thread_log()` macro calls in the Unix code in the\nkernel are being removed because they are redundant with the\ncorresponding strace output records; likewise, the code that\nimplements collection and reporting of syscall statistics is being\nmoved from the core syscall code to the strace klib. These changes,\ntogether with the removal of several related variables and struct\nfields, bring a reduction of the kernel binary size by 2.5%.\nThe manifest options that are used to confgure syscall tracing and\nstatistics collection (namely, `debugsyscalls`, `notrace`,\n`tracelist`, and `syscall_summary`) remain the same, but are now\nacted upon by the strace klib instead of the main kernel, thus they\ntake effect only if the strace klib is included in an image.\nThe `trace` manifest option is still handled in the main kernel\ncode, but now it only controls tracing of kernel internals.","shortMessageHtmlLink":"Klibs: add strace"}},{"before":null,"after":"d2278dec8e1986ec4d0b9659d3779bc862aa9d1a","ref":"refs/heads/feature/strace","pushedAt":"2024-06-06T16:17:51.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"francescolavra","name":"Francesco Lavra","path":"/francescolavra","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10710577?s=80&v=4"},"commit":{"message":"Klibs: add strace\n\nThis change adds a new \"strace\" klib which implements the main\nfunctionality of the Linux strace tool, i.e. can output trace\nrecords for each syscall invoked by the user program, and can\ncalculate relevant statistics such as number of occurrences and\nexecution time.\nMost of the `thread_log()` macro calls in the Unix code in the\nkernel are being removed because they are redundant with the\ncorresponding strace output records; likewise, the code that\nimplements collection and reporting of syscall statistics is being\nmoved from the core syscall code to the strace klib. These changes,\ntogether with the removal of several related variables and struct\nfields, bring a reduction of the kernel binary size by 2.5%.\nThe manifest options that are used to confgure syscall tracing and\nstatistics collection (namely, `debugsyscalls`, `notrace`,\n`tracelist`, and `syscall_summary`) remain the same, but are now\nacted upon by the strace klib instead of the main kernel, thus they\ntake effect only if the strace klib is included in an image.\nThe `trace` manifest option is still handled in the main kernel\ncode, but now it only controls tracing of kernel internals.","shortMessageHtmlLink":"Klibs: add strace"}},{"before":"033a1ed3a12c1f9d51a5fbd7d2831c60036f9db9","after":null,"ref":"refs/heads/feature/file-sealing","pushedAt":"2024-06-06T15:07:08.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"francescolavra","name":"Francesco Lavra","path":"/francescolavra","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10710577?s=80&v=4"}},{"before":"a92295e7fe3a2b68c958275e4debd6ff6f6cd10c","after":"033a1ed3a12c1f9d51a5fbd7d2831c60036f9db9","ref":"refs/heads/master","pushedAt":"2024-06-06T15:06:59.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"francescolavra","name":"Francesco Lavra","path":"/francescolavra","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10710577?s=80&v=4"},"commit":{"message":"memfd_create(): add support for file sealing\n\nThis change enhances the tmpfs implementation so that it supports\nfile sealing, and modifies memfd_create() so that it acts upon the\nMFD_ALLOW_SEALING flag when configuring the initial set of seals\nfor the underlying tmpfs file.\nThe fcntl() syscall now accepts 2 additional commands, needed for\nfile sealing operations: F_ADD_SEALS and F_GET_SEALS.\nThe fcntl runtime test has been amended to exercise this new\nfeature.","shortMessageHtmlLink":"memfd_create(): add support for file sealing"}},{"before":"21610522f4ccfee386f11d630fae54e2f51ca423","after":"5779988b058f7bd4885de58830d48f843d36dcd7","ref":"refs/heads/feature/cpu-affinity","pushedAt":"2024-05-29T16:06:39.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"francescolavra","name":"Francesco Lavra","path":"/francescolavra","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10710577?s=80&v=4"},"commit":{"message":"CI: execute runtime tests on 2-vCPU instances\n\nThis change amends the CircleCI configuration so that automated\ntests are run on 2-vCPU instances, in order to increase test\ncoverage of SMP-related kernel code.\nThe platform-specific Makefiles now support specifying a vCPU\ncount (via the `VCPUS` variable) in the command line when running a\ntest program; example command line to run the thread_test program\non a 2-vCPU instance: `make VCPUS=2 TARGET=thread_test run`","shortMessageHtmlLink":"CI: execute runtime tests on 2-vCPU instances"}},{"before":"9dec0b472af13549c43f268f7c27d93d37799b33","after":"21610522f4ccfee386f11d630fae54e2f51ca423","ref":"refs/heads/feature/cpu-affinity","pushedAt":"2024-05-29T10:00:52.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"francescolavra","name":"Francesco Lavra","path":"/francescolavra","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10710577?s=80&v=4"},"commit":{"message":"CI: execute runtime tests on 2-vCPU instances\n\nThis change amends the CircleCI configuration so that automated\ntests are run on 2-vCPU instances, in order to increase test\ncoverage of SMP-related kernel code.\nThe platform-specific Makefiles now support specifying a vCPU\ncount (via the `VCPUS` variable) in the command line when running a\ntest program; example command line to run the thread_test program\non a 2-vCPU instance: `make VCPUS=2 TARGET=thread_test run`","shortMessageHtmlLink":"CI: execute runtime tests on 2-vCPU instances"}},{"before":"717c65118a75b317f4f3fd4eb9c62b6c1cfcf92e","after":"9dec0b472af13549c43f268f7c27d93d37799b33","ref":"refs/heads/feature/cpu-affinity","pushedAt":"2024-05-27T16:59:20.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"francescolavra","name":"Francesco Lavra","path":"/francescolavra","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10710577?s=80&v=4"},"commit":{"message":"CI: execute runtime tests on 2-vCPU instances\n\nThis change amends the CircleCI configuration so that automated\ntests are run on 2-vCPU instances, in order to increase test\ncoverage of SMP-related kernel code.\nThe platform-specific Makefiles now support specifying a vCPU\ncount (via the `VCPUS` variable) in the command line when running a\ntest program; example command line to run the thread_test program\non a 2-vCPU instance: `make VCPUS=2 TARGET=thread_test run`","shortMessageHtmlLink":"CI: execute runtime tests on 2-vCPU instances"}},{"before":"4d5e9527b13c2c6cbc2a7c245129890ad5a56e84","after":"033a1ed3a12c1f9d51a5fbd7d2831c60036f9db9","ref":"refs/heads/feature/file-sealing","pushedAt":"2024-05-27T14:11:09.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"francescolavra","name":"Francesco Lavra","path":"/francescolavra","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10710577?s=80&v=4"},"commit":{"message":"memfd_create(): add support for file sealing\n\nThis change enhances the tmpfs implementation so that it supports\nfile sealing, and modifies memfd_create() so that it acts upon the\nMFD_ALLOW_SEALING flag when configuring the initial set of seals\nfor the underlying tmpfs file.\nThe fcntl() syscall now accepts 2 additional commands, needed for\nfile sealing operations: F_ADD_SEALS and F_GET_SEALS.\nThe fcntl runtime test has been amended to exercise this new\nfeature.","shortMessageHtmlLink":"memfd_create(): add support for file sealing"}},{"before":null,"after":"4d5e9527b13c2c6cbc2a7c245129890ad5a56e84","ref":"refs/heads/feature/file-sealing","pushedAt":"2024-05-27T12:00:16.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"francescolavra","name":"Francesco Lavra","path":"/francescolavra","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10710577?s=80&v=4"},"commit":{"message":"memfd_create(): add support for file sealing\n\nThe change enhances the tmpfs implementation so that it supports\nfile sealing, and modifes memfd_create() so that it acts upon the\nMFD_ALLOW_SEALING flag when configuring the initial set of seals\nfor the underlying tmpfs file.\nThe fcntl() syscall now accepts the additional commands needed for\nfile sealing operations: F_ADD_SEALS and F_GET_SEALS.\nThe fcntl runtime test has been amended to exercise this new\nfeature.","shortMessageHtmlLink":"memfd_create(): add support for file sealing"}},{"before":"216fb2bc77a30442d6dc2856c57bcf98d4298dc6","after":"717c65118a75b317f4f3fd4eb9c62b6c1cfcf92e","ref":"refs/heads/feature/cpu-affinity","pushedAt":"2024-05-27T11:25:31.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"francescolavra","name":"Francesco Lavra","path":"/francescolavra","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10710577?s=80&v=4"},"commit":{"message":"CI: execute runtime tests on 2-vCPU instances\n\nThis change amends the CircleCI configuration so that automated\ntests are run on 2-vCPU instances, in order to increase test\ncoverage of SMP-related kernel code.\nThe platform-specific Makefiles now support specifying a vCPU\ncount (via the `VCPUS` variable) in the command line when running a\ntest program; example command line to run the thread_test program\non a 2-vCPU instance: `make VCPUS=2 TARGET=thread_test run`","shortMessageHtmlLink":"CI: execute runtime tests on 2-vCPU instances"}},{"before":"a92295e7fe3a2b68c958275e4debd6ff6f6cd10c","after":null,"ref":"refs/heads/feature/azure-metrics","pushedAt":"2024-05-27T11:17:59.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"francescolavra","name":"Francesco Lavra","path":"/francescolavra","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10710577?s=80&v=4"}},{"before":"353490f023231aa1ed0b86d3a219ef899e776781","after":"a92295e7fe3a2b68c958275e4debd6ff6f6cd10c","ref":"refs/heads/master","pushedAt":"2024-05-27T11:17:53.000Z","pushType":"push","commitsCount":10,"pusher":{"login":"francescolavra","name":"Francesco Lavra","path":"/francescolavra","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10710577?s=80&v=4"},"commit":{"message":"Azure: implement sending memory metrics via diagnostic extension\n\nThis change adds a new \"azure\" klib that implements an Azure\nextension similar to the Linux Diagnostic extension.\nThe current implementation supports sending 4 types of memory\nmetrics (i.e. available and used memory, as both number of bytes\nand percentage of total memory).\nThis klib is configured in the manifest options via an \"azure\"\ntuple; the diagnostic functionalities are enabled and configured by\ninserting a \"diagnostic\" tuple with the following attributes:\n- storage_account: indicates the Azure storage account to be used\nto store metrics data generated by the klib; the storage account\nmust be located in the same region as the region where the Azure\ninstance is deployed\n- storage_account_sas: Shared Access Signature token for accessing\nthe storage account: this token must have proper permissions to\ncreate Azure storage tables and add table entities in the above\nstorage account; SAS tokens for a given storage account can be\ngenerated for example via the Azure portal in the\n\"Security + networking\" menu.\n- metrics: tuple that enables sending memory metrics; it can\ncontain 2 optional attributes:\n  - sample_interval: interval expressed in seconds at which metrics\ndata is collected (default: 15)\n  - transfer_interval: interval expressed in seconds at which\nmetrics data is aggregated and sent to the storage account\n(default: 60)\n\nExample snippet of Ops configuration file:\n```\n\"ManifestPassthrough\": {\n  \"azure\": {\n    \"diagnostics\": {\n      \"storage_account\": \"mystorageaccount\",\n      \"storage_account_sas\": \"sv=2022-11-02&ss=bfqt&srt=sco&sp=rwdlacupiytfx&se=2024-05-22T14:50:28Z&st=2024-05-12T06:50:28Z&spr=https&sig=xxyyzz\",\n      \"metrics\": {\"sample_interval\": \"15\",\"transfer_interval\": \"60\"}\n    }\n  }\n}\n```\n\nAggregated memory metrics data consist of the number of samples,\nthe minimum, maximum, last, and average value, and the sum of all\nvalues; these data are inserted in an Azure storage table (one\nentity per aggregated data). The name of the table is in the format\n\"WADMetricsxxxxP10DV2Syyyymmdd\", where xxxx is the transfer\ninterval expressed with ISO8601 format, and yyyymmdd is a\nrepresentation of the 10-day date interval to which the metrics\nrefer (thus, a new table is created every 10 days). For example, a\ntable named WADMetricsPT1MP10DV2S20240503 contains metrics data\naggregated every minute (\"PT1M\" is the ISO8601 representation of a\n1-minute period) generated for a 10-day period starting on May 3,\n2024.\n\nBy default, the Azure portal does not display these metrics in its\ncharts; in order for metrics to be available in the portal, the\nLinux Diagnostics Extension must be enabled and configured in a\nrunning instance (this can be done in the \"Diagnostic settings\"\nsection in the portal) to match the settings in the Nanos manifest\noptions. More specifically, the storage account and the metric\naggregation interval specified in the Azure diagnostic settings\nmust match those specified in the manifest options.\nNote: the Azure VM agent implemented in the cloud_init klib\nresponds to requests to enable and configure the diagnostic\nextension, but does not actually apply the extension settings\nspecified in the requests; instead, it always applies the settings\nfrom the manifest.\n\nCloses #2014","shortMessageHtmlLink":"Azure: implement sending memory metrics via diagnostic extension"}},{"before":"9dc963bb2773b7a3dcb39aade3556350babae16b","after":"a92295e7fe3a2b68c958275e4debd6ff6f6cd10c","ref":"refs/heads/feature/azure-metrics","pushedAt":"2024-05-27T10:57:22.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"francescolavra","name":"Francesco Lavra","path":"/francescolavra","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10710577?s=80&v=4"},"commit":{"message":"Azure: implement sending memory metrics via diagnostic extension\n\nThis change adds a new \"azure\" klib that implements an Azure\nextension similar to the Linux Diagnostic extension.\nThe current implementation supports sending 4 types of memory\nmetrics (i.e. available and used memory, as both number of bytes\nand percentage of total memory).\nThis klib is configured in the manifest options via an \"azure\"\ntuple; the diagnostic functionalities are enabled and configured by\ninserting a \"diagnostic\" tuple with the following attributes:\n- storage_account: indicates the Azure storage account to be used\nto store metrics data generated by the klib; the storage account\nmust be located in the same region as the region where the Azure\ninstance is deployed\n- storage_account_sas: Shared Access Signature token for accessing\nthe storage account: this token must have proper permissions to\ncreate Azure storage tables and add table entities in the above\nstorage account; SAS tokens for a given storage account can be\ngenerated for example via the Azure portal in the\n\"Security + networking\" menu.\n- metrics: tuple that enables sending memory metrics; it can\ncontain 2 optional attributes:\n  - sample_interval: interval expressed in seconds at which metrics\ndata is collected (default: 15)\n  - transfer_interval: interval expressed in seconds at which\nmetrics data is aggregated and sent to the storage account\n(default: 60)\n\nExample snippet of Ops configuration file:\n```\n\"ManifestPassthrough\": {\n  \"azure\": {\n    \"diagnostics\": {\n      \"storage_account\": \"mystorageaccount\",\n      \"storage_account_sas\": \"sv=2022-11-02&ss=bfqt&srt=sco&sp=rwdlacupiytfx&se=2024-05-22T14:50:28Z&st=2024-05-12T06:50:28Z&spr=https&sig=xxyyzz\",\n      \"metrics\": {\"sample_interval\": \"15\",\"transfer_interval\": \"60\"}\n    }\n  }\n}\n```\n\nAggregated memory metrics data consist of the number of samples,\nthe minimum, maximum, last, and average value, and the sum of all\nvalues; these data are inserted in an Azure storage table (one\nentity per aggregated data). The name of the table is in the format\n\"WADMetricsxxxxP10DV2Syyyymmdd\", where xxxx is the transfer\ninterval expressed with ISO8601 format, and yyyymmdd is a\nrepresentation of the 10-day date interval to which the metrics\nrefer (thus, a new table is created every 10 days). For example, a\ntable named WADMetricsPT1MP10DV2S20240503 contains metrics data\naggregated every minute (\"PT1M\" is the ISO8601 representation of a\n1-minute period) generated for a 10-day period starting on May 3,\n2024.\n\nBy default, the Azure portal does not display these metrics in its\ncharts; in order for metrics to be available in the portal, the\nLinux Diagnostics Extension must be enabled and configured in a\nrunning instance (this can be done in the \"Diagnostic settings\"\nsection in the portal) to match the settings in the Nanos manifest\noptions. More specifically, the storage account and the metric\naggregation interval specified in the Azure diagnostic settings\nmust match those specified in the manifest options.\nNote: the Azure VM agent implemented in the cloud_init klib\nresponds to requests to enable and configure the diagnostic\nextension, but does not actually apply the extension settings\nspecified in the requests; instead, it always applies the settings\nfrom the manifest.\n\nCloses #2014","shortMessageHtmlLink":"Azure: implement sending memory metrics via diagnostic extension"}},{"before":"62bcdb85a5f400e6cb9fea99ff418e0a1984aeae","after":null,"ref":"refs/heads/bumpxcode","pushedAt":"2024-05-24T02:31:14.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"eyberg","name":"Ian Eyberg","path":"/eyberg","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22410?s=80&v=4"}},{"before":"ec9976d39bcfd6042862a9f12d2eb77c39cfec4e","after":"353490f023231aa1ed0b86d3a219ef899e776781","ref":"refs/heads/master","pushedAt":"2024-05-24T02:31:10.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"eyberg","name":"Ian Eyberg","path":"/eyberg","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22410?s=80&v=4"},"commit":{"message":"bump xcode (#2026)","shortMessageHtmlLink":"bump xcode (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2311818959\" data-permission-text=\"Title is private\" data-url=\"https://github.com/nanovms/nanos/issues/2026\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/nanovms/nanos/pull/2026/hovercard\" href=\"https://github.com/nanovms/nanos/pull/2026\">#2026</a>)"}},{"before":null,"after":"62bcdb85a5f400e6cb9fea99ff418e0a1984aeae","ref":"refs/heads/bumpxcode","pushedAt":"2024-05-23T02:42:28.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"eyberg","name":"Ian Eyberg","path":"/eyberg","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22410?s=80&v=4"},"commit":{"message":"bump xcode","shortMessageHtmlLink":"bump xcode"}},{"before":"c10057da39d0432da51c1180b69a7a6721e16625","after":"216fb2bc77a30442d6dc2856c57bcf98d4298dc6","ref":"refs/heads/feature/cpu-affinity","pushedAt":"2024-05-17T15:02:09.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"francescolavra","name":"Francesco Lavra","path":"/francescolavra","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10710577?s=80&v=4"},"commit":{"message":"CI: execute runtime tests on 2-vCPU instances\n\nThis change amends the CircleCI configuration so that automated\ntests are run on 2-vCPU instances, in order to increase test\ncoverage of SMP-related kernel code.\nThe platform-specific Makefiles now support specifying a vCPU\ncount (via the VCPU variable) in the command line when running a\ntest program; example command line to run the thread_test program\non a 2-vCPU instance: `make VCPUS=2 TARGET=thread_test run`","shortMessageHtmlLink":"CI: execute runtime tests on 2-vCPU instances"}},{"before":"ec9976d39bcfd6042862a9f12d2eb77c39cfec4e","after":null,"ref":"refs/heads/fix/kernel-limit","pushedAt":"2024-05-17T14:56:44.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"francescolavra","name":"Francesco Lavra","path":"/francescolavra","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10710577?s=80&v=4"}},{"before":"4668594719ace9ea3bf02d1c7a27c1fb416041a6","after":"ec9976d39bcfd6042862a9f12d2eb77c39cfec4e","ref":"refs/heads/master","pushedAt":"2024-05-17T14:56:36.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"francescolavra","name":"Francesco Lavra","path":"/francescolavra","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10710577?s=80&v=4"},"commit":{"message":"x86: fix overlapping of kernel addresses with vsyscall page\n\nIn the x86_64 architecture, the KERNEL_LIMIT constant is currently\nset to 0xfffffffffffff000; if the KASLR process places the kernel\nnear the limit of the address range, kernel addresses may overlap\nwith the vsyscall page, which always starts at a fixed address\n(0xffffffffff600000u); this may cause boot failures such as in\nhttps://app.circleci.com/pipelines/github/nanovms/nanos/4631/workflows/1400a162-d5c4-478d-8cc8-bdf84ab2536a/jobs/16261.\nThis change fixes the above issue by changing the KERNEL_LIMIT\nconstant to coincide wit the start of the vsyscall page.","shortMessageHtmlLink":"x86: fix overlapping of kernel addresses with vsyscall page"}},{"before":null,"after":"ec9976d39bcfd6042862a9f12d2eb77c39cfec4e","ref":"refs/heads/fix/kernel-limit","pushedAt":"2024-05-17T11:00:30.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"francescolavra","name":"Francesco Lavra","path":"/francescolavra","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10710577?s=80&v=4"},"commit":{"message":"x86: fix overlapping of kernel addresses with vsyscall page\n\nIn the x86_64 architecture, the KERNEL_LIMIT constant is currently\nset to 0xfffffffffffff000; if the KASLR process places the kernel\nnear the limit of the address range, kernel addresses may overlap\nwith the vsyscall page, which always starts at a fixed address\n(0xffffffffff600000u); this may cause boot failures such as in\nhttps://app.circleci.com/pipelines/github/nanovms/nanos/4631/workflows/1400a162-d5c4-478d-8cc8-bdf84ab2536a/jobs/16261.\nThis change fixes the above issue by changing the KERNEL_LIMIT\nconstant to coincide wit the start of the vsyscall page.","shortMessageHtmlLink":"x86: fix overlapping of kernel addresses with vsyscall page"}},{"before":"04c7ccdeb7f868eaabbd38c7ee4257c8a0afaf4e","after":"c10057da39d0432da51c1180b69a7a6721e16625","ref":"refs/heads/feature/cpu-affinity","pushedAt":"2024-05-17T10:49:33.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"francescolavra","name":"Francesco Lavra","path":"/francescolavra","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10710577?s=80&v=4"},"commit":{"message":"CI: execute runtime tests on 2-vCPU instances\n\nThis change amends the CircleCI configuration so that automated\ntests are run on 2-vCPU instances, in order to increase test\ncoverage of SMP-related kernel code.\nThe platform-specific Makefiles now support specifying a vCPU\ncount (via the VCPU variable) in the command line when running a\ntest program; example command line to run the thread_test program\non a 2-vCPU instance: `make VCPUS=2 TARGET=thread_test run`","shortMessageHtmlLink":"CI: execute runtime tests on 2-vCPU instances"}},{"before":"544856bf5c08de442f9a43f01e3911775d2364f5","after":"04c7ccdeb7f868eaabbd38c7ee4257c8a0afaf4e","ref":"refs/heads/feature/cpu-affinity","pushedAt":"2024-05-16T16:09:22.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"francescolavra","name":"Francesco Lavra","path":"/francescolavra","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10710577?s=80&v=4"},"commit":{"message":"CI: execute runtime tests on 2-vCPU instances\n\nThis change amends the CircleCI configuration so that automated\ntests are run on 2-vCPU instances, in order to increase test\ncoverage of SMP-related kernel code.\nThe platform-specific Makefiles now support specifying a vCPU\ncount (via the VCPU variable) in the command line when running a\ntest program; example command line to run the thread_test program\non a 2-vCPU instance: `make VCPUS=2 TARGET=thread_test run`","shortMessageHtmlLink":"CI: execute runtime tests on 2-vCPU instances"}},{"before":"240379da9f64a753eef18b4b997b3e6e1c6940f9","after":"544856bf5c08de442f9a43f01e3911775d2364f5","ref":"refs/heads/feature/cpu-affinity","pushedAt":"2024-05-16T09:37:05.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"francescolavra","name":"Francesco Lavra","path":"/francescolavra","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10710577?s=80&v=4"},"commit":{"message":"CI: execute runtime tests on 2-vCPU instances\n\nThis change amends the CircleCI configuration so that automated\ntests are run on 2-vCPU instances, in order to increase test\ncoverage of SMP-related kernel code.\nThe platform-specific Makefiles now support specifying a vCPU\ncount (via the VCPU variable) in the command line when running a\ntest program; example command line to run the thread_test program\non a 2-vCPU instance: `make VCPUS=2 TARGET=thread_test run`","shortMessageHtmlLink":"CI: execute runtime tests on 2-vCPU instances"}},{"before":null,"after":"240379da9f64a753eef18b4b997b3e6e1c6940f9","ref":"refs/heads/feature/cpu-affinity","pushedAt":"2024-05-15T16:52:44.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"francescolavra","name":"Francesco Lavra","path":"/francescolavra","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10710577?s=80&v=4"},"commit":{"message":"CI: execute runtime tests on 2-vCPU instances\n\nThis change amends the CircleCI configuration so that automated\ntests are run on 2-vCPU instances, in order to increase test\ncoverage of SMP-related kernel code.\nThe platform-specific Makefiles now support specifying a vCPU\ncount (via the VCPU variable) in the command line when running a\ntest program; example command line to run the thread_test program\non a 2-vCPU instance: `make VCPUS=2 TARGET=thread_test run`","shortMessageHtmlLink":"CI: execute runtime tests on 2-vCPU instances"}},{"before":"8f6e5fc7b67fd1c78e5af2d5360cd4f07c0e9b5d","after":"9dc963bb2773b7a3dcb39aade3556350babae16b","ref":"refs/heads/feature/azure-metrics","pushedAt":"2024-05-12T14:36:59.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"francescolavra","name":"Francesco Lavra","path":"/francescolavra","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10710577?s=80&v=4"},"commit":{"message":"Azure: implement sending memory metrics via diagnostic extension\n\nThis change adds a new \"azure\" klib that implements an Azure\nextension similar to the Linux Diagnostic extension.\nThe current implementation supports sending 4 types of memory\nmetrics (i.e. available and used memory, as both number of bytes\nand percentage of total memory).\nThis klib is configured in the manifest options via an \"azure\"\ntuple; the diagnostic functionalities are enabled and configured by\ninserting a \"diagnostic\" tuple with the following attributes:\n- storage_account: indicates the Azure storage account to be used\nto store metrics data generated by the klib; the storage account\nmust be located in the same region as the region where the Azure\ninstance is deployed\n- storage_account_sas: Shared Access Signature token for accessing\nthe storage account: this token must have proper permissions to\ncreate Azure storage tables and add table entities in the above\nstorage account; SAS tokens for a given storage account can be\ngenerated for example via the Azure portal in the\n\"Security + networking\" menu.\n- metrics: tuple that enables sending memory metrics; it can\ncontain 2 optional attributes:\n  - sample_interval: interval expressed in seconds at which metrics\ndata is collected (default: 15)\n  - transfer_interval: interval expressed in seconds at which\nmetrics data is aggregated and sent to the storage account\n(default: 60)\n\nExample snippet of Ops configuration file:\n```\n\"ManifestPassthrough\": {\n  \"azure\": {\n    \"diagnostics\": {\n      \"storage_account\": \"mystorageaccount\",\n      \"storage_account_sas\": \"sv=2022-11-02&ss=bfqt&srt=sco&sp=rwdlacupiytfx&se=2024-05-22T14:50:28Z&st=2024-05-12T06:50:28Z&spr=https&sig=xxyyzz\",\n      \"metrics\": {\"sample_interval\": \"15\",\"transfer_interval\": \"60\"}\n    }\n  }\n}\n```\n\nAggregated memory metrics data consist of the number of samples,\nthe minimum, maximum, last, and average value, and the sum of all\nvalues; these data are insterted in an Azure storage table (one\nentity per aggregated data). The name of the table is in the format\n\"WADMetricsxxxxP10DV2Syyyymmdd\", where xxxx is the transfer\ninterval expressed with ISO8601 format, and yyyymmdd is a\nrepresentation of the 10-day date interval to which the metrics\nrefer (thus, a new table is created every 10 days). For example, a\ntable named WADMetricsPT1MP10DV2S20240503 contains metrics data\naggregated every minute (\"PT1M\" is the ISO8601 representation of a\n1-minute period) generated for a 10-day period starting on May 3,\n2024.\n\nBy default, the Azure portal does not display these metrics in its\ncharts; in order for metrics to be available in the portal, the\nLinux Diagnostics Extension must be enabled and configured in a\nrunning instance (this can be done in the \"Diagnostic settings\"\nsection in the portal) to match the settings in the Nanos manifest\noptions. More specifically, the storage account and the metric\naggregation interval specified in the Azure diagnostic settings\nmust match those specified in the manifest options.\nNote: the Azure VM agent implemented in the cloud_init klib\nresponds to requests to enable and configure the diagnostic\nextension, but does not actually apply the extension settings\nspecified in the requests; instead, it always applies the settings\nfrom the manifest.\n\nCloses #2014","shortMessageHtmlLink":"Azure: implement sending memory metrics via diagnostic extension"}},{"before":"bd7e49e5c037e53c6fd4f393f0b6c9ad4e1c95a8","after":"8f6e5fc7b67fd1c78e5af2d5360cd4f07c0e9b5d","ref":"refs/heads/feature/azure-metrics","pushedAt":"2024-05-12T11:04:13.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"francescolavra","name":"Francesco Lavra","path":"/francescolavra","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10710577?s=80&v=4"},"commit":{"message":"Azure: implement sending memory metrics via diagnostic extension\n\nThis change adds a new \"azure\" klib that implements an Azure\nextension similar to the Linux Diagnostic extension.\nThe current implementation supports sending 4 types of memory\nmetrics (i.e. available and used memory, both as number of bytes\nas a percentage of total memory).\nThis klib is configured in the manifest options via an \"azure\"\ntuple; the diagnostic functionalities are enabled and configured by\ninserting a \"diagnostic\" tuple with the folowing attributes:\n- storage_account: indicates the Azure storage account to be used\nto store metrics data generated by the klib; the storage account\nmust be located in the same region as the region where the Azure\ninstance is deployed\n- storage_account_sas: Shared Access Signature token for accessing\nthe storage account: this token must have proper permissions to\ncreate and add entities to Azure storage tables in the above\nstorage account; SAS tokens for a given storage account can be\ngenerated for example via the Azure portal in the\n\"Security + networking\" menu.\n- metrics: tuple that enables sending memory metrics; it can\ncontain 2 optional attributes:\n  - sample_interval: interval expressed in seconds at which metrics\ndata is collected (default: 15)\n  - transfer_interval: interval expressed in seconds at which\nmetrics data is aggregated and sent to the storage account\n(default: 60)\n\nExample snippet of Ops configuration file:\n```\n\"ManifestPassthrough\": {\n  \"azure\": {\n    \"diagnostics\": {\n      \"storage_account\": \"mystorageaccount\",\n      \"storage_account_sas\": \"sv=2022-11-02&ss=bfqt&srt=sco&sp=rwdlacupiytfx&se=2024-05-22T14:50:28Z&st=2024-05-12T06:50:28Z&spr=https&sig=xxyyzz\",\n      \"metrics\": {\"sample_interval\": \"15\",\"transfer_interval\": \"60\"}\n    }\n  }\n}\n```\n\nAggregated memory metrics data consist of the number of samples,\nthe minimum, maximum, last, and average value, and the sum of all\nsamples; these data are insterted in an Azure storage table (one\nentity per aggregated data). The name of the table is in the format\n\"WADMetricsxxxxP10DV2Syyyymmdd\", where xxxx is the transfer\ninterval expressed with ISO8601 format, and yyyymmdd is the\nrepresentation of the 10-day date interval to which the metrics\nrefer (thus, a new table is created every 10 days). For example, a\ntable named WADMetricsPT1MP10DV2S20240503 contains metric data\naggregated every minute (\"PT1M\" is the ISO8601 representation of a\n1-minute period) generated for a 10-day period starting on May 3,\n2024.\n\nBy default, the Azure portal doe not display these metrics in its\ncharts; in order for metrics to be available in the portal, the\nLinux Diagnostics Extension must be enabled and configured in a\nrunning instance (this can be done in the \"Diagnostic settings\"\nsection in the portal) to match the settings in the Nanod manifest\noptions. More specifically, the storage account and the metric\naggregation interval specified in the Azure diagnostic settings\nmust match those specified in the manifest options.\nNote: the Azure VM agent implemented in the cloud_init klib\nresponds to requests to enable and configure the diagnostic\nextension, but does not actually applies the extension settings\nspecified in the requests; instead, it always applies the settings\nfrom the manifest.\n\nCloses #2014","shortMessageHtmlLink":"Azure: implement sending memory metrics via diagnostic extension"}},{"before":"e5e479184405a86cf979c8c3c40603db9a1667e2","after":null,"ref":"refs/heads/dependabot/go_modules/test/go/golang.org/x/crypto-0.17.0","pushedAt":"2024-05-09T14:23:57.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"eyberg","name":"Ian Eyberg","path":"/eyberg","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22410?s=80&v=4"}},{"before":"c2756731da9f6a100ef7b1005047d6435c90452b","after":"4668594719ace9ea3bf02d1c7a27c1fb416041a6","ref":"refs/heads/master","pushedAt":"2024-05-09T14:23:53.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"eyberg","name":"Ian Eyberg","path":"/eyberg","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22410?s=80&v=4"},"commit":{"message":"build(deps): bump golang.org/x/crypto in /test/go (#2021)\n\nBumps [golang.org/x/crypto](https://github.com/golang/crypto) from 0.0.0-20220321153916-2c7772ba3064 to 0.17.0.\r\n- [Commits](https://github.com/golang/crypto/commits/v0.17.0)\r\n\r\n---\r\nupdated-dependencies:\r\n- dependency-name: golang.org/x/crypto\r\n  dependency-type: indirect\r\n...\r\n\r\nSigned-off-by: dependabot[bot] <support@github.com>\r\nCo-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>","shortMessageHtmlLink":"build(deps): bump golang.org/x/crypto in /test/go (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2286689829\" data-permission-text=\"Title is private\" data-url=\"https://github.com/nanovms/nanos/issues/2021\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/nanovms/nanos/pull/2021/hovercard\" href=\"https://github.com/nanovms/nanos/pull/2021\">#2021</a>)"}},{"before":null,"after":"e5e479184405a86cf979c8c3c40603db9a1667e2","ref":"refs/heads/dependabot/go_modules/test/go/golang.org/x/crypto-0.17.0","pushedAt":"2024-05-09T00:35:40.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"dependabot[bot]","name":null,"path":"/apps/dependabot","primaryAvatarUrl":"https://avatars.githubusercontent.com/in/29110?s=80&v=4"},"commit":{"message":"build(deps): bump golang.org/x/crypto in /test/go\n\nBumps [golang.org/x/crypto](https://github.com/golang/crypto) from 0.0.0-20220321153916-2c7772ba3064 to 0.17.0.\n- [Commits](https://github.com/golang/crypto/commits/v0.17.0)\n\n---\nupdated-dependencies:\n- dependency-name: golang.org/x/crypto\n  dependency-type: indirect\n...\n\nSigned-off-by: dependabot[bot] <support@github.com>","shortMessageHtmlLink":"build(deps): bump golang.org/x/crypto in /test/go"}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAEXvvaGgA","startCursor":null,"endCursor":null}},"title":"Activity · nanovms/nanos"}